Android Activity的启动流程

核心流程概览

整个过程可以清晰地分为三个大部分：

1. 应用进程内部处理：在你自己的 App 内发起请求
2. 系统进程处理：核心决策过程，由系统服务完成
3. 回到应用进程：执行最终的创建和生命周期回调

整个过程的核心在于 Binder 跨进程通信 (IPC)，因为你的 App 和系统服务（如 AMS）运行在不同的进程中

详细步骤分解

阶段一：从应用进程到系统进程 (startActivity -> AMS)

1）startActivity() 调用

• 无论是调用 Activity.startActivity() 还是 Context.startActivity()，最终都会走到 Activity 的重载方法
• 这里会开始收集一些信息，例如请求码 (requestCode)、是否要回调 (Binder)、启动选项 (Bundle) 等

2）经由 Instrumentation

• Activity 的 startActivity 方法并不会直接处理启动逻辑，而是将工作委托给一个名为 Instrumentation 的类
• Instrumentation 是一个“工具集”，它监控着应用与系统之间的所有交互。它的 execStartActivity() 方法是启动 Activity 的关键一步。在这里，Activity 的启动信息被封装

3）跨进程调用 ActivityTaskManagerService (ATMS)

• 重要更新：在 Android 10 (API 29) 及更高版本中，原有的 ActivityManagerService (AMS) 的许多职能（尤其是 Activity 和任务栈管理）被拆分到了一个的新服务 ActivityTaskManagerService (ATMS) 中。AMS 现在更侧重于四大组件和进程的宏观管理
• Instrumentation 通过 ActivityTaskManager.getService() 获取到 ATMS 的 Binder 代理对象
• 它调用 ATMS 的 startActivity() 方法，这是一个 跨进程调用 (IPC)。至此，执行逻辑从你的应用进程跳转到了系统进程 (system_server)

阶段二：系统进程内的决策与调度 (ATMS -> ActivityStack)

4）ActivityTaskManagerService (ATMS) 接收请求

• 系统进程中的 ATMS 接收到来自应用进程的启动请求

5）ActivityStarter 处理请求

• ATMS 并不亲自处理所有细节，而是将任务交给 ActivityStarter 类
• ActivityStarter 是启动 Activity 的“大脑”，负责所有的校验和决策逻辑，包括：
  ○ 权限检查：是否有权限启动目标 Activity？
  ○ Intent 解析：如果使用了隐式 Intent，通过 PackageManagerService 解析出具体的组件
  ○ 进程检查：目标 Activity 所在的应用进程是否已存在？
  ○ 创建或复用任务栈 (ActivityStack)：根据 launchMode、Intent 的 Flag 等参数，决定将新的 Activity 放入哪个任务栈 (ActivityStack) 的哪个位置
  ○ 生命周期处理：决定当前正在运行的 Activity 是否需要进入 onPause 状态
  ○ 日志记录 (Activity Starts Logging)

6）ActivityStack 与 ActivityRecord

• ActivityStack（或它的子类 Task）是管理 回退栈 (Back Stack) 的核心类。它内部维护着一个 ActivityRecord 的列表，每个 ActivityRecord 代表栈中的一个 Activity
• ActivityStarter 会操作 ActivityStack，将新的 ActivityRecord 添加到栈中合适的位置

7）ActivityStartController 与 ClientLifecycleManager

• 决策完成后，控制权回到 ATMS。ATMS 通过 ActivityStartController 和 ClientLifecycleManager 来安排后续的生命周期执行

8）跨进程回调应用进程

• 系统进程现在需要通知应用进程进行实际操作
• ATMS 通过 Binder IPC 回调到目标 Activity 所在的应用进程。这个回调的接收者是 ApplicationThread

阶段三：回到应用进程执行 (ApplicationThread -> onCreate)

9）ApplicationThread 接收回调

• ApplicationThread 是 ActivityThread 的一个内部类，它是一个 Binder 对象，运行在应用进程中。它的作用就是接收来自系统进程（如 ATMS）的指令
• 它接收到 scheduleTransaction() 调用，其中包含了启动 Activity 的指令 (LaunchActivityItem)

10）H (Handler) 处理消息

• ApplicationThread 将接收到的 Binder 调用转换成 Message，通过一个 Handler（名为 H）发送到应用进程的主线程消息队列中。这样确保了所有UI操作都在主线程执行

11）ActivityThread 处理指令

• 主线程的 H 处理消息，调用 ActivityThread 的 handleLaunchActivity() 方法。这里是真正创建 Activity 并执行生命周期的地方
• 具体步骤包括：
  ○ 创建 Activity 实例：通过 Instrumentation.newActivity() 和类加载器
  ○ 创建 Application 实例（如果尚未创建）
  ○ 创建 ContextImpl：这是 Activity 的上下文环境
  ○ 调用 Activity.attach()：将上下文、Window 等关键信息绑定到 Activity
  ○ 调用 Instrumentation.callActivityOnCreate()：进而调用 Activity 的 onCreate() 方法

12）后续生命周期

• 之后，系统进程会继续通过同样的 IPC -> Handler 机制，依次调度 onStart() 和 onResume() 等方法

流程图

总结与关键点

• 进程间协作：启动流程是应用进程与系统进程紧密协作的结果，通过 Binder IPC 进行通信
• 系统进程是大脑：系统进程（特别是 ATMS 和 ActivityStarter）负责所有安全和调度决策（权限、栈管理、启动模式等）
• 应用进程是执行者：应用进程在收到系统指令后，才真正执行创建 Activity 和生命周期回调的操作，且这些操作都在主线程完成
• Instrumentation：像一个“监控钩子”，贯穿整个流程，应用进程的每一步操作几乎都经由它
• ActivityThread 和 ApplicationThread：ApplicationThread 是 Binder stub，负责接收指令；ActivityThread 是主线程管理器，负责执行指令
• Android 10+ 的变化：记住 ActivityTaskManagerService (ATMS) 接管了具体的 Activity 管理任务，这是理解新版本源码的关键