Android 性能优化典范（六）

作者简介：

胡凯（@胡凯me），腾讯 Android 工程师，热爱开源与分享，维护 Android 官方培训课程协作项目，关注 Android 应用性能优化的总结与分享，推崇 Android 官方最佳实践。个人博客：http://hukai.me，Github：https://github.com/kesenhoo。

前言

这里是Android性能优化典范第 6 季的课程学习笔记，从被@知会到有连载更新，这篇学习笔记就一直被惦记着。现在学习记录分享一下，请多多指教包涵！这次一共才 6 个小段落，涉及的内容主要有程序启动时间性能优化的三个方面：优化 activity 的创建过程，优化 Application 对象的启动过程，正确使用启动显屏达到优化程序启动性能的目的。另外还介绍了减少安装包大小的 checklist 以及如何使用 VectorDrawable 来减少安装包的大小。

系列阅读

Android 性能优化典范（一）：主要从 Android 的渲染机制、内存与 GC、电量优化三个方面展开，介绍了 Android 中性能问题的底层工作原理，以及如何通过工具来找出性能问题及提升性能的建议。

Android 性能优化典范（二）：20 个短视频，主要内容为：电量优化、网络优化、Android Wear 上如何做优化、使用对象池来提高效率、LRU Cache、Bitmap 的缩放、缓存、重用、PNG 压缩、自定义 View 的性能、提升设置 alpha 之后 View 的渲染性能，以及 Lint、StictMode 等工具的使用技巧。

Android 性能优化典范（三）：更高效的 ArrayMap 容器，使用 Android 系统提供的特殊容器来避免自动装箱，避免使用枚举类型，注意onLowMemory与onTrimMemory的回调，避免内存泄漏，高效的位置更新操作，重复 layout 操作的性能影响，以及使用 Batching，Prefetching 优化网络请求，压缩传输数据等使用技巧。

Android 性能优化典范（四）：优化网络请求的行为，优化安装包的资源文件，优化数据传输的效率，性能优化的几大基础原理等。

Android 性能优化典范（五）：文章共有10个段落，涉及的内容有：多线程并发的性能问题，介绍了 AsyncTask、HandlerThread、IntentService 与 ThreadPool 分别适合的使用场景以及各自的使用注意事项。这是一篇了解 Android 多线程编程不可多得的基础文章，清楚地了解这些 Android 系统提供的多线程基础组件之间的差异以及优缺点，才能够在项目实战中做出最恰当的选择。

Android 性能优化典范（六）：文章共 6 个段落，涉及的内容主要有程序启动时间性能优化的三个方面：优化 activity 的创建过程，优化 Application 对象的启动过程，正确使用启动显屏达到优化程序启动性能的目的。另外还介绍了减少安装包大小的 checklist 以及如何使用 VectorDrawable 来减少安装包的大小。

1）App Launch time 101

提高程序的启动速度意义重大，很显然，启动时间越短，用户才越有耐心等待打开这个 App 进行使用。反之启动时间越长，用户则越有可能来不及等到 App 打开就已经切换到其他 App 了。程序启动过程中的那些复杂错误的操作很可能导致严重的性能问题。

Android 系统会根据用户的操作行为调整程序的显示策略，用来提高程序的显示性能。例如，一旦用户点击桌面图标，Android 系统会立即显示一个启动窗口，这个窗口会一直保持显示，直到画面中的元素成功加载并绘制完第一帧。这种行为常见于程序的冷启动，或者程序的热启动场景（程序从后台被唤起或者从其他 App 界面切换回来）。那么关键的问题是，用户很可能会因为从启动窗口到显示画面的过程耗时过长而感到厌烦，从而导致用户没有来得及等程序启动完毕就切换到其他 App 了。更严重的是，如果启动时间过长，可能导致程序出现 ANR。我们应该避免出现这两种糟糕的情况。

从技术角度来说，当用户点击桌面图标开始，系统会立即为这个 App 创建独立的专属进程，然后显示启动窗口，直到 App 在自己的进程里面完成了程序的创建以及主线程完成了 Activity 的初始化显示操作，再然后系统进程就会把启动窗口替换成APP的显示窗口。

上述流程里面的绝大多数步骤都是由系统控制的，一般来说不会出现什么问题，可是对于启动速度，我们能够控制并且需要特别关注的地方主要有三处：

Activity 的 onCreate 流程，特别是 UI 的布局与渲染操作，如果布局过于复杂很可能导致严重的启动性能问题。
Application 的 onCreate 流程，对于大型的 App 来说，通常会在这里做大量的通用组件的初始化操作。
目前有部分 App 会提供自定义的启动窗口，这里可以做成品牌宣传界面或者是给用户提供一种程序已经启动的视觉效果。

在正式着手解决问题之前，我们需要掌握一套正确测量评估启动性能的方法。所幸的是，Android 系统有提供一些工具来帮助我们定位问题。

1. 首先是 display time：从 Android KitKat 版本开始，Logcat 中会输出从程序启动到某个 Activity 显示到画面上所花费的时间。这个方法比较适合测量程序的启动时间。

2. 其次是 reportFullyDrawn 方法：我们通常来说会使用异步懒加载的方式来提升程序画面的显示速度，这通常会导致的一个问题是，程序画面已经显示，可是内容却还在加载中。为了衡量这些异步加载资源所耗费的时间，我们可以在异步加载完毕之后调用activity.reportFullyDrawn()方法来告诉系统此时的状态，以便获取整个加载的耗时。

3. 然后是 Method Tracing：前面两个方法提供了启动耗时的总时间，可是却无法提供具体的耗时细节。为了获取具体的耗时分布情况，我们可以使用 Method Tracing工具来进行详细的测量。

4. 最后是 Systrace：我们可以在 onCreate 方法里面添加trace.beginSection()与trace.endSection()方法来声明需要跟踪的起止位置，系统会帮忙统计中间经历过的函数调用耗时，并输出报表。

2）App Launch Time & Activity Creation

提升 Activity 的创建速度是优化 App 启动速度的首要关注目标。从桌面点击 App 图标启动应用开始，程序会显示一个启动窗口等待 Activity 的创建加载完毕再进行显示。在 Activity 的创建加载过程中，会执行很多的操作，例如设置页面的主题、初始化页面的布局、加载图片、获取网络数据、读写 Preference 等。

上述操作的任何一个环节出现性能问题都可能导致画面不能及时显示，影响了程序的启动速度。上一个段落我们介绍了使用 Method Tracing 来发现那些耗时占比相对较多的方法。假设发现某个方法执行时间过长，接下去就可以使用 Systrace 来帮忙定位到底是什么原因导致那个方法执行时间过长。

除了使用工具进行具体定位分析性能问题之外，以下两点经验可以帮助我们对 Activity 启动做性能优化：

优化布局耗时：一个布局层级越深，里面包含需要加载的元素越多，就会耗费更多的初始化时间。关于布局性能的优化，这里就不展开描述了。
异步延迟加载：一开始只初始化最需要的布局，异步加载图片，非立即需要的组件可以做延迟加载。

3）App Launch Time & Bloated Application Objects

在 Application 初始化的地方做太多繁重的事情是可能导致严重启动性能问题的元凶之一。Application 里面的初始化操作不结束，其他任意的程序操作都无法进行。

有时候，我们会一股脑地把绝大多数全局组件的初始化操作都放在 Application 的onCreate里面，但其实很多组件是需要做区别对待的，有些可以做延迟加载，有些可以放到其他的地方做初始化操作，特别需要留意包含 Disk IO 操作、网络访问等严重耗时的任务，它们会严重阻塞程序的启动。

优化这些问题的解决方案是做延迟加载，可以在 Application 里面做延迟加载，也可以把一些初始化的操作延迟到组件真正被调用到的时候再做加载。

4）App Launch Time & Theme Launch Screens

启动闪屏不仅仅可以作为品牌宣传页，还能够减轻用户对启动耗时的感知，但是如果使用不当，将适得其反。前面介绍过当点击桌面图标启动 App 的时候，程序会显示一个启动窗口，一直到页面的渲染加载完毕。如果程序的启动速度足够快，我们看到的闪屏窗口停留显示的时间则会很短，但是当程序启动速度偏慢的时候，这个启动闪屏可以一定程度上减轻用户等待的焦虑感，避免用户过于轻易的关闭应用。

目前大多数开发者都会通过设置启动窗口主题的方式来替换系统默认的启动窗口，通过这种方式只是使用『障眼法』弱化了用户对启动时间的感知，但本质上并没有对启动速度做什么优化。也有些 App 通过关闭启动窗口属性android:windowDisablePreview的方式来直接移除系统默认的启动窗口，但是这样的弊端是用户从点击桌面图标到真的看到实际页面的这段时间当中，画面没有任何变化，这样的用户体验是十分糟糕的！

对于启动闪屏，正确的使用方法是自定义一张图片，把这张图片通过设置主题的方式显示为启动闪屏，代码执行到主页面的onCreate的时候设置为程序正常的主题。

5）Smaller APKs: A Checklist

减少应用程序安装包的大小，不仅仅减少了用户的网络数据流量还减少了下载等待的时间。毋庸置疑，尽量减少程序安装包的大小是十分有必要的。通常来说，减少程序安装包的大小有两条规律：要么减少程序资源的大小，要么就是减少程序的代码量。这里总结一个简易版的减少安装包大小的 Checklist。

减少程序图片资源的大小

1. 确保在 build.gradle 文件中开启了minifEnabled与shrinkResources的属性，这两个属性可以帮助移除那些在程序中使用不到的代码与资源，帮助减少 App 的安装包大小。

2. 有选择性的提供对应分辨率的图片资源，系统会自动匹配最合适分辨率的图片并执行拉伸或者压缩的处理。

3. 在符合条件的情况下，使用 Vertor Drawable 替代传统的 PNG/JPEG 图片，能够极大地减少图片资源的大小。传统模式下，针对不同 dpi 的手机都需要提供一套 PNG/JPEG 的图片，而如果使用 Vector Drawable 的话，只需要一个 XML 文件即可。

4. 尽量复用已经存在的资源图片，使用代码的方式对已有的资源进行复用，如下图所示：

以上几点虽然看起来都微不足道，但是真正执行之后，能够显著减少安装包的资源图片大小。

减少程序的代码量

开启 MinifEnabled、Proguard。打开这些编译属性之后，程序在打包的时候就不会把没有引用到的代码编译进来，以此达到减少安装包大小的目的。
注意因为编译行为额外产生的方法数，例如类似 Enum、Protocal Buffer 可能导致方法数与类的个数增加。
部分引入到工程中的 jar 类库可能并不是专门针对移动端 App 而设计的，它们最开始可能是运用在 PC 或者 Server 上的。使用这些类库不仅仅额外增加了包的大小，还增加了编译时间。单纯依靠 Proguard 可能无法完全移除那些使用不到的方法，最佳的方式是使用一些更加轻量化，专门为 Android App 设计的 jar 类库。

安装包的拆分

设想一下，一个 low dpi，API<14 的用户手机下载安装的 APK 里面却包含了大量 xxhdpi 的资源文件，对于这个用户来说，这个 APK 是存在很大的资源浪费的。幸好 Android 平台为我们提供了拆分 APK 的方法，它能够根据 API Level、屏幕大小以及 GPU 版本的不同进行拆分，使得对应平台的用户下载到最合适自己手机的安装包。