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

启动性能指标定义：启动指标定义主要在于如何确定启动路径的起点与终点。起点的备选项有下图中的三个点以及 Application 的 attachBaseContext 方法：
- 下图中“点击图标”后的/proc/self/stats starttime 是内核中记录的 App 启动时间点，该数据的 Android 版本兼容性良好也比较贴合真实情况，可以作为备选；
- 接下来的 Process.getStartElapsedRealTime 是 Framework 中记录的 APP 进程创建起点，该 API 是 Android N 起才提供的兼容性较差；
- 再往后是 Application 的构造函数，按照 Android 官方生命周期式的开发模式通常不会往 Application 的构造函数中加逻辑，所以不建议在这里记录起点；
- 最后是大家熟悉的 attachBaseContext 方法也是 Application 生命周期中非常早的一个点，可以在这里记录启动点，虽然可能和真实情况有小幅差距，但能够起到基本的对照效应并且处于 APP 逻辑可以干预的范围内，抖音的启动路径起点选定的正是此处，此外也可以结合前述的内核中启动时刻综合观测。

文章插图

而关于终点的定义同样有几个备选项：Activity-onResume、Activity-onWindowFocusChanged、View-dispatchDraw 和 DecorView-post：
- 少数 APP 在选定冷启阶段终点时可能会选择首页 Activity 的 onResume 时机，但此时整个 Activity 还不是完全可见，与用户感受到的冷启阶段结束时刻有一定的差距；
- 基于上述原因，更多 APP 会选择首页 Activity 的 onWindowFocusChanged 时机，抖音也是选择的此时机作为冷启过程的终点，此时首页 Activity 已经可见但其内部的 view 还不可见，对于用户侧已经可以看见首页背景，即认为冷启阶段到此结束，后续的首页内 View 绘制归入首刷过程中；
- dispatchDraw 从 View 可见这个角度讲应该是比较接近用户感受的，但其受业务改动影响较大，不利于把控冷启时间及维护；
- 最后是通过 DecorView 在 attachToWindow 前 post 一个 runnable 来打点的方式，该方式可以保障在业务 View 完成渲染后做打点，但该方式可能会受业务同学做懒加载在打点前插入逻辑的影响，因此抖音的冷启终点也未选用该时机。
启动性能指标统计：在统计性能指标时有个关键点往往被大家忽略，就是分位值的概念，由于平均值相对更通俗易懂且对大盘突发问题敏感往往作为首要统计指标被关注，但其存在波动较大不利于大盘监控以及难以体现不同分位机型启动性能差异的问题，而分位值更有利于全面监控且各分位波动相对较小，此外对于低端机的性能问题能够更好地显现出来，有助于做专项优化，在优化抖音的启动性能时我们会重点关注 50 分位和 90 分的性能指标，不过分位值也存在一些缺点，比如：概念理解起来相对复杂、个别 bad case 分散到各分位不容易体现出来等，因此比较好的实践是：日常优化主要统计分位值，平均值作为辅助完善监控体系。
启动性能指标校准：由于启动路径往往比较复杂，因此添加了启动性能埋点后还需要额外的校准，总的原则是需要保障指标数据能切实反映大盘用户情形。在添加客户端埋点时最好是先梳理再分主路径和重点 case 分别打点，此外还要对若干异常 case 的数据进行剔除或分类避免污染打点数据，比如抖音在添加启动时间打点时就会对开屏广告、保活进程、push 拉起、deeplink 拉起、启动期间退后台、新用户启动等场景进行过滤或分开统计。

启动优化的实践在做完理论分析与现状分析后，我们基本对全局待优化点及其大致优化方向会产生整体的认知，在开始落地各个优化措施之前还有很重要但往往会被忽略的一步——按优先级排布优化项、制定整体优化方案，这一步在很大程度上制约着后续启动优化的收益预期与进展把控，这两点对于按时达成启动优化的终极目标都至关重要。前述中提及了对“优先级”的把控，这点是制定整体优化方案的重中之重。
从抖音启动优化实践总结来看比较好的优先级策略是按照“投入产出比”来排布优化项，顾名思义：投入人力越少但优化幅度越大的优化项越应该排在前期，因为所有的性能优化历程都势必会经历从高收益到低收益的变化，那么相应的在排布优化项的前后顺序时也需顺应此规律，最终呈现的态势即为：前期以小成本快速降低大盘启动耗时，后期逐步提高投入突破各个瓶颈型耗时点（更后期大规模重构仅能减少几十毫秒启动时间的情形也应在预期之内），全过程同期加强防劣化机制，最终做到可持续优化。