📚 课程目录第4章 Activity启动流程源码分析

4. Activity启动流程源码分析

理解 Activity 启动流程，不能只停留在“调用 startActivity 就会打开页面”的层面。真正决定页面何时创建、在哪个进程创建、以什么生命周期顺序回调的，是一条横跨应用进程与系统进程的跨进程调用链。它从 Activity 的 startActivity 出发，经过 Instrumentation、AMS/ATMS，再通过 Binder 回调到应用进程的 ApplicationThread，最终由 ActivityThread 与 TransactionExecutor 驱动生命周期执行。

核心结论：Activity 启动不是一次函数调用，而是一次“客户端请求 → 系统服务调度 → 服务端决策 → 跨进程回调 → 客户端执行事务”的完整闭环。理解这条链，才能定位启动白屏、生命周期错乱、启动超时等问题。

一、整体调用链：两条 Binder 方向

Activity 启动流程可以拆成两个方向：应用进程向系统进程发起启动请求，系统进程完成调度后再回调应用进程执行。前者是客户端到服务端，后者是服务端到客户端。二者都依赖 Binder，但角色完全相反。

典型调用链如下：

Activity.startActivity()
  → Activity.startActivityForResult()
    → Instrumentation.execStartActivity()
      → ActivityTaskManager.getService().startActivity()   // Binder 跨进程
        → ATMS.startActivity()
          → ATMS.startActivityAsUser()
            → ActivityStarter.execute()
              → ActivityStackSupervisor / RootWindowContainer 调度
                → ApplicationThread.scheduleTransaction()   // Binder 回调
                  → ActivityThread.scheduleTransaction()
                    → TransactionExecutor.execute()
                      → ClientTransaction 中的 LaunchActivityItem
                        → ActivityThread.handleLaunchActivity()
                          → performLaunchActivity()
                          → handleResumeActivity()

这条链中最容易混淆的是：ATMS 并不直接创建 Activity 对象，它只负责决策与调度；真正执行创建、生命周期回调的是应用进程中的 ActivityThread。ATMS 通过 ClientTransaction 把“要执行什么”打包，再交给应用进程执行。

二、关键数据结构：请求、事务与记录

源码中大量类名容易让人迷失，抓住几个关键数据结构即可建立主线。

数据结构	所在进程	作用
ActivityStarter	system_server	解析 Intent、Flag、LaunchMode，决定如何启动
ActivityRecord	system_server	代表一次 Activity 实例在系统中的记录
TaskRecord / Task	system_server	描述任务栈及其中 Activity 的组织关系
ClientTransaction	跨进程传递	封装要在客户端执行的事务集合
LaunchActivityItem	跨进程传递	描述“启动 Activity”这一具体事务
ActivityThread	应用进程	应用主线程入口，负责调度与执行
TransactionExecutor	应用进程	按顺序执行 ClientTransaction 中的事务

其中 ClientTransaction 与 TransactionExecutor 是 Android 8.0 之后生命周期事务化的重要设计。ATMS 不再直接调用应用进程的各个生命周期方法，而是把 Launch、Pause、Resume、Stop 等动作封装成 Item，由 TransactionExecutor 统一执行。

三、从 startActivity 到 ATMS：请求如何发出

在应用进程侧，Activity.startActivity 最终会进入 Instrumentation.execStartActivity。这里会获取 ATMS 的 Binder 代理，并把调用者的包名、Intent、结果接收器等参数传入。

// 简化示意
Instrumentation.execStartActivity(
    Context who, IBinder contextThread, IBinder token,
    Activity target, Intent intent, int requestCode, Bundle options) {
    IApplicationThread whoThread = (IApplicationThread) contextThread;
    ...
    int result = ActivityTaskManager.getService()
        .startActivity(whoThread, who.getBasePackageName(), intent,
                       intent.resolveTypeIfNeeded(who.getContentResolver()),
                       token, target != null ? target.mEmbeddedID : null,
                       requestCode, 0, null, options);
    ...
}

注意这里的 whoThread 参数，它是应用进程的 ApplicationThread Binder 对象。ATMS 后续正是通过它回调应用进程。也就是说，启动请求发出时，应用进程已经把自己的“回调入口”交给了系统服务。

四、ATMS 内部：决策与调度

ATMS 收到请求后，会交给 ActivityStarter 处理。ActivityStarter 负责解析 Intent、检查权限、处理 LaunchMode、判断是否需要新建 Task、是否需要复用已有 Activity 等。随后通过 ActivityStackSupervisor 和 RootWindowContainer 完成栈与窗口容器的调度。

当 ATMS 决定要启动一个新的 Activity 实例时，会创建 ActivityRecord，并准备 ClientTransaction。此时系统进程不会直接 new Activity，而是把 LaunchActivityItem 放入事务中，再调用 ApplicationThread.scheduleTransaction。

ATMS 的职责是“决策与调度”，不是“创建与回调”。它决定启动哪个 Activity、放在哪个 Task、以什么模式启动；真正的对象创建和生命周期执行发生在应用进程。

五、ApplicationThread 与 TransactionExecutor：客户端执行

ApplicationThread 是应用进程在 system_server 中的 Binder 代理。ATMS 调用 scheduleTransaction 后，请求会跨进程回到应用进程的 ActivityThread。

// ActivityThread 简化路径
public void scheduleTransaction(ClientTransaction transaction) {
    ActivityThread.this.scheduleTransaction(transaction);
}

void scheduleTransaction(ClientTransaction transaction) {
    transaction.preExecute(this);
    sendMessage(ActivityThread.H.EXECUTE_TRANSACTION, transaction);
}

// TransactionExecutor
public void execute(ClientTransaction transaction) {
    final IBinder token = transaction.getActivityToken();
    executeCallbacks(transaction);
    executeLifecycleState(transaction);
    mPendingActions.clear();
}

TransactionExecutor 会按顺序执行 ClientTransaction 中的 Item。对于启动场景，最关键的是 LaunchActivityItem。执行到它时，会调用 ActivityThread.handleLaunchActivity，进而执行 performLaunchActivity 和 handleResumeActivity。

performLaunchActivity 负责创建 Activity 实例、调用 attach、创建 PhoneWindow、设置 WindowManager、调用 onCreate。handleResumeActivity 则负责让窗口可见、执行 onStart 与 onResume，并把 DecorView 添加到 WindowManager。

六、案例场景：一次冷启动的完整时序

假设用户在 Launcher 点击图标启动一个未运行的 App。此时应用进程不存在，系统需要先创建进程，再启动 Activity。

Launcher 调用 startActivity，请求进入 ATMS。
ATMS 发现目标进程不存在，先通过 Zygote 创建应用进程。
应用进程初始化 ActivityThread，并向 AMS 注册 ApplicationThread。
ATMS 将 LaunchActivityItem 封装进 ClientTransaction，回调 ApplicationThread。
ActivityThread 通过 Handler 切换到主线程，交给 TransactionExecutor。
TransactionExecutor 执行 LaunchActivityItem，触发 handleLaunchActivity。
performLaunchActivity 创建 Activity，执行 onCreate。
handleResumeActivity 执行 onStart、onResume，并添加窗口。

这也是冷启动耗时分析的核心路径：进程创建、Application 初始化、Activity 创建、窗口添加，每一段都可能成为瓶颈。

七、常见误区与复盘

误区一：认为 ATMS 直接创建 Activity。实际上 ATMS 只创建 ActivityRecord 和 ClientTransaction，Activity 对象由应用进程创建。
误区二：认为生命周期回调是直接函数调用。Android 8.0 后，生命周期通过 ClientTransaction + TransactionExecutor 事务化执行。
误区三：忽略 ApplicationThread 的 Binder 回调方向。它是 system_server 回调应用进程的关键入口，不是应用进程主动调用系统服务的通道。

复盘时可以用一张调用链图定位问题：如果日志停在 ATMS.startActivity，说明请求已到系统服务；如果停在 scheduleTransaction，说明系统已回调客户端；如果进入 handleLaunchActivity 后卡住，则问题多在应用进程的 onCreate、Application 初始化或窗口添加阶段。

把这条链记成四段：应用进程发起请求、ATMS 决策调度、ApplicationThread 跨进程回调、TransactionExecutor 执行事务。掌握这四段，再结合 ActivityRecord、ClientTransaction、LaunchActivityItem 等关键数据结构，就能在源码中快速定位 Activity 启动的每一个阶段。