【文章摘要】对性能的持续优化，是一个追求卓越的产品所必不可少的。  

在一个软件产品的迭代中，有一些非产品类的需求也是程序猿不得不做的工作，比如之前讲过的「代码重构」和今天要讲的「性能优化」。  

「优化」在汉语中的愿意为「采取一定措施使变得优秀」，在计算机领域，则一般是指在完成同样的功能前提下，消耗更低的资源（包括时间、内存、电量等），对应到具体的产品形态上，则是动画更流畅，操作更顺滑，占用的存储空间更小等这些用户可以实实在在体验到的特性。对性能的持续优化，是一个追求卓越的产品所必不可少的。  

然而，当程序猿对你说「昨天主要在做这里的优化」时，你知道他昨天到底做了什么又是如何做的吗？  

1)启动速度优化  

启动速度的快慢作为用户对你的第一印象，这是个必须重视的问题。我们将启动定义成从用户「打开」应用程序到「可操作」这个过程。每个应用程序都需要一个启动过程，这个过程中，应用程序需要准备好必须的资源并对功能模块初始化（其实还是准备资源啦）。  

而在冷启动的过程中，这些资源都需要从外部存储器（磁盘、SD卡等）中加载，例如读取图片、文件、用户账户信息等。随着功能的扩展，功能依附的资源、数据越来越多，如果将所有的资源都一股脑的放在启动阶段加载，启动过程将会不断的被延长。  

然而，在启动时，或者启动后的一段时间内，并不会用到所有的数据。将数据按照「必须的」、「可延时加载的」和「不需要主动加载的」进行分类，其中「必须的」资源会阻塞用户的操作，例如闪屏的初始化，首屏内容的数据准备等；「可延时加载的资源」则可以等到UI可操作后，「异步」的在线程中执行，控制的好的话，用户基本上不会感知到这个过程的存在。  

一些非关键路径功能所需的资源，则可以延后到功能被真正使用时再进行初始化，不需要在启动过程中自动初始化。这样处理后，启动速度就会变的可控。启动速度优化的关键点，就是准确的区分出这三类资源，并尽量的压缩「必须」资源的数量，以及降低「可延时加载的」资源对UI操作的影响。  

2）操作和动画卡顿的优化  

在《庖丁解牛：来比比谁家的app更卡》中果果有讲到如何评价一个Android应用的「卡顿」程度，也提到了。在解决「过度绘制」问题之前，程序猿首先要定位到哪个控件被错误的设置了背景。通过代码去查的话，过程会很「苦逼」，好在谷歌给「苦逼」的程序猿带来一个名叫HierarchyViewer的工具，让程序猿能在「苦逼」的道路上走的稍微不那么「苦逼」。  

上图中每个灰色的方框都代表一个UI控件，横向的连线表示控件的父子关系，也就是UI的层级，越往右层级越深，而最左边的一个灰色方框你可以把它当做你手机的屏幕。用鼠标点击对应的灰色方框，HierarchyViewer会将当前方框对应的控件和其子控件的内容展示出来，这样，程序猿就可以快速的定位到哪一个控件被不科学的设置了背景资源。找到它，干掉它！  

除了「过度绘制」外，过深的UI层级也会影响操作的流畅性。原因是系统的绘制和排版指令，都是通过控件树的根节点向叶子节点传递的，对应HierarchyViewer显示的内容就是从左到右依次传递，很显然，UI层级越深，指令传递的过程就越长，当用户的操作触发排版和重绘时，就会消耗更多的时间，进而造成「卡顿」。HierarchyViewer也是检查应用程序UI层级很好的工具，比如上图上那些只包含一个子控件的父控件，一般情况下都是可以合并的。  

关于「性能优化」，都是一些「技术向」的概念，大家先消化一下，后续再讲讲关于内存、电量和流量的优化。另外，文中如有没说清楚或者有异议的地方欢迎留言讨论。