Android 开发 III 规范与性能

Question

在 Android 设备上, 性能和内存是密不可分的, 系统的总内存占用会影响到系统的每个进程的性能表现, 垃圾回收机制也会对 runtime 的性能表现产生重要影响. 但是本章节要讨论的重点是一些和内存无关的的 runtime 性能表现.

在动画和用户交互时避免复杂操作

之前在 Context 章节的 "UI Thread" 部分已经提到过, UI 线程中的复杂操作会引起渲染过程的卡顿. 连锁反应会影响到动画效果, 因为动画的每一帧都是一次渲染. 这就意味着当有动画出现时 UI 线程里更应该避免复杂的操作. 下面是一些应该避免的常见情况:

Layout

Measurement 和 Layout 是非常复杂的操作, view 的层级关系越复杂, 处理起来就越耗时. Measurement 和 layout 发生在 UI 线程 (所有需要改动 activity 里 view 的操作都在 UI 线程中进行). 这就意味着如果一个程序正在执行一个流畅的动画的时候被告知需要在 UI 线程中同时执行 layout 操作, 结果动画肯定要受罪了.

假设你的程序可以在 13 毫秒内绘制完成一个指定的动画, 这是在 16 毫秒的规定范围内的(Google 官方推荐每秒 60 帧的刷新频率). 如果这时一个事件触发了需要耗时 5 毫秒的一个 layout 动作, 那么这个 layout 操作会在动画的下一帧绘制之前执行, 这就会将总绘制耗时增加到 18 毫秒, 结果就是动画效果有一个明显的跳帧.

为了避免这种情况的发生, layout 操作要在动画开始前或动画完成后进行. 还有就是, 尽量使用不会触发 layout 操作的动画效果. 比如, view 的 translationX 和 translationY 属性会影响 post-layout 属性. 而 LayoutParams 的属性又会触发一个 layout 操作去产生作用, 所以类似这种属性的动画效果会影响已经比较合理的 ui 显示.

Inflation

view 的 inflation 过程只能在 UI 线程完成, 如果操作不当会变成一个非常耗时的过程 (view 的层级关系越深, inflation 过程就越耗时) Inflation 过程可以通过主动 inflate 一个 view 或 view 树触发, 也可以通过启动一个不同的的 activity 时隐性触发, 隐性触发会发生在 UI 线程中, 进而会造成 activity 在 inflation 过程中的动画卡顿.

为了避免这种情况, 应该等待当前的动画结束后再触发 view 的 inflation 操作或者 activity 的启动操作. 还有一种情况就是, 为了避免多 type 的 list 在滚动时的 inflation 相关问题, 可以考虑预先 inflate 不同 type 的 view. 比如, RecyclerView 支持预设一个可以产生不同 type 的 ItemView 的 RecycledViewPool.

快速启动

view 的 inflation 过程有些耗时. 并不只是解析一些资源文件那么简单, 更包含了实例化潜在的许许多多的 view 和各个 view 初始化时自身耗时的操作. 包括 bitmap 的解码过程, 绘制 layout 的过程, 还有第一次初始化时的 draw 过程. ui 写的越复杂, view 树状结构层级关系越深,整体的 inflation 过程就会越耗时.

以上的这些都会拖慢程序的启动过程. 当用户启动一个程序时, 他们期望看到的是几乎瞬时的反馈可以告知他们程序已经跑起来了. Android 系统用了一个"启动界面" 来实现这一效果, 包括一个程序设定主题的空白窗口和一些特定的背景图画. "启动界面"是在程序在后台加载以及 inflation 的过程中在系统进程展示的. 当 activity 准备好可以被展示了, 启动界面就切换到了真正的内容, 用户就可以开始使用程序了.

启动界面的加入确实可以给用户一个快速反馈告诉用户程序正在启动, 但是这并不足以应付需要两三秒甚至更长时间启动的程序; 结果就是用户被迫坐在那里盯着空空的启动界面直到程序真正启动起来.

解决这个问题的办法就是用最快的速度启动程序. 如果有一些 UI 界面并不需要在第一次启动的时候展示, 那么就不要初始化它们. 用 ViewStub 作为 sub-hierarchies 的临时占位对象, 这样随时可以填充为真正的 UI 元素. 只要有可能就尽量避免类似解码很大的 bitmap 这样的耗时操作. 尽量避免因为内存分配或垃圾回收引起的内存抖动. 用工具去监控程序的启动时间, 发现并消除遇到的瓶颈.

同时, 避免在 Application 对象中的初始化操作. 只要有新的进程启动, Application 类就会创建新的对象. 会潜在的引起许多超出实际需要（只展示初始化 UI) 的操作. 比如, 当某个用户在查看一张图片时想分享它, 于是选中了你的程序, 这时你的程序需要做的只是展示一个分享界面就可以了. 现在 Application 的子类越来越变成了一个初始化一切操作的仓库, 做着很多多余的工作. 相反, 正确的做法是用单例去控制初始化操作, 这样的话初始化操作只会在该单例第一次被调用时执行. 还有就是, 永远不要在 Application 对象中触发网络请求. 因为 Application 对象也许会在 Service 或者 BroadcastReceiver 启动时被创建; 此时触发网络操作会使一段特定频率下请求数据更新的代码变成对服务器的 DDoS 攻击代码.

还有就是, 程序启动前所处在的状态不同, 启动时间也大不相同. 最坏一种情况是程序完全没有被启动: 此时进程需要被启动, 所有的状态也需要被重新初始化, 程序需要完成所有的 inflation, layout 和 drawing 过程. 另外一个极端情况是, 程序已经启动并在后台运行着, 这时要开启它, 系统只需要把它从后台切换到前台就可以了 - 甚至省去了大量的 layout 和 rendering 过程. 除了两种极端情况外, 还有另外两种场景。

一个是当用户退出程序时, 进程可能还在跑, 但是要再次开启程序, 所有任务需要从头来过（从调用 Activity.onCreate() 方法开始). 还有一种场景是当系统将程序任务从内存中删掉时, 进程和任务都需要重新启动, 但是任务结束时保存的状态会通过 Activity.onCreate() 传给程序并使之受益. 当你测试你的程序的启动时间时, 要确保优化的是最坏场景下的启动过程, 此时进程和任务都需要重新启动. 制造此场景的方法就是, 你可以在最近的任务列表中划掉你的程序杀掉任务和进程, 这就保证了程序下次启动时是完全重新启动的.

避免 View 复杂的层级关系

界面层级关系中的 view 越多, 系统进行一般的操作需要消耗的时间就越长, 比如 inflation, layout 和 rendering 过程（许多无用的内容占据了很多内存; view 本身也很能占据内存, 尤其是自定义控件带来的更多数据). 要找到最节约资源的方式去组织 view 中的控件. 在某些场景下用自定义 view 或者自定义 layout 可以避免复杂的 view 层级关系. 用一个单一的 view 去画一些文字和 icon 也许比用一系列组合 viewgroup 来实现一样的效果更节省资源. 在交互界面中如何组合控件有一个准则: 如果用户可以和某一 UI 元素产生交互（比如 touch 事件, 获取 focus 等), 那么这个 UI 元素应该是一个独立的 view 而不应该和其他元素组合.

避免在靠近 view 层级关系顶层的地方使用 RelativeLayout

RelativeLayout 是一个用起来很方便的控件, 因为它允许工程师们用相对布局摆放子控件. 在许多情况下, 这是个解决问题非常有必要的方案. 但是, 一定要明白使用 RelativeLayout 非常消耗资源. 因为 RelativeLayout 会触发两次 measurement 过程来保证正确的处理了所有子元素的关系. 更糟的是, 它会和 view 层级关系中其他的 RelativeLayout 一起产生更坏的后果. 想象一下一个 view 层级关系的顶部是一个 RelativeLayout; 这本来就将所有子 view 的 measurement 次数变成了原来的两倍. 此时如果另外一个 RelativeLayout 是顶部那个 RelativeLayout 的子 view,那么这时它下面所有子 view 的 measurement 次数又变成了原来的两倍, 也就是所它下面的所有子 view 都经历了四次 measurement 过程.

所以要尽量使用不需要两次 measure 过程的控件, 比如 LinearLayout 或者自定义 layout. 如果一定要用相对布局的方案, 可以考虑用一个自定义的 GridLayout, 可以预处理 view 的相对关系, 从而避免了两次 measure 的问题.

避免在 UI 线程中的复杂操作

拖延 UI 线程会导致动画和界面绘制过程的滞后, 造成用户可以感知到的卡顿. 在 UI 线程（比如 onDraw() 方法 onLayout() 方法, 或者一些 UI 线程中被调用的和 view 展示有关的方法) 避免一些众所周知的耗时操作. 比如调用 web service 或执行其它网络请求（会抛出 NetworkOnMainThreadException), 或者是访问数据库. 相反, 应该考虑用 Loader 或者其它模块异步操作完成后再通知 UI 线程修改界面. 可以用 StrictMode 模块监控这种问题.

不可以在 UI 线程访问数据库和文件的另外一个重要原因是 Android 设备通常并不善于处理 IO 的并发. 即使你的程序闲置的时候, 其它的程序也许在高负荷的访问磁盘 I/O (比如谷歌商店在更新软件). 结果就是有可能会导致 ANR 发生, 或者至少会导致你的程序出现的严重卡顿.

总的来说, 只要可以放在异步处理的任务就尽量放在异步处理; UI 线程需要做的应该只是和 UI 相关的核心操作, 比如控制界面上元素的属性或者是绘制过程.

把程序的唤醒次数降到最低

广播接收者被用来接受其它程序发来的消息或者事件. 但是如果超出实际需要, 响应过多的广播会导致程序被频繁的唤醒, 从而影响整个系统的性能表现和资源消耗. 应该在程序不需要接受某个广播的时候反注册掉该广播接收者. 注册广播接收者时也要只选择程序需要监听的 Intent.

为低端设备开发

这与前面在 Context 章节关于低端设备的讨论有关. 也许大多数的用户的设备都不如你每天用的设备性能好, 也许比你的设备用的更久或者更便宜. 为这部分低端手机开发非常的重要, 一些在高端设备上很难察觉的性能差异在低端设备上会非常明显. 你的首选开发设备不应该是市面上最快最新的设备, 而且你也应该持有各种不同的测试设备, 这样就可以保证你的程序在不同速度不同厂商的设备上都有足够的性能表现.

这些需要测试的其它低性能设备包括内存较小的设备或者屏幕分辨率较小的设备. 比如 512MB 内存的设备, 或者拥有 768x480 或者更低的屏幕分辨率的设备.

测试性能表现

市面上有许多工具可以用来测试你的程序的性能表现, 比如 rendering 的性能（程序可以达到 60fps 的刷新频率吗?), 内存回收性能（动画的过程中会因为持续的内存非配所引发的垃圾回收而发生卡顿吗?), 或者程序启动性能（用户会因为你的程序第一次启动做了大量的工作而耽误很长时间吗?). 找到问题. 修复他们.