Android 启动性能全路径分析

利用X2C提升构建效率

app：onCreate

自定义View渲染优化

首页优化的主要场景

View渲染

内核加载完成：创建init

层级优化

fork出ActivityThead进程

数据加载

OpenDexFilesFromOat

在来到 Activity 阶段后，首先经历的是其onCreate生命周期，这里涵盖了首屏业务优化的主要场景也是开启异步并发的主要时机，在其中有个重要的 setContentView 方法会触发 DecorView 的 install，可尝试对 DecorView 的构建进行预加载；后续自然来到View 构建的阶段，该阶段在抖音上相当耗时，可采用异步 Inflate 配合 X2C（编译期将 xml 布局转代码）并提升相应异步线程优先级的方法综合优化；再来到View 的整体渲染阶段，涵盖 measure、layout、draw 三部分，这里可尝试从层级、布局、渲染上取得优化收益

DocorView构建预加载

ActivityThead：Main

handle Message

最后是首屏数据加载阶段，这部分涵盖非常多数据相关的操作，也需要综合性优化，可尝试预加载、缓存或网络优先级调度等手段

handleBindApplication

网络优先级调度

Linux系统

MulitDex 加载优化

UI 的 inflate 过程最大异步化

使用数据缓存

内核 阶段

数据预加载

在 Android 系统里面，zygote是一个进程的名字，Android是基于linux系统的，当你的手机开机的时候，Linux的内核加载完成之后就会启动一个叫“init”的进程，在Linux System系统中，所有的进程都是有init进程fork出来的。

离屏渲染

布局优化

Activity 生命周期

install Provider

异步并发的主要时机

异步 widget 框架

zygote进程（俗称受精卵开始分裂）

主线程消息调度优化

业务优化的主要部分：异步、按需加载、预加载的主要时机

handle 间隙

Bind Application

异步 UI 构建线程优先级提升到最高级

主线程消息监控及治理

数据加载 间隙

自己 的 sdk初始化

attachBase Context

View构建

在Application 阶段和 Activity 阶段之间往往会不可避免地被插入很多 post 到主线程的消息及相应待执行任务，这是拉长启动耗时的另一不可控问题点，需要加以监控治理或通过消息调度优化来尽量减小此间隙。

Activity 阶段

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

Application 阶段

init进程 fork zygote进程

最早预加载时机

google 的 sdk 初始化