作者：抖音根底技术团队
起源：字节跳动技术团队

启动性能是 APP 应用体验的门面，启动过程耗时较长很可能导致用户应用 APP 的趣味骤减，抖音通过对启动性能做劣化的 AB 试验也验证了其对于业务指标有影响显著。抖音领有数亿的用户，启动耗时几百毫秒的增长就可能带来成千上万用户的留存缩减，因而，启动性能的优化成为了抖音 Android 根底技术团队在体验优化方向上的重中之重。

本文基于过往对抖音 Android 客户端做启动性能优化的实战经验总结提炼出普适性的方法论，并将该过程中积淀的工具加以分享，心愿能给大家带来一些新的思考。

如果你要负责优化抖音的启动性能，你会怎么去布局整体的优化计划？你可能会一下子想到很多方面的细节点，比方：要优化主线程耗时、要缩小布局层级、要对某些启动工作做按需加载或预加载、要防止主线程 IO、要对线程应用进行优化、还要有剖析工具帮忙定位性能问题等…

然而，该如何系统性地把这些细碎点组织起来并依照肯定的章法来落地启动优化呢？此时，须要咱们在具体细节点之上有进一步的问题合成与深刻思考，最终造成一套 残缺的方法论 ，不仅能笼罩所有细节点，还能切实领导在实战中达成启动优化的成果。切实有效的方法论必然是从实战中通过千锤百炼能力造成的，而抖音宏大的用户基数又进一步保障了方法论的 可行性与普适性。那么接下来让咱们带着前述问题来看抖音的启动优化方法论是怎么的又是如何利用于实战之中的。

启动优化方法论

抖音的启动性能优化方法论分为五局部，别离是：实践剖析、现状剖析、启动性能优化、线上验证与防劣化。

这五局部间存在显著的先后顺序，又能闭环达成可继续的启动性能优化，上面将对这五局部做具体论述：

实践剖析

实践剖析放在最先是为了从一开始就防止让视线受到限制，很多同学往往一开始接手启动优化就容易陷入对各种现状细节的剖析，拘泥于全面的潜在可优化点，这样就难以做到对 全局和优先级的把控，所以，咱们应该首先跳出现状，从更加全局的视角来思考整体优化的指标和策略。这里能够利用特斯拉创始人——埃隆·马斯克所推崇的“第一性原理”思考法：

“通过第一性原理，把事件升华到最基本的真谛，而后从最外围处开始推理。”

基于此，咱们在做启动优化的实践剖析时能够从更根源的角度登程做到全局思考，比方抖音会做从过程创立到页面展现的 全启动门路分阶段耗时剖析 、还会依照耗费的系统资源类型做 耗时成因剖析 ，通过这种极致的耗时剖析能够带来极致的优化策略，此外，从 全门路 登程还可能发现容易漠视的问题、摸索优化的极限。

现状剖析

在实现实践剖析后，咱们根本具备了全局的视角，并且也大抵分明了整体的优化指标和策略，接下来就要基于此来做现状剖析从而清晰实现目标的具体门路：

• 首先应用 profile 工具对可优化点进行摸底：其实不合理的高耗时点就是潜在的优化点，并能依照前述的实践剖析纳入一个或多个耗时成因中；
• 而后联合线上的指标数据确定最终优化方向：线下摸底的潜在优化点要联合其线上打点确认是否为广泛耗时，再依据耗时成因明确大抵的优化思路、施行老本和预估收益。

在这部分须要尤其留神三点：优质的 profile 工具 （这里举荐应用同样来自根底技术团队的“ 新一代全能型性能剖析工具 ”）、 线下 trace 联合线上监控综合剖析、依据投入产出比评估施行优先级，这三点是保障切实有效获得启动优化收益的要害。

启动优化

在实现了实践和现状剖析后，就能够依据布局的门路来施行具体的启动优化项了。在施行过程中，次要思考主线程优化、后盾线程优化和全局优化三个维度：

• 主线程耗时优化 须要在启动全门路各阶段中细化具体的耗时成因，如：CPU Time、CPU Schedule、IO wait、Lock wait 等，实现耗时归因后能够应用逐渐降级的优化策略来一一击破：对于首屏所必须的耗时逻辑做侧面优化（可应用缩减耗时逻辑、异步并发、提早加载等伎俩）、对于非首屏必须的耗时逻辑做按需加载（须要架构优化的根底）、对于优化后仍存在耗时的逻辑尝试做业务降级（大都有损需评估全局收益）；
• 后盾线程优化 策略与主线程相似，在此基础上还能够施行后台任务缩减、线程收敛、开启多过程等优化措施；此外，主线程和后盾线程均存在较多启动工作且彼此间可能存在关联，因而，能够对全局的启动工作做依赖关系梳理并施行精细化的工作重排，旨在缩小依赖工作间的期待耗时；
• 全局优化 次要是指业务无关的通用的全局优化策略，如虚拟机层面或 IO 层面的优化等。

线上验证

在实现了具体的优化项施工后，就来到了线上验证大盘收益的阶段。这个阶段有三点须要留神：

• 线下的优化肯定要有线上的指标反馈，线下的优化项因为设施或操作习惯差别往往难以评估是否具备广泛影响，只有当相应的线上指标获得侧面反馈后能力验证拿到了无效的优化收益；
• 线上指标须要联合均值与分位值综合来评估，只关注启动耗时的均值往往会覆盖低分位设施的现状，这部分设施可能占比不高，对均值影响无限，但抖音宏大的用户基数乘以该比例仍旧是不小的数量，为了保障该局部用户的启动性能体验，抖音个别会分 50%、70%、90% 三个分位值来评估指标；
• 在验证收益时通过 AB 试验达成，这样做不仅能控制变量确保优化项的严格无效，还能借此来察看性能优化所带来的业务指标收益，这些都能够作为布局后续启动优化方向的参考领导。

防劣化

在线上验证优化措施获得切实收益后，并不是高枕无忧了，持续保持住优化成果 才算残缺达成了启动性能优化的目标。其实不仅是启动优化，整个性能优化畛域都是围绕着“攻 ”和“ 守”来开展的，“攻”即为前述的剖析与优化，而“守”则是 避免劣化 ，在防劣化方面大家往往不会像优化的方面那么器重，但实际上能避免劣化是可继续获得优化成果的前提（否则新的优化成果会用于补救劣化甚至入不敷出），并且 防劣化相比于优化是更能长久无益的。

抖音启动性能防劣化的过程分为了三个期间，不同期间有不同的体现与应答伎俩，这很可能是大多数 APP 优化启动性能都要经验的，这里提炼进去以供参考：

• 疾速降落期：此时个别位于启动优化的初始阶段，优化空间很大，随同有小幅度的劣化但往往都能被更大幅度的优化对消且还仍有收益，这时应该抓大放小，依照更高投入产出比的策略重点推动优化，同时也抽出少部分精力治理修复成本低的劣化。
• 瓶颈期：到了该期间绝大部分优化收益曾经拿到，想进一步做到优化往往须要投入更多老本，且优化幅度无限，整体的投入产出比不高，同期还会随同有中小幅的劣化，此时须要建设欠缺的线上线下监控体系，及时发现并修复劣化，此外还要通过架构革新从源头上限度劣化的产生，综合保障优化的收益不会被劣化对消。
• 劣化期：这个期间往往呈现在年关或重要节日期间，这类工夫点往往有重要且紧急的流动我的项目上线，泛滥关联方面均要为其开绿灯，启动性能指标也不例外，为了保障流动成果可能要退出若干耗时的主线程启动工作，所带来的的劣化幅度往往比拟大，此时须要对齐预期并在流动完结后及时修复。

启动优化方法论的利用实际

古人云“纸上得来终觉浅，绝知此事要躬行”，前述的方法论讲得再具体再透彻也会与理论的落地存在隔膜，为了做到真正的学以致用，下文将粗疏解说如何将启动优化方法论利用于实际之中。

实践剖析的实际

抖音在实践剖析局部会对启动流程别离作全路径分析和耗时成因剖析，前者用于发现全门路各个阶段的潜在耗时点防止疏漏，后者用于系统性地将各个耗时点归因从而疏导咱们找寻优化思路，对于这两局部的具体实际如下：

启动性能全路径分析：抖音的启动门路和大多数 APP 相似，整体分为两大阶段和两个间隙，它们按工夫程序排布为：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，上面别离对各成因进行分析：

• 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 文件，后续能够间接 load 这个 image 文件，省去了 Link 过程；Init，类的初始化。
• CPU Schedule 在剖析时次要针对主线程，是指主线程处于可执行状态但获取不到 cpu 工夫片，这类耗时可能和线程调度等无关，最终导致调配给主线程的 cpu 工夫片不足以及时处理完其内工作。因为主线程的线程优先级比其余线程的优先级要高很多，通常影响并不大，事实上抖音做了线上用户的启动耗时统计，这部分的耗时占比也是不大的。不过有一个场景须要关注，就是渲染，渲染是须要 RenderThread 提交 GPU 的渲染命令，而 RenderThread 并没有主线程那么高的优先级，因而比拟容易受 CPU 的负载的影响，导致渲染耗时，这个对于启动来说影响并不算大，启动只有一次首页的渲染，占整体工夫的比例不算大，但对于晦涩度的影响就会比拟大。这类耗时的优化次要还是从升高 CPU 的负载的角度思考，比方业务降级、业务打散等伎俩。抖音还通过对 RenderThread 优先级的晋升优化，拿到了不错的收益。
• IO Wait 指产生了 IO 操作须要期待 IO 返回后果，这类耗时可能产生在读取资源和文件，类加载，甚至在内存不足时的 PageFault 都会导致 IO Wait。Resources 的相干的操作耗时，次要是须要从 apk 里读取资源文件，优化策略能够有预加载、资源重排、资源异步加载等。类加载的 IO Wait 和 Resources 相似，也能够通过类的重排、预加载等优化计划。文件读写导致的 IO Wait 又分为业务文件和系统文件，业务文件指业务逻辑的读写文件，个别都能够通过异步来解决，而系统文件的例子是 dex 的读写，抖音的 IO Wait 很大一块是它奉献的，目前的思路还是做 dex 的重排和 IO 的预读来尝试优化。
• 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 耗时成因的例子作为实际参考，依据 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（做竞品测试等）和业务方（判断业务需要是否影响启动性能等）达成统一的前提，上面将对这部分做具体论述，分为启动性能指标的定义、统计和校准三局部：

• 启动性能指标定义：启动指标定义次要在于如何确定启动门路的终点与起点。终点的备选项有下图中的三个点以及 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 拉起、启动期间退后台、新用户启动等场景进行过滤或离开统计。

启动优化的实际

在做完实践剖析与现状剖析后，咱们根本对全局待优化点及其大抵优化方向会产生整体的认知，在开始落地各个优化措施之前还有很重要但往往会被疏忽的一步——按优先级排布优化项、制订整体优化计划，这一步在很大水平上制约着后续启动优化的收益预期与停顿把控，这两点对于按时达成启动优化的终极目标都至关重要。前述中提及了对“优先级”的把控，这点是制订整体优化计划的重中之重。

从抖音启动优化实际总结来看比拟好的优先级策略是依照“投入产出比”来排布优化项，顾名思义：投入人力越少但优化幅度越大的优化项越应该排在后期，因为所有的性能优化历程都势必会经验从高收益到低收益的变动，那么相应的在排布优化项的前后程序时也需适应此法则，最终出现的态势即为：后期以小老本疾速升高大盘启动耗时，前期逐步提高投入冲破各个瓶颈型耗时点（更前期大规模重构仅能缩小几十毫秒启动工夫的情景也应在预期之内），全过程同期增强防劣化机制，最终做到可继续优化。

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

• 侧面优化：删减非必要的启动逻辑、开屏页与首页 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 天后才进行试验的数据分析并产出论断，这样能够基本保障所有相干指标的稳固及相信。

防劣化的实际

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

防劣化的有几个难点：一是 劣化检测的准确率和召回率 ，为了更多更精确的发现劣化；二是 劣化的精确归因 ，发现劣化之后，如果不能精准的指出劣化的起因，须要投入比拟多的人力资源和工夫定位劣化起因，影响劣化解决的效率；三是 劣化的修复，如果是比较严重的劣化，能够采纳阻塞发版限期解决的形式，是比拟容易推动解决的。然而从抖音的实际来看，当启动优化到了深水区之后，优化的速度曾经比拟迟缓，须要关注几十毫秒级别的劣化了，假如咱们解决了一二两个难点，发现了这些轻微的劣化，然而如何推动业务去解决这些小劣化也同样是一个难题。咱们须要可能量化出这些劣化对业务的影响，针对不同的劣化量级，和业务对齐优先级，确定规范的劣化修复流程，才可能保障劣化不会被带到线上影响大盘用户。

防劣化是一个长期的工作，抖音投入曾经有一年多了，目前整体成果还不错，在这个过程中也积攒了比拟多的教训，之后会专门写一个抖音的防劣化系列文章来给大家介绍咱们的技术成绩。

启动优化工具

古人云“工欲善其事必先利其器”，在启动性能优化畛域也是一样，咱们不仅须要趁手的工具来定位优化耗时问题，还须要尽量自动化的工具来继续发现劣化问题，也就是说整个启动优化在“攻”和“守”的两大方面均须要工具的辅助。那么上面将针对这两局部的工具别离进行介绍及分享抖音在启动优化工具方面的摸索：

线下剖析工具

这部分次要针对业界常见的 APP 性能探测工具进行基本原理解析及优缺点比照，具体蕴含的工具有：TraceView、CPU Profiler、Systrace，此外还将提及抖音自研的“新一代全能型性能剖析工具 RheaTrace”：

• TraceView：Instrumentation 模式下采纳 AddListener 的形式注册 MethodError、MethodExited、MethodUnwind 的回调来采集办法起止工夫；Sampling 模式下应用一个 SamplingThread 定时主权线程堆栈，通过对此的堆栈比照近似确定函数的进入和退出工夫；尽管是官网提供的工具，但两种模式自身都存在比拟大的性能损耗，可能带偏优化方向；
• CPU Profiler：整体通过 JVM Agent 实现，具备实现办法调用栈输入，且反对 Java、C/C++ 办法的耗时检测，上手比较简单，但其同样存在性能损耗较大的问题，且个别仅用于 debug 包，release 包须要额定增加 debuggable 的配置；
• Systrace：基于 Android 零碎层的 Atrace 实现，Atrace 又基于 Linux kernal 层的 ftrace 实现，ftrace 在内核中通过函数插桩获取耗时；其本身性能损耗比拟低、数据源丰盛且具备较好的可视化页面，但其默认监控点较少，在 APP 自有代码中的监控点须要手动退出，比拟麻烦；
• RheaTrace：这是抖音基于字节码插桩联合 Systrace 及 Atrace 自研的工具，其具备主动退出监控点、各类耗时信息全面、性能损耗低等特点，是抖音日常在线下施行性能优化时首选的工具，其细节详见前述公众号文章，这里不再赘述。

RheaTrace 目前是抖音性能优化同学的次要工具，它不仅仅是一个工具，也是一个平台。除了 Systrace 自带的性能数据之外，咱们减少了 业务的函数耗时插桩的数据 ，能够更全面地对耗时进行剖析。然而这些数据还不够，咱们反对以插件的模式，减少本人定制的数据，比方为了优化 IO 的耗时，咱们通过 hook 减少了更精细化的 IO 的信息，辅助定位 IO 的耗时问题；抖音的类加载耗时也是有些重大，咱们也 hook 了类加载，减少了类加载的性能数据。咱们要极致地优化 抖音启动工夫，以上这些数据是不够的，还有锁、View 耗时信息等相干数据补充，给性能优化的同学提供全方位的性能剖析工具。

除了 RheaTrace 之外，还有一些特定场景的小工具，比方 线程剖析工具、内存剖析工具、高频函数剖析 等。因为篇幅无限，就不在这里一一介绍，前面会有专门的系列文章来介绍。

线上监控工具

下面介绍启动优化方法论的时候咱们提到了，不能只是看线下的性能剖析，线下的剖析后果并不能齐全代表线上大盘用户的状况。咱们分析线上的性能数据，一方面可能验证咱们的线上优化成果，另一方面可能从线上多个维度的数据里领导后续的优化方向。

线上监控工具和线下的差别点次要在 低性能损耗和兼容性 ，咱们将 RheaTrace 做了革新，使其可能满足线上的监控要求。 性能损耗 上，咱们将监控的性能损耗管制在 1% 以内，包大小管制在 200KB 以内，根本实现了线上全量用户的启动耗时监控。通过启动门路的全量插桩，能够针对启动门路的各个阶段进行监控，一是能够发现线上用户哪些工作比拟耗时，能够针对性的优化，让更多用户受害；二是能够监控线上的启动工作，如果产生了耗时减少，那么阐明有劣化，这比监控到启动工夫的劣化，要更容易定位到起因。除了线上的全量慢函数监控之外，咱们的线上启动监控还会细化 IO、锁、GC 等多种维度的耗时数据，帮忙定位线上为什么耗时慢，提供新的优化方向。

总结一下线上启动监控工具的思路就是：将线下的性能剖析数据，低损耗的移植到线上，察看线上用户的性能数据，线上线下相结合的剖析启动耗时，为启动优化提供优化方向领导。

启动性能优化之路去向何方

看了上文对于启动性能优化如此多的实践与实际，想必你曾经意识到启动优化之路注定是不会平庸的，抖音在这条路上摸索了 2 年之久且仍未达到止境。在这条路上势必会经验后期的坦途、中期的迷茫与前期的瓶颈，但无论如何都要始终动摇地走上来，因为只有业务还有一天在迭代那么 启动性能就有一天存在挑战的可能，所以启动优化之路的将来必然是无止境的。

既然如此，那么咱们的重点就应该从 何时能力走完这条路 转移到 如何走得更精彩 之上，甚至到最初可能做到把控这条路的走向，这或者也能算作另一种意义上的走完启动优化之路，那么什么才算走得更精彩以及把控路的走向呢？

迷茫时慢下步子再剖析全局的耗时点寻找到新的优化策略、遇到瓶颈时先临时放缓追赶指标尝试从代码重构上开掘深层的收益、一直开辟跨畛域（如端上智能降级）联合的优化方向……这些或者都能称作是一种精彩，并且会因人而异，最终，当这种精彩累计得足够多之时咱们很可能会发现启动优化之路上已知的所有岔路口全被走了个遍，同期 APP 的启动性能也很可能曾经达到了再优化也没什么显著业务收益的境地，并且呈现的任何劣化点都能及时被解决掉，那么这时不出意外的话，启动优化之路走向的把控权曾经尽在你手中了。