作者都是各自领域经过审查的专家,并撰写他们有经验的主题. 我们所有的内容都经过同行评审,并由同一领域的Toptal专家验证.
伊万·迪莫斯基的头像

Ivan Dimoski

Ivan是一位成功的Android开发人员和顾问,拥有六年开发用户友好应用程序的经验.

Previously At

Truecaller
Share

Android. 这个平台有什么不喜欢的? 它是免费的,它是可定制的 rapidly growing 它不仅可以在你的手机或平板电脑上使用,还可以在智能手表、电视和汽车上使用.

With the latest Lollipop update, Android编程 持续改善. Android编程软件、工具和资源也是如此. 从一开始,这个平台已经成熟了很多 AOSP 发布,并设置用户期望的门槛相当高. 看这新东西多好 Material 设计模式外观!

There are thousands 不同的设备, 不同的屏幕尺寸, chip architectures, 硬件配置, 软件版本. Unfortunately, 细分是开放的代价, 你的应用在不同设备上失败的方式有上千种, even as an 高级Android程序员.

不管如此巨大的分割, 大多数错误实际上是由于逻辑错误而引入的. 这些漏洞是很容易预防的,只要我们掌握了基本的知识!

这里有一个Android编程教程来解决10个最常见的Android开发错误.

学习Android编程在更高级的水平与本教程.

常见错误1:面向iOS开发

令我非常高兴的是, Android的这种错误现在已经不常见了(部分原因是客户开始意识到苹果设定所有设计标准的日子已经一去不复返了)。. 但是,我们仍然时不时地看到一款iOS克隆应用.

不要误解我的意思,我并不是Android开发的传道者! 我尊重每一个推动移动世界向前发展的平台. But, 现在是2014年,用户使用Android已经有一段时间了, 他们已经习惯了这个平台. 将iOS设计标准强加给他们是一种糟糕的策略!

除非有特别好的理由打破 guidelines, don’t do it. (谷歌一直在这么做,但从来没有通过复制粘贴.)

以下是Android最常见的错误:

  1. 你不应该制作静态标签,它们不属于底部(我指的是你) Instagram).
  2. 系统通知图标不应该有颜色.
  3. 应用程序图标不应该放在圆角矩形内(除非那是你实际的logo). facebook).
  4. 启动画面在初始设置/介绍之外是多余的. 不要在其他场景中使用它们.
  5. 列表不应该有插入符号.

这些只是其中的一些 many other 可能会破坏用户体验的小事情.

常见错误2:针对Android设备开发游戏

除非你是在为一台平板电脑创建一个信息亭/促销应用, 你的Android应用可能不会在所有设备上都好看. Here are a few Android编程 tips to remember:

有上千种可能的情况, 但过了一段时间,你就会有一种用a来覆盖它们的感觉 handful of cases.

你不会拥有成千上万的设备? Not a problem. Android Emulator在复制物理设备方面非常出色. 更好的是,试一试 Genymotion,它的速度快如闪电,并配有许多不同的流行预设设备.

还有,你试过旋转你的设备吗? 所有的地狱都可以挣脱……

常见错误#3:不使用意图

Intents 是Android的关键组件之一吗. 它是在应用程序的不同部分之间传递数据的一种方式, even better, 系统上不同的应用程序.

假设你有一个图库应用程序,可以通过短信分享一些图片的下载链接. 这两种选择哪一种更符合逻辑?

Option 1:

  • 请求SEND_SMS权限.

      
    
  • 编写自己的代码发送短信使用 SmsManager.
  • 向你的用户解释为什么你的图库应用需要使用那些需要花钱的服务, 以及为什么他们必须授予使用你的应用的权限.

Option 2:

  • 启动一个SMS Intent,让一个专为SMS设计的应用程序来完成这项工作

      sendIntent = new Intent.ACTION_VIEW);
      sendIntent.setData(Uri.parse("sms:" + telephoneNumber));
      sendIntent.putExtra(“sms_body”,x);
      startActivity (sendIntent);
    

如果你有任何疑问,最好的解决方案是选项2!

这种方法几乎可以应用于任何事情. Sharing content, taking pictures, recording video, picking contacts, adding events, 打开原生应用的链接, etc.

除非有很好的理由进行自定义实现(例如.(一个应用滤镜的相机),对于这些场景总是使用intent. 它将为您节省大量的编程时间,并剥离 AndroidManifest.xml 不必要的权限.

常见错误4:不使用片段

不久前在Honeycomb中,Android引入了 fragments. 可以把它们看作是独立的构建块,它们有自己的(相当复杂的)生命周期,存在于Activity中. 它们对各种屏幕的优化有很大帮助, 它们很容易被父活动管理, can be reused, 任意组合和定位.

为每个应用程序屏幕启动单独的活动是非常低效的, 因为系统会尽可能长时间地将它们保存在内存中. 杀死一个不会释放其他动物使用的资源.

本Android编程教程建议正确使用fragments,使你的应用程序更高效.

除非你想深入挖掘Android核心并阅读 this article尽管反对使用片段,但你应该尽可能地使用片段. 它基本上是说碎片和 cursor loaders 有良好的预期目的,但执行不力.

常见错误#5:阻塞主线程

主线程只有一个目的:保持用户界面的响应.

尽管测量我们的眼睛/大脑能够感知到的帧速率背后的科学是复杂的,并且受到很多因素的影响, 一般规则是,任何低于24 FPS且延迟大于100 ms的内容都不会被认为是流畅的.

这意味着用户的行动将会有延迟的反馈, 你编写的安卓应用程序就会停止响应. 剥夺用户对应用程序的控制权会导致挫败感, 受挫的用户往往会给出非常负面的反馈.

Even worse, 如果主线程被阻塞了一段时间(活动5秒), 10(广播接收机), ANR will happen.

当你学习Android编程时,你会知道并害怕这个消息.  遵循这些Android编程技巧来尽量减少这种情况.

这在Android 2中很常见.X,在较新的版本上系统不允许您这样做 network calls in the main thread.

为了避免阻塞主线程,总是使用工作线程/后台线程: 1. network calls 2. bitmap loading 3. image processing 4. database querying 5. SD读/写

常见错误#6:重新发明轮子

"好的,我不使用主线程. 我将编写自己的代码,在后台线程中与服务器通信.”

No! 请不要这样做! Network calls, image loading, database access, JSON parsing, 社交登录是应用中最常见的功能. 不只是你的,所有的应用都是. 有更好的办法. 记住Android是如何成熟和成长为一个平台的? 下面是一些简短的例子:

  1. Use gradle as a build system.
  2. Use Retrofit / Volley for network calls.
  3. Use Picasso for image loading.
  4. Use Gson / Jackson for JSON parsing.
  5. Use 共同实现 for social login.

如果你需要实现一些东西,很可能它已经被编写、测试和广泛使用了. 做一些基础研究,读一些 Android编程教程 在编写自己的代码之前!

常见错误7:不假设成功

Great. 我们已经知道有一种更好的方法来处理长时间运行的任务, 为此,我们正在使用文档完备的库. 但是用户仍然需要等待. It’s inevitable. 包裹不是立即发送、处理和接收的. 有往返延迟,有网络故障,有包裹丢失,有梦想被摧毁.

但这一切都是可以衡量的. 成功的网络呼叫是 far more likely 而不是失败的人. 那么为什么要在处理成功的请求之前等待服务器响应呢? 假设成功,处理失败,这要好得多. So, 当用户点赞一篇文章时,点赞数会立即增加, 在不太可能的情况下,电话失败了, 通知用户.

在现代社会,人们期望得到即时反馈. 人们不喜欢等待. 孩子们不希望坐在教室里获得未来回报不确定的知识. 应用程序必须适应用户的心理.

常见错误8:不理解位图

Users love content! 特别是当内容格式良好且看起来不错时. Images, for instance, 都是非常好的内容, 主要是由于他们的特性,传达千言万语的每一个图像. 它们还会消耗大量内存. A lot of memory!

在屏幕上显示图像之前,必须将其加载到存储器中. 因为位图是最常用的方法, 我们将为整个过程提供一个Android编程指南:

假设你想在屏幕上显示一张你用相机拍摄的图像. 为此所需的总内存使用以下公式计算: memory_needded_in_bytes = 4 * image_width * image_height;

Why 4? 那么,最常见/推荐的位图配置是 ARGB_8888. 这意味着对于我们绘制的每个像素, 我们需要为alpha保留8位(1字节), the red, 记忆中的贪婪和蓝色通道, 以便正确地显示它. 还有其他选择,比如 RGB_565 只需要一半内存的配置 ARGB_8888,但失去了透明度和色彩精度(同时可能添加绿色调).

让我们假设你有一个全新的设备,全高清屏幕和1200万像素的摄像头. 您刚刚拍摄的图片是4000x3000像素大,显示它所需的总内存为: 4字节* 4000 * 3000 = 48mb

48mb的内存只能存储一张图像!? That’s a lot!

现在让我们考虑一下屏幕分辨率. 您正在尝试在具有1920x1080像素的屏幕上显示4000x3000图像, 在最坏的情况下(全屏显示图像),您不应该分配超过 4 * 1920 * 1080 = 8.3 MB of memory.

始终遵循Android编程提示 有效显示位图:

  1. 测量显示图像的视图.
  2. 相应地缩放/裁剪大图.
  3. 只显示可以显示的内容.

常见错误#9:使用深度视图层次结构

在Android中,布局有一个XML表示. 以便绘制内容, 需要解析XML, 屏幕需要测量, 所有的元素都需要相应地放置. 这是一个需要优化的资源和耗时的过程.

This is how the ListView (以及最近的 RecyclerView) works.

如果一个布局被膨胀过一次,系统就会重用它. 但是,在某些时候,膨胀布局是必须发生的.

假设你想用图像制作一个3x3的网格. 一种方法是用垂线 LinearLayout containing 3 LinearLayoutS的权值相等,每个都包含3 ImageViews with equal weight.

一些Android编程初学者并不总是能很好地利用LinearLayouts.

用这种方法我们能得到什么? “嵌套权重对性能不利”的警告.

在Android编程界有一种说法,是我刚刚编出来的: “不费什么力气,所有的等级制度都可以被夷平。”.

In this case RelativeLayout or GridLayout 将有效地替换嵌套 LinearLayouts.

常见错误#10:未将minSdkVersion设置为14

好吧,这不是错误,但这是不好的做法.

Android 2.X是开发这个平台的一个巨大的里程碑,但有些东西应该被抛在后面. 支持旧设备增加了代码维护的复杂性,并限制了开发过程.

The numbers 很明显,用户已经离开了,开发者不应该留在后面.

我知道这并不适用于一些使用旧设备的大市场(例如. 印度),并设置 minSdkVersion to 14, on the Facebook App, 意味着数百万用户失去了他们最喜欢的社交网络. But, 如果你想重新开始,并试图为你的用户创造一个美好的体验, 是否考虑过消除过去. 没有资源的用户, 或者觉得需要升级他们的设备/操作系统, 不会有动力去尝试你的Android应用的高级版本,并最终为它花钱.

Wrap Up

Android是一个发展迅速的强大平台. 期望用户跟上步伐可能是不合理的, 但这对Android开发者来说至关重要. 在接受更具挑战性的项目之前,掌握Android基础知识并避免Android错误是最重要的.

更重要的是,我们要知道,Android不仅适用于手机或平板电脑. 它在我们的手腕上,在我们的客厅里,在我们的厨房里,在我们的汽车里. 对生态系统的良好把握和更高级的Android教程将帮助您为各种硬件平台和用例创建应用程序, 从顶级智能手机到基本的智能家居设备.

关于总博客的进一步阅读:

聘请Toptal这方面的专家.
Hire Now
伊万·迪莫斯基的头像
Ivan Dimoski

Located in Stockholm, Sweden

Member since December 11, 2013

About the author

Ivan是一位成功的Android开发人员和顾问,拥有六年开发用户友好应用程序的经验.

Toptal作者都是各自领域经过审查的专家,并撰写他们有经验的主题. 我们所有的内容都经过同行评审,并由同一领域的Toptal专家验证.

Previously At

Truecaller

世界级的文章,每周发一次.

订阅意味着同意我们的 privacy policy

世界级的文章,每周发一次.

订阅意味着同意我们的 privacy policy

Toptal Developers

Join the Toptal® community.