Android APP启动优化

应用启动的类型

冷启动

从点击应用图标到UI界面完全显示且用户可操作的全部过程。

启动流程

Application 阶段、handle message 间隙、Activity 阶段和数据加载间隙，全路径各部分细分涵盖的内容如下图所示：

APP 进程由 zygote 进程 fork 出来后会执行 ActivityThread 的 main 方法，该方法最终触发执行bindApplication，这也是 Application 阶段的起点；然后是我们在应用中能触达到的attachBaseContext阶段，4.x 的机型在该阶段具有较长的 MultiDex 耗时可以做针对性优化（可参考“抖音 BoostMultiDex 优化实践”），本阶段也是最早的预加载时机；接下来是installProvider阶段，很多三方 sdk 借助该时机来做初始化操作，很可能导致启动耗时的不可控情形，需要按具体 case 优化；此后就到了 Application 的onCreate阶段，这里有很多三方库和业务的初始化操作，是通过异步、按需、预加载等手段做优化的主要时机，它也是 Application 阶段的末尾。

在Application 阶段和 Activity 阶段之间往往会不可避免地被插入很多 post 到主线程的消息及相应待执行任务，这是拉长启动耗时的另一不可控问题点，需要加以监控治理或通过消息调度优化来尽量减小此间隙。

在来到 Activity 阶段后，首先经历的是其onCreate生命周期，这里涵盖了首屏业务优化的主要场景也是开启异步并发的主要时机，在其中有个重要的 setContentView 方法会触发 DecorView 的 install，可尝试对 DecorView 的构建进行预加载；后续自然来到View 构建的阶段，该阶段在抖音上相当耗时，可采用异步 Inflate 配合 X2C（编译期将 xml 布局转代码）并提升相应异步线程优先级的方法综合优化；再来到View 的整体渲染阶段，涵盖 measure、layout、draw 三部分，这里可尝试从层级、布局、渲染上取得优化收益。

最后是首屏数据加载阶段，这部分涵盖非常多数据相关的操作，也需要综合性优化，可尝试预加载、缓存或网络优先级调度等手段。

此外，针对全路径所有阶段还可以实施通用性的优化项，如：启动任务调度框架、类重排、IO 预加载、全局通用性框架优化等。

启动耗时成因分析

启动耗时成因分析：所有的耗时均因代码运行时不合理地消耗系统资源产生，而不合理的耗时点正是需要做归因分析之处。抖音按照不合理耗时点消耗的主要系统资源类型划分出五大成因，分别是：CPU Time、CPU Schedule、IO Wait、Lock Wait 和 IPC，下面分别对各成因进行剖析：

1. CPU Time 指占用 CPU 进行计算所花费的时间绝对值，中断、挂起、休眠等行为是不会增加 CPU Time 的，所以因 CPU Time 开销占比高导致的不合理耗时点往往是逻辑本身复杂冗长需要消耗较多 cpu 时间片才能处理完。比较常见的高 CPU 占用是循环，比如抖音启动时遇到过一个 so 加载耗时，最后定位原因是在解压 so 的时候，遍历 ZipEntry 的次数过多导致，一个可行的优化策略就是可以把 so 所在的 ZipEntry 提前，遍历完 so 的 ZipEntry 之后可以提前中止遍历，而不需要遍历剩下的无效 ZipEntry。除循环之外，反射也是导致 CPU Time 的重要原因，像在序列化/反序列化、View Inflate 时，都有大量的反射操作，反射的耗时主要是字符串去查找 Method 或者 Field，这个优化策略也可以考虑提前查找 Method 和 Field 缓存起来，或者是通过内联来降低 Field 数量等。另外一个常见的 CPU 耗时是类加载，类的加载过程包括：Load，从 Dex 文件里读取类的信息，可通过类重排优化；Verify，验证指令是否合法等，通过关掉 Class Verify 可以优化该过程，同时高版本的 vdex 也是为了优化 verify 过程而设计，在 dex2oat 的时候做 verify，verify 之后的结果保存成 vdex，后续只需要加载 vdex；Link，给 Field、Method 分配内存，按照名字排序以方便后续反射的时候查找 Field、Method 等，这个过程的优化，art 虚拟机采用了 ImageSpace 的方案进行了优化，将 Link 后的内存保存为 image 文件&#x