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

后台线程优化策略与主线程类似，在此基础上还可以实施后台任务缩减、线程收敛、开启多进程等优化措施；此外，主线程和后台线程均存在较多启动任务且彼此间可能存在关联，因此，可以对全局的启动任务做依赖关系梳理并实施精细化的任务重排，旨在减少依赖任务间的等待耗时；

全局优化主要是指业务无关的通用的全局优化策略，如虚拟机层面或 IO 层面的优化等。

线上验证在完成了具体的优化项施工后，就来到了线上验证大盘收益的阶段。这个阶段有三点需要注意：

线下的优化一定要有线上的指标反馈，线下的优化项因为设备或操作习惯差异往往难以评估是否具备普遍影响，只有当相应的线上指标取得正面反馈后才能验证拿到了有效的优化收益；
线上指标需要结合均值与分位值综合来评估，只关注启动耗时的均值往往会掩盖低分位设备的现状，这部分设备可能占比不高，对均值影响有限，但抖音庞大的用户基数乘以该比例仍旧是不小的数量，为了保障该部分用户的启动性能体验，抖音一般会分 50%、70%、90%三个分位值来评估指标；
在验证收益时通过 AB 实验达成，这样做不仅能控制变量确保优化项的严格有效，还能借此来观察性能优化所带来的业务指标收益，这些都可以作为规划后续启动优化方向的参考指导。

防劣化在线上验证优化措施取得切实收益后，并不是万事大吉了，持续保持住优化效果才算完整达成了启动性能优化的目的。其实不仅是启动优化，整个性能优化领域都是围绕着“攻”和“守”来展开的，“攻”即为前述的分析与优化，而“守”则是防止劣化，在防劣化方面大家往往不会像优化的方面那么重视，但实际上能防止劣化是可持续取得优化效果的前提（否则新的优化效果会用于弥补劣化甚至入不敷出），并且防劣化相比于优化是更能持久有益的。
抖音启动性能防劣化的进程分为了三个时期，不同时期有不同的表现与应对手段，这很可能是大多数 APP 优化启动性能都要经历的，这里提炼出来以供参考：

快速下降期：此时一般位于启动优化的初始阶段，优化空间很大，伴随有小幅度的劣化但往往都能被更大幅度的优化抵消且还仍有收益，这时应该抓大放小，按照更高投入产出比的策略重点推进优化，同时也抽出少部分精力治理修复成本低的劣化。
瓶颈期：到了该时期绝大部分优化收益已经拿到，想进一步做到优化往往需要投入更多成本，且优化幅度有限，整体的投入产出比不高，同期还会伴随有中小幅的劣化，此时需要建立完善的线上线下监控体系，及时发现并修复劣化，此外还要通过架构改造从源头上限制劣化的发生，综合保障优化的收益不会被劣化抵消。
劣化期：这个时期往往出现在年关或重要节日期间，这类时间点往往有重要且紧急的活动项目上线，众多关联方面均要为其开绿灯，启动性能指标也不例外，为了保障活动效果可能要加入若干耗时的主线程启动任务，所带来的的劣化幅度往往比较大，此时需要对齐预期并在活动结束后及时修复。

启动优化方法论的应用实践古人云“纸上得来终觉浅，绝知此事要躬行”，前述的方法论讲得再详细再透彻也会与实际的落地存在隔阂，为了做到真正的学以致用，下文将细致讲解如何将启动优化方法论应用于实践之中。
理论分析的实践抖音在理论分析部分会对启动流程分别作全路径分析和耗时成因分析，前者用于发现全路径各个阶段的潜在耗时点避免疏漏，后者用于系统性地将各个耗时点归因从而引导我们找寻优化思路，关于这两部分的具体实践如下：
启动性能全路径分析：抖音的启动路径和大多数 APP 类似，整体分为两大阶段和两个间隙，它们按时间顺序排布为：Application 阶段、handle message 间隙、Activity 阶段和数据加载间隙，全路径各部分细分涵盖的内容如下图所示：

文章插图

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