抖音 Android 性能优化系列：启动优化之理论和工具篇( 六 ) _抖音

文章插图

在完成前述的全局优先级排布及方案制定后，才算真正来到了实施优化的阶段，在这个阶段所要用到的各类优化策略及配合方法在前文方法论部分已有详细讲述，在实战部分首先要补充一下前述几类优化策略按照“性能无损”、“业务无损”的区别划分，整体如上图所示，此外，我们会结合抖音启动优化实战经验列举各优化策略下可实施的优化项，以供参考：

正面优化：删减非必要的启动逻辑、开屏页与首页 Activity 合并、获取进程名从 IPC 转反射方式等；
按需优化：ContentProvider 中过早初始化逻辑转为使用时初始化、多进程由启动时加载转为使用时或特定场景触发加载等；
延迟优化：4.x 机型延迟执行 Multidex.install 中的 Odex 操作、主线程消息队列中非启动必要消息延迟执行、启动路径非高优业务逻辑延迟初始化等；
运行时优化：CPU 提频、语言层面优化（内联、替换反射、避免用 Kotlin 的 Range 循环）、关闭 Verify Class、4.x 机型抑制 GC、主动触发 AOT 编译、资源重排、类重排、dex 重排等；
异步优化：异步预加载（ShardPreference、实例化对象）、异步 inflate view、线程收敛等；
降级优化：极速版、组件化降级、非必要耗时逻辑按人群/地区降级等；
综合优化：启动任务调度框架、启动路径重构、前后台启动任务精细化重排、后台负载优化等，这些优化项属于前述优化思想的综合应用，一般不局限于单方面的优化。

通过上述列举的各策略优化项你可能会发现，这其中有的优化项其实会对个别业务性能或功能有损，但最终对于启动性能是有显著提升的，那么此时需要按照“全局收益最大”的策略来综合评估这些优化项的可落地性，并不是只看单点的得失，这种全局性的思维在性能优化中非常重要。
线上验证的实践这部分在前述的方法论中已针对三个关键点阐述得比较细致，这里仅针对三个关键点在落地时的技巧或注意事项加以补充：

线下的优化一定要有线上的指标反馈：由于线上设备的固有硬件性能各异，所以需要有足够量级的用户启动打点数据才能相对准确地判定线下的优化是否在线上产生了效果，这个量级从抖音启动优化中摸索的经验来看一般达到 100 万即可；此外，观测启动性能数据的时间点也需要把控好，这是由于每次发布升级版 APP 后，大都是性能相对好的手机会先升级，这个现象会等导致发版初期的启动性能数据整体偏好，不能反映真实大盘情形，因此，抖音一般会选取每个版本发版后 4-5 天（可能随 APP 升级覆盖安装的速度不同而不同）的数据判定大盘情形。
线上指标需要结合均值与分位值综合来评估：在抖音启动优化实践中，启动耗时均值会更多用于大盘情形评估或线上监控中，而作为性能优化的同学最主要关注的是 50 分位机型的数据，这是能代表过半数用户启动性能水准的指标，此外 90 分位以上的机型也需要我们额外关注，这类机型非常容易放大启动性能问题，从实际来看，90 以上相对 50 的绝对分位数差了不到一倍，但冷启耗时却可能差到 2 倍左右（如下图所示抖音在某段时期的各分位冷启耗时情形），这说明低端机的用户启动体验是明显可感知的差，基于我们曾经做过的劣化实验结果来看，这些机型的启动性能如果不能有效提升，将有很大概率减少其留存。

文章插图

在验证收益时通过 AB 实验达成：AB 实验相对于观测不同版本的大盘数据来看更具有严谨性，因此在产出实验结论前同样需要保障数据量和时间跨度，抖音在开启性能的 AB 实验后，一般会让对照组及实验组进组用户各达到 100 万并保持至少 5 天后才进行实验的数据分析并产出结论，这样可以基本保障所有相关指标的稳定及置信。

防劣化的实践防劣化的体系建设是个比较复杂的工程，要做好是有非常大的挑战的。抖音从最早的线下手动的分版本测试开始，经过了逐步的摸索优化，演变到当前涵盖了代码提交时静态检测、线下自动化劣化测试和归因、灰度劣化发现和归因、线上常态化的劣化监控和归因。防劣化是一个漏斗，从代码提交阶段到线下测试阶段，再到灰度发布阶段，再到线上版本发布阶段，我们希望劣化能够更前置的发现，每个环节都尽可能的发现解决更多的劣化，保证更少的劣化被带到线上。