- 原文作者 : Google
- 译文出自 : Medium.com
- 译者 : dustookk
- 状态 : 完成
在Android设备上, 性能和内存是密不可分的, 系统的总内存占用会影响到系统的每个进程的性能表现, 垃圾回收机制也会对runtime的性能表现产生重要影响. 但是本章节要讨论的重点是一些和内存无关的的runtime性能表现.
之前在Context章节的 "UI Thread" 部分已经提到过, UI线程中的复杂操作会引起渲染过程的卡顿. 连锁反应会影响到动画效果, 因为动画的每一帧都是一次渲染. 这就意味着当有动画出现时UI线程里更应该避免复杂的操作. 下面是一些应该避免的常见情况:
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显示.
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越多, 系统进行一般的操作需要消耗的时间就越长, 比如inflation, layout和rendering过程(许多无用的内容占据了很多内存; view本身也很能占据内存, 尤其是自定义控件带来的更多数据). 要找到最节约资源的方式去组织view中的控件. 在某些场景下用自定义view或者自定义layout可以避免复杂的view层级关系. 用一个单一的view去画一些文字和icon也许比用一系列组合viewgroup来实现一样的效果更节省资源. 在交互界面中如何组合控件有一个准则: 如果用户可以和某一UI元素产生交互(比如touch事件, 获取focus等), 那么这个UI元素应该是一个独立的view 而不应该和其他元素组合.
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线程(比如 onDraw()方法 onLayout()方法, 或者一些UI线程中被调用的和view展示有关的方法)避免一些众所周知的耗时操作. 比如调用web service 或执行其它网络请求(会抛出NetworkOnMainThreadException), 或者是访问数据库. 相反, 应该考虑用Loader或者其它模块异步操作完成后再通知UI线程修改界面. 可以用StrictMode模块监控这种问题.
不可以在UI线程访问数据库和文件的另外一个重要原因是Android设备通常并不善于处理IO的并发. 即使你的程序闲置的时候, 其它的程序也许在高负荷的访问磁盘I/O (比如谷歌商店在更新软件). 结果就是有可能会导致ANR发生, 或者至少会导致你的程序出现的严重卡顿.
总的来说, 只要可以放在异步处理的任务就尽量放在异步处理; UI线程需要做的应该只是和UI相关的核心操作, 比如控制界面上元素的属性或者是绘制过程.
广播接收者被用来接受其它程序发来的消息或者事件. 但是如果超出实际需要, 响应过多的广播会导致程序被频繁的唤醒, 从而影响整个系统的性能表现和资源消耗. 应该在程序不需要接受某个广播的时候反注册掉该广播接收者. 注册广播接收者时也要只选择程序需要监听的Intent.
这与前面在Context章节关于低端设备的讨论有关. 也许大多数的用户的设备都不如你每天用的设备性能好, 也许比你的设备用的更久或者更便宜. 为这部分低端手机开发非常的重要, 一些在高端设备上很难察觉的性能差异在低端设备上会非常明显. 你的首选开发设备不应该是市面上最快最新的设备, 而且你也应该持有各种不同的测试设备, 这样就可以保证你的程序在不同速度不同厂商的设备上都有足够的性能表现.
这些需要测试的其它低性能设备包括内存较小的设备或者屏幕分辨率较小的设备. 比如512MB内存的设备, 或者拥有768x480或者更低的屏幕分辨率的设备.
市面上有许多工具可以用来测试你的程序的性能表现, 比如rendering的性能(程序可以达到60fps的刷新频率吗?), 内存回收性能(动画的过程中会因为持续的内存非配所引发的垃圾回收而发生卡顿吗?), 或者程序启动性能(用户会因为你的程序第一次启动做了大量的工作而耽误很长时间吗?). 找到问题. 修复他们.