Handler 与 ActivityThread 的协作机制

3 - Android, 3.1 - Framework, 3.1.2 - AMS 本文总阅读量次

在 AMS 管理 Activity 生命周期的过程中，Handler 扮演了“线程切换器”的关键角色。理解 ActivityThread 如何通过 Handler 接收并执行来自 AMS 的指令，是掌握 Framework 通信模型的核心。

1. 协作模型：从 Binder 线程到主线程

AMS 运行在 system_server 进程中，通过 IApplicationThread (Binder 接口) 向应用进程发送指令。

步骤 运行环境 执行动作
1. 跨进程调用 Binder 线程池 应用进程收到 AMS 的 Binder 调用（如 scheduleTransaction）。
2. 线程切换 Handler 发送消息 Binder 线程不直接操作 UI，而是将任务通过 H (Handler) 发送到主线程。
3. 消息排队 MessageQueue 任务作为 Message 进入主线程的消息队列，遵循优先级排序。
4. 执行任务 主线程 (Looper) Looper 取出消息并回调 handleMessage，最终执行 Activity 的生命周期。

2. ActivityThread 内部的管家：类 H

在 ActivityThread 源码中，定义了一个内部类 H，它继承自 Handler。它是应用进程中最重要的消息处理中心。

核心消息常量 (Message Type) 对应场景
EXECUTE_TRANSACTION Android 9.0+ 引入，统一处理绝大多数生命周期事务（Start, Resume 等）。
BIND_APPLICATION 应用进程启动后的初始化指令。
EXIT_APPLICATION 请求应用退出。
RECEIVER 广播处理指令。 
1
2
3
4
5
6
7
8
9
10
11
12
// ActivityThread.java 中的内部类 H
class H extends Handler {
    public void handleMessage(Message msg) {
        switch (msg.what) {
            case EXECUTE_TRANSACTION:
                final ClientTransaction transaction = (ClientTransaction) msg.obj;
                mTransactionExecutor.execute(transaction);
                break;
            // ... 其他消息处理
        }
    }
}

3. 同步屏障 (Sync Barrier) 在 AMS 场景下的应用

当 AMS 请求启动一个 Activity 或执行渲染任务时，为了保证 UI 能够以 60fps/120fps 的频率流畅刷新，系统会使用同步屏障机制。

概念 作用机制 在 AMS 场景的应用
插入屏障 在 MessageQueue 头部插入一个 target 为空的特殊消息。 当 Choreographer 接收到 VSync 信号，或者 AMS 触发界面刷新时发送。
优先异步 此时 Looper 会跳过普通消息，只执行标记为 isAsynchronous 的消息。 确保 UI 绘制任务、某些关键生命周期事务不会被队列中积压的普通消息（如日志、数据上报）阻塞。
移除屏障 渲染完成后移除，恢复普通消息的处理。 保证系统吞吐量与 UI 流畅度的平衡。

4. 总结：为什么要通过 Handler？

  1. 线程安全：Android 的 UI 控件是非线程安全的，必须保证所有对 Activity 状态的修改都在主线程完成。
  2. 异步缓冲：AMS 往往是“发后即忘”的异步调用。Handler 提供的消息队列可以缓冲来自系统的密集请求，防止应用进程因瞬间过载而崩溃。
  3. 优先级调度：配合同步屏障，Handler 机制能确保最重要的“显示”任务永远被优先执行。
3 - Android, 3.1 - Framework, 3.1.2 - AMS