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

Lock Wait 也是主要针对主线程，指其处于等锁状态，等待被其他线程唤醒或自己超时唤醒，导致这类耗时的问题种类多样，大体也是可以分为业务锁和系统锁，业务锁主要是被主线程等待的业务逻辑未能及时处理完，优化思路一般是移除主线程的锁等待逻辑或者加快被等待的业务逻辑的执行速度。系统锁主要有：String InternTable Lock，ClassLinker Lock，GC Wait Lock 等，目前抖音正在尝试优化这几类的锁耗时。

IPC 指进程间通信，操作系统大都含有相应的机制，Android 中所特有的 IPC 机制是 Binder，由于进行 IPC 调用往往需要等待通信结果本质上这也算是一种 Lock Wait，但 Android 特有 Binder 机制所以单独列出，这类耗时可采用减少或替代 Binder 调用等手段来优化。

综合前述的五大耗时成因，这里举一个分析启动阶段 UI 耗时成因的例子作为实践参考，根据 UI 界面的生命周期（一般划分）——UI 构建、数据绑定、View 显示三个阶段分别进行分析：

文章插图

在UI 构建阶段中首先要对界面布局的 xml 文件进行解析，这会导致 IO Wait 耗时，在接下来要解析 xml 文件中的 TagName 从而获取对应 View 的 class 会用到反射、创建各子 View 实例并生成 View 树又会用到循环递归，两部分都会增加 CPU Time 的开销。
然后是数据绑定阶段，该阶段主要分两部分，一部分是对数据做请求、解析、适配，另一是部分是将适配好的数据填充进 UI 中，前一部分往往会涉及到 Json 解析成 Data Class 实例，这里就可能涉及反射、循环遍历嵌套的数据类结构等增加 CPU Time 的操作。
最后是View 显示阶段，常见的 measure、layout、draw 三大渲染 View 的步骤就在其中，它们同样会产生递归遍历父子 View 的耗时，此外这里还涉及将应用层计算好的渲染 View 的数据传递给系统层做最终的像素点排布，那么必然又会产生 IPC 耗时。

从这个例子可见即使再复杂的场景只要我们进行细粒度的分析，都能将耗时点归入前述某一成因中。
现状分析的实践如前文方法论所述，现状分析包括线下 Profile 数据与线上监控数据的对照分析，综合这两部分可以明确切实影响大盘启动性能的普遍耗时点，从而确保要做的优化项是行之有效的。下面分别讲述这两部分数据的分析实践：
线下 Profile 数据分析：Profile 主要是指使用性能探测工具抓取应用启动路径各阶段的耗时和系统资源消耗情况，常见的开源 Profile 工具有 TraceView、Systrace、Android Profiler 等，这些工具各有优势但均不能完全满足抖音做线下 Profile 的需求（详见后文“启动性能优化工具”部分的讲解），为此，抖音自研了“新一代全能型性能分析工具 RheaTrace”满足了需求。通过该工具我们可以在线下抓取整个启动路径的 Trace 文件，其整体样式与 Systrace 一致，但是涵盖了更多的信息点，一个样例 Trace 文件如下图所示：

文章插图

这里需要注意抓取 Trace 一定要基于 release 包，debug 包中往往涵盖诸多调试逻辑可能影响启动性能，导致 profile 数据与实际使用情形存在偏差。在查看 profile 数据时，首要观察主线程，寻找其中不符合预期的耗时方法，抖音将主线程耗时在 5ms 以上的方法均认定为不符合预期；然后在所有不符合预期的方法中寻找 Top n 的耗时点，逐个分析耗时原因、寻找突破口；耗时原因需要结合方法实现逻辑以及诸多运行时信息综合分析（这里可以参考 google 官方文档“浏览 Systrace 报告”），需要关注的运行时信息有方法执行时段对应的 CPU 负载、线程状态的颜色标识值、锁信息、IO 耗时、Binder 调用耗时等，根据这些信息判定引起方法耗时的主要原因，再结合理论分析中不同阶段、不同系统资源类型探寻优化手段。
线上监控数据分析：这部分数据的分析主要是用作参照和补充，参照是指线下 Profile 数据分析出的耗时点要对照线上数据确认其在大盘中存在普遍耗时，补充是指线下 Profile 数据未能复现的耗时点可能存在于线上大盘中，这部分漏掉的耗时点需要在线下尝试复现、归因后实施优化。这里有个很重要的点是：该如何对线上的启动性能指标做监控，这是保障线上数据能真实反映用户体验并且与 QA（做竞品测试等）和业务方（判断业务需求是否影响启动性能等）达成一致的前提，下面将对这部分做详细阐述，分为启动性能指标的定义、统计和校准三部分：