启动流程的宏观架构：从点击图标到首页展示

做启动优化这么多年，我见过太多团队一上来就盯着某个函数死磕。其实，你得先看清全局。今天我们就聊聊启动流程的宏观架构——说白了，就是从用户点下图标那一刻，到首页完全展示，这中间到底发生了什么。

应用启动的完整生命周期

我把启动过程拆成五个阶段。你想想看，每个阶段都有它的瓶颈点。

阶段	时间范围	核心事件
T0 - 用户触发	0ms	点击图标、冷启动/热启动判定
T1 - 进程创建	0~50ms	Zygote fork、创建主线程、绑定Application
T2 - 应用初始化	50~500ms	Application.onCreate、ContentProvider、依赖注入
T3 - 页面构建	500~800ms	Activity.onCreate、布局解析、第一帧绘制
T4 - 首帧展示	800~1200ms	onResume、布局完成、用户可交互

系统内核态与用户态的分工

这里有个很多人容易忽略的点——启动过程其实横跨了内核态和用户态。我刚开始做优化时，也以为只要管好自己的代码就行。后来发现，内核态那部分才是真正的「暗坑」。

内核态（Kernel Space）

• 进程创建：Zygote 进程 fork 出应用进程，涉及内存拷贝、文件描述符继承
• 内存映射：加载 dex/so 文件到内存，建立页表映射
• I/O 调度：读取磁盘上的代码和数据，涉及 page cache 命中率
• CPU 调度：主线程优先级、时间片分配、大核/小核调度策略

用户态（User Space）

• Framework 层：ActivityManagerService、WindowManagerService 的调度
• 应用层：Application、Activity 生命周期回调、业务初始化
• UI 层：布局解析、测量、布局、绘制、渲染合成

启动流程中的关键阶段

我们把启动过程再拆细一点。嗯，这里要注意，每个阶段都有它独特的优化手段。

1. 加载阶段（Loading）

这个阶段主要做两件事：加载代码和加载资源。说白了，就是从磁盘读到内存。

• Dex 加载：系统会把 APK 中的 classes.dex 映射到内存。如果用了多 dex，还要加载 secondary dex
• So 加载：System.loadLibrary 会触发动态链接器的符号解析
• 资源加载：Resources 和 AssetManager 的初始化，涉及大量 XML 解析

// 加载阶段的典型耗时分布
// 我建议你在启动时用 systrace 抓一下
// 重点关注：dex2oat、page cache miss、so 加载

// 伪代码示例
public class MyApplication extends Application {
    @Override
    public void onCreate() {
        // 这里不要做任何 I/O 操作
        // 我曾经见过有人在这里读 SharedPreferences
        // 结果导致启动慢了 200ms
        super.onCreate();
    }
}

2. 初始化阶段（Initialization）

这是最容易被「塞东西」的阶段。Application.onCreate 里，各种 SDK、依赖注入框架、数据库初始化全堆在这里。

我个人的习惯是，把初始化分成三类：

• 必须同步：崩溃收集、日志系统、核心路由表
• 可以异步：推送、统计、广告、热修复
• 可以懒加载：图片缓存、数据库连接、网络库

3. 布局阶段（Layout）

Activity.onCreate 里调用 setContentView，然后系统开始解析 XML 布局文件。这个过程涉及：

• XmlPullParser 解析：逐行读取 XML 节点
• View 对象创建：通过反射调用构造函数
• 属性赋值：解析 style、theme、属性值

你想想看，一个复杂的首页布局，可能有几百个 View 节点。每个节点都要反射创建，这能不慢吗？

4. 渲染阶段（Rendering）

布局完成后，进入 Measure -> Layout -> Draw 三部曲。这里我重点说一个很多人忽略的点：

渲染阶段的瓶颈通常在于：

• 过度绘制：背景层叠、不必要的 View 层级
• 复杂布局：RelativeLayout 嵌套、ConstraintLayout 约束过多
• 图片解码：首屏图片的 BitmapFactory 解码耗时

宏观架构全景图

下面这张图，是我自己总结的启动流程宏观架构。每次做优化前，我都会先对照这张图，找到当前最耗时的阶段。