“压箱底”的启动优化“秘籍”|极客时间

大家好，我是《 Android 开发高手课》作者、前微信高级工程师张绍文。今天和大家分享的是 Android 应用启动优化的“秘籍”，在优化过程中你会遇到什么问题？该如何分析？又该如何解决？

用户如果想打开一个应用，就一定要经过“启动”这个步骤。 启动时间的长短，不只是用户体验的问题，对于淘宝、京东这些应用来说，会直接影响留存和转化等核心数据。 对研发人员来说，启动速度是我们的“门面”，它清清楚楚可以被所有人看到，我们都希望自己应用的启动速度可以秒杀所有竞争对手。

那启动过程究竟会出现哪些问题？我们应该怎么去优化和监控应用的启动速度呢？是否还有方法可以做进一步优化吗？怎么证明你秒杀所有的竞品？如何在线上衡量启动优化的效果？怎么保障和监控启动速度是否变慢？

今儿和大家分享我对“启动优化”的理解，对应用性能优化的体会。

• 业务优化：应用层 。开始的时候通过业务代码的优化，我很轻松地就把启动速度优化了 50%。但正如《大停滞》所说的，这只是摘完了“ 所有低垂的果实 ”。之后很快就陷入了停滞，就像冲进了一条漆黑的隧道，不知道还可以做哪些事情，很多现象从表面也不知道如何解释：I/O 有时候为什么那么慢？线程的优化应该怎么样去衡量？
• Android Framework：系统框架层 。为了冲出这条漆黑的隧道，我去研究了 Android 的内存管理、文件系统、渲染框架等各个模块；学习如何去优化和监控 I/O、线程、卡顿以及帧率，建立了各种各样的性能监控框架。 为什么我对监控如此重视？ 这是因为对于大厂来说，“挖坑容易，填坑难”，几十上百人协同开发一个项目，我们不希望只是解决具体的某一个问题，而是要彻底解决某一类问题。但想要实现一个监控框架，前提是需要对 Framework 有非常充分地理解和研究。
• Linux Kernel：内核层 。再深入下去，我还需要利用 Linux 的一些机制，例如 ftrace、Perf、JVMTI 等。在做 I/O 的类重排、文件重排评估的时候，还需要自己去修改内核的参数，去刷 ROM。
• Hardware：硬件层 。高端机和低端机的硬件差异究竟在哪里？eMMC 闪存和 UFS 闪存的区别是什么？除了更加了解硬件的性能和特性，到了这个阶段我还希望可以向手机厂商和硬件厂商要性能。例如高通的 CPU Boost 、微信的 Hardcoder、OPPO 的开放平台等。

启动优化的过程，就像是一个知识爬坡的过程。我们不停地尝试往底层深入，希望去摘更高的果实。同样专栏也是希望帮你补充“爬坡”所需的知识，让你一步步进阶成为高手，并可以用高手的思维去寻找、解决开发中遇到的复杂问题。

还是回到启动优化，既然里面涉及那么多问题，我们该如何具体优化呢？

启动过程分析

在真正动手开始优化之前，我们应该先搞清楚从用户点击图标开始，整个启动过程经过哪几个关键阶段，又会给用户带来哪些体验问题。

我以微信为例，用户从桌面点击图标开始，会经过 4 个关键阶段。

• T1 预览窗口显示 。系统在拉起微信进程之前，会先根据微信的 Theme 属性创建预览窗口。当然如果我们禁用预览窗口或者将预览窗口指定为透明，用户在这段时间依然看到的是桌面。
• T2 闪屏显示 。在微信进程和闪屏窗口页面创建完毕，并且完成一系列 inflate view、onmeasure、onlayout 等准备工作后，用户终于可以看到熟悉的“小地球”。
• T3 主页显示 。在完成主窗口创建和页面显示的准备工作后，用户可以看到微信的主界面。
• T4 界面可操作 。在启动完成后，微信会有比较多的工作需要继续执行，例如聊天和朋友圈界面的预加载、小程序框架和进程的准备等。在这些工作完成后，用户才可以真正开始愉快地聊天。

启动问题分析

从启动流程的 4 个关键阶段，我们可以推测出用户启动过程会遇到的 3 个问题。这 3 个问题其实也是大多数应用在启动时可能会遇到的。

• 问题 1：点击图标很久都不响应

如果我们禁用了预览窗口或者指定了透明的皮肤，那用户点击了图标之后，需要 T2 时间才能真正看到应用闪屏。对于用户体验来说，点击了图标，过了几秒还是停留在桌面，看起来就像没有点击成功，这在中低端机中更加明显。

• 问题 2：首页显示太慢

现在应用启动流程越来越复杂，闪屏广告、热修复框架、插件化框架、大前端框架，所有准备工作都需要集中在启动阶段完成。上面说的 T3 首页显示时间对于中低端机来说简直就是噩梦，经常会达到十几秒的时间。

• 问题 3：首页显示后无法操作

既然首页显示那么慢，那我能不能把尽量多的工作都通过异步化延后执行呢？很多应用的确就是这么做的，但这会造成两种后果：要么首页会出现白屏，要么首页出来后用户根本无法操作。

很多应用把启动结束时间的统计放到首页刚出现的时候，这对用户是不负责任的。看到一个首页，但是停住十几秒都不能滑动，这对用户来说完全没有意义。 启动优化不能过于 KPI 化，要从用户的真实体验出发，要着眼从点击图标到用户可操作的整个过程。

启动优化

启动速度优化的方法和卡顿优化基本相同，不过因为启动实在是太重要了，我们会更加“精打细算”。我们希望启动期间加载的每个功能和业务都是必须的，它们的实现都是经过“千锤百炼”的，特别是在中低端机上面的表现。

“工欲善其事必先利其器”，我们需要先找到一款适合做启动优化分析的工具。

你可以先回忆一下“卡顿优化”提到的几种工具。Traceview 性能损耗太大，得出的结果并不真实；Nanoscope 非常真实，不过暂时只支持 Nexus 6P 和 x86 模拟器，无法针对中低端机做测试；Simpleperf 的火焰图并不适合做启动流程分析；systrace 可以很方便地追踪关键系统调用的耗时情况，但是不支持应用程序代码的耗时分析。

综合来看，在卡顿优化中提到“systrace + 函数插桩”似乎是比较理想的方案，而且它还可以看到系统的一些关键事件，例如 GC、System Server、CPU 调度等。

点击查看优化工具

在拿到整个启动流程的全景图之后，我们可以清楚地看到这段时间内系统、应用各个进程和线程的运行情况，现在我们要开始真正开始“干活”了。

具体的优化方式，我把它们分为闪屏优化、业务梳理、业务优化、线程优化、GC 优化和系统调用优化。

点击查看优化方法

启动优化的进阶方法

当然高手可不是这么容易当的，仅仅完成这些就美滋滋地向老大汇报工作成果：“启动速度提升 30%，秒杀所有竞品好几条街”，启动优化工作就结束了吗？“还有什么方法可以做进一步优化吗？怎么证明你秒杀所有的竞品？如何在线上衡量启动优化的效果？怎么保障和监控启动速度是否变慢？”

除了上面这些常规的优化方法，我还有一些与业务无关的“压箱底”方法可以帮助加快应用的启动速度。当然有些方法会用到一些黑科技，它就像一把双刃剑，需要你做深入的评估和测试。

• I/O 优化
• 数据重排
• 类的加载
• 黑科技

点击查看启动优化进阶方案和监控方案

未来移动开发无论是变成大前端还是 Flutter 的世界，性能、效率和架构都是永恒不变的主线。今天我们在 Android 开发打下的坚实基础，未来也会帮助我们更好地理解和深入新的开发模式或者新的系统。崩溃、内存、存储、渲染、I/O、网络…这些知识以及它们背后的底层原理依然还是非常重要的。