文章插图
在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 的预读来尝试优化 。
推荐阅读
- 抖音运营如何分析对标账号，对标账号我们都需要分析哪些数据
- 玩转抖音平台的算法推荐逻辑
- 抖音流量这么大，如何简单有效的获取精准客户？
- 抖音SEO是什么？揭秘抖音搜索算法工作原理和推荐算法
- 2021抖音电商年度数据
- 提高 JavaScript 性能的 12 个技巧
- 抖音账号无故被限流，你可能已经踩了这4个坑，建议自查！
- 新申请的抖音账号怎么上热门，怎么才能获得更多的流量推荐？
- 抖音新号0粉如何赚钱？
- 抖音账号被限流，原因为何？有哪些补救措施？
