引言：为什么你需要真正理解 Activity 启动流程

很多人能写 Activity，但一旦遇到“冷启动慢”“白屏”“偶现 onCreate 没走完就被杀”等问题，就只能凭经验猜。理解 Activity 启动流程不是为了背概念，而是为了把问题拆成链路，定位到具体节点。本文从工程实战角度，按“调用链 + 进程模型 + 生命周期 + 性能优化 + 常见坑”的完整结构展开，读完你能把启动问题讲清楚、做出可复现的优化。

一、启动流程总览：从 startActivity 到 onResume

整体链路可以概括为：startActivity → AMS/ATMS → Zygote → ActivityThread → Instrumentation → 生命周期。下面按真实调用路径拆解。

1. 应用侧入口：startActivity

无论你在 Activity、Service、Context 中调用 startActivity，最终都会走到 ContextImpl 的实现，并通过 Binder 调用系统服务。

context.startActivity(intent)
// ContextImpl.startActivity
// ActivityTaskManager.getService().startActivity(...)

这一步只负责“把请求交给系统”，真正的调度在系统侧完成。

2. 系统侧调度：ATMS/AMS 决策

Android 10 之后 Activity 调度主体是 ActivityTaskManagerService (ATMS)。它会判断：

• 目标 Activity 是否存在
• 是否需要新建 Task/TaskStack
• 目标进程是否已存在
• 是否需要走冷启动

如果进程不存在，就会触发 Zygote fork。

3. 创建进程：Zygote fork + ActivityThread

系统通过 Zygote fork 一个新进程，并在新进程里进入 ActivityThread.main()。这一步是“应用进程真正的入口”。

public static void main(String[] args) {
    ActivityThread thread = new ActivityThread();
    thread.attach(false, startSeq);
    Looper.loop();
}

注意：这里还会创建主线程 Looper，意味着 UI 线程消息循环已经启动。

4. 绑定系统与应用：attach 过程

ActivityThread.attach() 负责把应用进程注册到系统。系统会返回一些关键对象，比如 ApplicationInfo、LoadedApk，并完成 Application 初始化。

如果你在 Application 的 onCreate 做了大量初始化，这里会直接影响冷启动速度。

5. 创建 Activity：Instrumentation.newActivity

系统回调到应用进程，通过 Instrumentation 创建 Activity 实例，并调用生命周期：

Activity activity = mInstrumentation.newActivity(...)
activity.onCreate(...)
activity.onStart()
activity.onResume()

这一步是你最熟悉的生命周期阶段，但它是整条链路的最后一环。

二、关键对象与职责分工（非常重要）

理解这些核心对象能帮助你快速定位问题：

• ATMS/AMS：Activity 调度、进程管理
• ActivityThread：应用进程的核心调度器
• Instrumentation：负责创建 Activity/调用生命周期
• LoadedApk：应用包加载和资源管理

三、生命周期与启动类型的关系

Activity 启动流程会根据不同启动场景表现不同。

1. 冷启动（Cold Start）

• 进程不存在
• 必须走 Zygote fork
• Application/Activity 全部初始化

这是启动最慢的情况。

2. 热启动（Warm Start）

• 进程存在，但 Activity 不在前台
• 可能走 onRestart/onStart/onResume

3. 热恢复（Hot Start）

• Activity 在内存中
• 基本只走 onResume

四、冷启动优化的工程策略（重点）

冷启动优化不是“删代码”，而是拆分与延迟。

1. Application 初始化延迟

• 能延迟的初始化全部延迟
• 不要在 Application 中做网络请求

// 示例：延迟初始化
Handler(Looper.getMainLooper()).post {
    initSdk()
}

2. 首屏渲染优先级

先保证首屏渲染，再做次要初始化。比如：

• 首屏只加载必须数据
• 其他数据滚动加载

3. 资源加载优化

减少首屏 layout 复杂度，避免嵌套过深布局。图片尽量用占位图异步加载。

4. 严控主线程阻塞

冷启动最忌讳阻塞主线程。建议：

• 主线程只做 UI 相关
• IO/数据库放到后台线程

五、常见坑与排查思路

1. 白屏时间过长

• 原因：onCreate 中阻塞
• 解决：拆分初始化，异步加载

2. onCreate 没走完被杀

• 原因：内存不足或主线程卡死
• 解决：优化资源占用，减少大对象

3. 启动慢但 profile 不明显

• 可能是首屏 layout 过重
• 用 Layout Inspector 分析

六、性能测量与工具

没有测量就没有优化，建议用以下工具：

• Android Studio Profiler：监控 CPU/内存
• Traceview / System Trace：定位阻塞点
• adb shell am start -W：获取启动耗时

adb shell am start -W com.xxx/.MainActivity

七、工程师建议（我自己的实战习惯）

• 先跑通最小链路，再逐步加功能
• 冷启动优化一定要有指标
• 不要盲目清理代码，先测再动

结论

Activity 启动流程不是“理论题”，而是你解决启动慢、白屏、崩溃的底层工具。把链路拆清楚，才能真正做出可控优化。下一篇可以继续深入“Application 初始化最佳实践”或“冷启动优化的实战清单”。