利用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 初始化
