爱奇艺 App 启动优化实践分享

性能优化一直都是各个 APP 推进中的重点、难点，爱奇艺 App 也不例外。在此之前，爱奇艺 App Android 版的启动速度虽然一直处于同类 App 领先的水平，但优势距离其他同类的 APP 距离一直很小。面对这一瓶颈，爱奇艺技术产品团队为爱奇艺 App 的启动优化搭建了专项团队。在各个团队的大力支持下，将启动时间由 1.5s 优化到了 0.5s，实现了巨大跨越，下文将分享爱奇艺 App 启动的优化实践。

本文长度为 2914 字，预估阅读时间 8 分钟。

凡事预则立，不预则废

关于 App 的启动优化, 大部分的技术同学第一反应是延迟执行任务，再通过做一些代码实现上的优化来提高代码的执行效率。爱奇艺 App 早期的优化策略也是如此：将某些启动阶段不必要执行的任务延迟到首页某个生命周期之后再执行，或是延迟固定时间之后再执行等等。

这一优化策略在前期的确有一些效果，但是后来就收益甚微了。爱奇艺 App（Android）经过多年的稳定迭代， 功能不断丰富，代码量也越来越庞大。启动阶段涉及了很多业务的初始化功能，业务之间又有着复杂的依赖关系，轻易变更代码执行时序可能会导致崩溃或者某些业务异常。之前简单的延迟优化策略已经很难再取得收益，一种全新的优化方案已经迫在眉睫。

工欲善其事，必先利其器

有没有一种工具能直接看到当前任务执行的瓶颈呢？做过 Android 性能优化的同学应该都会比较熟悉 Systrace 和 TraceView 这两款工具。但是这还不够，我们需要一款更为直观、便捷的工具。它能够把启动阶段代码执行的先后顺序、时间间隔、线程情况以及代码位置等信息直观的展示出来，让我们能一眼看出某一阶段的任务调度是否合理，然后再根据实际情况进一步做有针对性的优化。

但到目前为止，我们尚未发现业内有满足此需求的现成工具。然而在一年前，我们团队自主开发了一款 Lens 开发调试工具，它能够以 SDK 的形式接入任意的 Android 应用程序，可以提供任务分析、网络分析（抓包）、页面分析（视图拾取、视图层级等）、沙盒访问、快捷入口等等功能。于是我们团队经过讨论，决定用 Lens 来实现任务分析的功能，这样既能完成启动优化，又能进一步完善 Lens 的功能。经过我们团队持续不断的完善和优化，突破重重技术难关。终于实现了可以直接看见任务的执行状况的能力，就像医生拿到了病人的 CT 报告，精准优化已准备就绪。

优化前启动耗时与线程信息(Debug)

优化前启动任务情况(Debug)

优化前启动任务执行时序(Debug)

诊断：启动阶段有大量的线程启动，执行了大量的任务，并且主线程任务十分密集。

经过充分的思考后，我们团队给出了如下的优化方案：

• 任务化：将启动阶段的代码按照业务逻辑封装成独立任务，方便管理和调度。

• 并发：将启动阶段的任务尽量并发执行。

• 延迟：启动阶段只执行第一个页面渲染展示的必要任务，延迟的任务将在第一个页面渲染完成后再进行合理的调度触发。

• 兜底：设计兜底机制，保证程序稳定执行。

• 监控与优化：建立常态化监控机制，监测任务变化情况，实现精准优化。

由于启动阶段的任务之间存在相互依赖关系，被依赖任务会出现异步执行未完成而导致的崩溃问题。为了解决这一问题，一种基于依赖关系来动态调度任务执行的任务管理器——《TaskManger》被设计出来。

TaskManager（后文简称 TM）支持给任务设置执行条件，例如等待某个任务执行完成后或者某个事件发生后再开始执行；支持“关系与”依赖、“关系或”依赖，支持延时执行，支持把任务提交到主线程或者子线程执行等等。除此之外，任务之间还能传递数据，监听事件等等。

一、任务化

我们重新梳理了 Application 阶段的代码，并按照功能业务归类整理，提炼出了多个任务模块。例如，我们将播放器部分的初始化工作封装在 PlayerInitTask 类中。每个任务类都分为任务注册与任务执行两个部分，依据程序是否会启动页面展示，我们设置了不同的任务执行策略。

PS：灵活的任务执行时机设置也是 TM 的一大优点。

二、并发与线程收敛

在完成启动业务的梳理和重构之后，将可以在子线程中运行的任务提交到子线程中执行，将之前比较耗时的任务分拆为多个子任务，阻塞并发执行，从而尽可能的充分利用 CPU 的算力。

并且将启动阶段的任务都对接到了 TM 统一调度，避免其它线程抢占 CPU 资源以及一些不必要的系统开销问题，完成了启动阶段线程的收敛。通过采取这些措施启动阶段的线程数明显降低，主线程因为子线程抢占 CPU 资源而导致的执行效率过低的问题也得到了解决。

三、延迟

在启动阶段主要设置了两个事件：广告展示事件和首页展示事件。按照业务执行的必要性，我们把启动阶段不必要执行的任务分别延迟到了这两个阶段之后执行。任务之间也按照之前梳理的依赖关系，分别设置了相应的依赖条件，解决了因被依赖任务被延迟未执行而导致的崩溃或业务异常问题。TM 还 提供了一些运行监测机制，能有效避免循环依赖问题的发生。

由于 TM 的调度管理，这些任务在运行条件得到满足后会根据当前运行条件与设置的任务优先级等情况合理调度执行，不会出现大量任务同时并发执，从而导致页面卡顿的问题；

四、兜底

当任务延迟后，任务执行时机存在不确定性。这可能导致在业务需要时，一些初始化任务还没有执行完成的问题——TM 提供了任务兜底机制。

使用上面的 API 可以保证业务依赖的任务一定被执行，从而解决了因为“异步”与“延迟”可能给业务带来崩溃或者逻辑异常问题。

五、监控与优化

1）阻塞等待监控

由于 TM 提供了任务的兜底机制，理论上就会存在因业务需要而导致等待任务执行完成的场景产生。这种问题在低端设备上更为常见。为了解决这一问题，我们在 TM 中添加了任务等待监控功能，将其纳入常态化的监控中，并且成功发现了多项阻塞等待的问题。通过通知业务方进行逻辑优化，大大减少甚至避免了部分阻塞等待的问题，用户体验获得了更进一步的提升。

2）启动数据监控

我们将 Lens 的启动数据投递到后端，并且建立了启动分析日报机制。将启动过程分段，除了启动时间外，还投递了程序初始化阶段、页面创建阶段、页面渲染阶段的分阶段耗时数据，当某项数据明显劣化后，服务端就会发出预警。

3）历史版本启动任务对比分析

目前最新的 Lens 版本支持版本间启动任务对比分析功能，我们可以在界面上展示出两个版本之间的任务变化差异，例如新增任务、减少任务及运行耗时变化超出阈值的任务信息。通过分析这些变化的任务信息，就可以直接“约谈”相关业务方，进而快速的完成优化工作。

与此同时，我们团队还执行了一些其他的优化手段，例如推进代码执行效率的优化、提前加载一些重要展示数据等等。

总结

通过多个版本的迭代，完善了任务调度框架、启动任务常态化监控机制、任务分析功能等等。

优化后启动耗时与线程信息(Debug)

现已经优化到 500ms 以内，启动任务、启动阶段线程数也大幅度减少。在这次的优化实践工作中，Lens 与 TM 两个工具发挥了重要作用。关于 Lens 的细节，我们将在后续进一步为大家分享。