自 Android 10 (API 29) 开始，Google 对原本庞大的 ActivityManagerService (AMS) 进行了结构性重构，将其核心的 Activity 管理职能抽离出来，成立了 ActivityTaskManagerService (ATMS)。

1. 为什么要进行拆分？

在早期的 Android 版本中，AMS 承载了太多的职责。这种“巨石”设计导致了严重的工程问题：

核心管理对象：Record 体系

为了实现职责分离，AMS 与 ATMS 分别维护了不同的核心数据对象：

2. AMS vs ATMS 职责对比

3. 架构演进的关键点

3.1 跨进程通信的变化

• Android 9 以前：App -> AMS (startActivity)。
• Android 10 以后：App -> ATMS (startActivity)。

3.2 内部协作流程

1. ATMS 负责判断 Activity 应该在哪个 Task 启动，并管理其生命周期状态。
2. 当需要启动一个新的进程来承载 Activity 时，ATMS 会回调 AMS 的 startProcessAsync 方法。
3. AMS 负责与 Zygote 通信并完成进程的创建。

4. 总结：一句话区分

• ATMS 是“Activity 管家”：只关心 Activity 怎么跳、怎么显示、怎么分组。
• AMS 是“应用管家”：关心进程还在不在、Service 跑没跑、广播发没发。

这种拆分使得 Android 系统在支持 多窗口模式 (Multi-Window) 和 折叠屏 (Foldables) 时，逻辑更加清晰和独立。

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

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

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

2. ActivityThread 内部的管家：类 H

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

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 的频率流畅刷新，系统会使用同步屏障机制。

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

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

在 Android 的系统架构中，AMS（System Server 进程）与 ActivityThread（应用进程）之间的通信是典型的 C/S 架构。AMS 作为服务端下发指令，ActivityThread 作为客户端接收并执行。

1. 通信架构：Binder 边界

AMS 并不直接持有 ActivityThread 对象，而是通过 IApplicationThread 这一 Binder 接口进行通信。

2. 指令接收流程：从 Binder 线程到主线程

当 AMS 发起一个指令（如启动 Activity）时，数据流转如下：

第一步：Binder 线程接收

AMS 调用 app.thread.scheduleTransaction(transaction)。此时，App 进程中的 Binder 线程池 会随机选择一个线程来执行 ApplicationThread 对应的接口方法。

第二步：向主线程分发

由于 Binder 线程不能直接操作 UI 或执行 Activity 生命周期，ApplicationThread 会通过内部类 H（Handler）将任务发送到主线程。

1
2
3
4
5

// ActivityThread.java 内部代码逻辑
public void scheduleTransaction(ClientTransaction transaction) {
    // 这里的 this 指向 H (Handler)
    sendMessage(ActivityThread.H.EXECUTE_TRANSACTION, transaction);
}

第三步：主线程消息循环 (Looper)

主线程的 Looper 不断从 MessageQueue 中取出消息。当收到 EXECUTE_TRANSACTION 时，回调 H 的 handleMessage。

第四步：执行具体逻辑

对于生命周期相关的指令，ActivityThread 会委派给 TransactionExecutor 执行，最终调用到 Activity 的 onCreate/onStart 等方法。

3. 核心处理中心：类 H

ActivityThread 内部维护的 Handler H 是所有系统指令的汇聚点。它处理的消息类型决定了应用的行为。

4. 协作机制总结

💡 面试要点：

1. ActivityThread 的主线程循环是什么？
   答：是 Looper.loop()，它不仅处理用户交互，还处理来自 AMS 的所有生命周期指令。
2. 为什么 ApplicationThread 里的方法不直接改 UI？
   答：因为 ApplicationThread 的方法运行在 Binder 线程 中，而 Android 的 UI 系统是非线程安全的，必须通过 Handler 切换到主线程。
3. Handler H 的作用？
   答：它是应用进程的“神经中枢”，负责将系统的异步调用同步化到主线程执行。

当 Activity 的启动请求进入 ATMS 后，最核心的逻辑就是：这个 Activity 应该放在哪个任务栈（Task）里？ 这涉及到对 LaunchMode、Intent Flags 以及 TaskAffinity 的综合判定。

1. 核心角色：ActivityStarter

ActivityStarter 是启动流程中的“决策者”。它负责解析启动参数，并调用 startActivityUnchecked 开始处理栈逻辑。

2. LaunchMode 与 栈分配逻辑表

3. Intent Flags 的影响

代码中通过 Intent.setFlags() 设置的参数优先级高于 XML 定义。

• FLAG_ACTIVITY_NEW_TASK：对应 singleTask 的基本行为，寻找或创建新栈。
• FLAG_ACTIVITY_CLEAR_TOP：如果栈中已存在该实例，销毁其上的所有 Activity。
• FLAG_ACTIVITY_REORDER_TO_FRONT：将已存在的实例移到栈顶，不销毁中间的 Activity。

4. 栈管理的关键步骤

1. findTask：根据 taskAffinity 和 Flags 寻找匹配的 TaskRecord。
2. computeStack：确定目标 Activity 应该落在哪个 ActivityStack（在 Android 10+ 主要是 DisplayContent 下的容器）。
3. resumeFocusedStacksTopActivities：将目标栈移到最前台，准备执行显示逻辑。

5. 调试技巧

使用以下命令可以实时观察栈的变化，这是理解栈管理逻辑的“神技”：

1

adb shell dumpsys activity activities

关注点： 寻找 TaskRecord 节点，查看其内部的 ActivityRecord 列表及其 intent 信息。

在启动 Activity 时，如果 ATMS 发现目标进程（ProcessRecord）不存在，就会触发进程创建流程。这是 Android 系统中典型的“按需启动”机制。

1. 触发点：AMS.startProcessLocked

当 ATMS 判定需要新进程来承载 Activity 时，会跨模块回调 AMS：

1
2
3
4
5

// 核心逻辑简述
if (app == null) {
    // 进程不存在，开始启动进程
    mService.startProcessLocked(processName, info, ...);
}

2. AMS 与 Zygote 的通信流程表

3. 为什么是 Socket 而不是 Binder？

这是一个经典考点。Zygote 使用 LocalSocket 监听请求而非 Binder，主要是为了规避 Fork 机制与多线程锁冲突 导致的死锁风险。在 fork 瞬间，子进程只会拷贝发起调用的线程，其他线程持有的锁将永远无法在子进程中释放。

4. 子进程的“觉醒”：ActivityThread.main()

当 fork 成功后，子进程会执行 ActivityThread.main() 方法，这标志着应用主线程正式开始工作：

1. **Looper.prepareMainLooper()**：初始化主线程消息循环。
2. attach：跨进程向 AMS 报告：“我启动好了（attachApplication）”。
3. BIND_APPLICATION：AMS 发回应用配置信息，App 开始创建 Application 实例并调用 onCreate。
4. **Looper.loop()**：主线程进入死循环，开始处理 AMS 发来的生命周期指令（如 LAUNCH_ACTIVITY）。

5. 总结

进程创建是一个“从 C++ 到 Java”的过程，也是“从系统服务到应用代码”的过程。掌握了从 startProcessLocked 到 attachApplication 的闭环，就掌握了 Android 进程管理的精髓。

WindowManagerService (WMS) 是 Android 系统中负责窗口管理的核心服务。与 AMS 相比，WMS 与图形显示、输入系统及 View 系统的交互更为紧密。设计一套科学的 WMS 学习路线，建议遵循“从基础支撑到核心模型，再到显示原理”的原则。

第一阶段：支撑系统（底层依赖知识）

在深入 WMS 源码前，必须掌握 WMS 运行的基础设施。

第二阶段：核心模型（窗口的骨架）

WMS 服务端通过一组对象来维护窗口的层级、属性和状态。

第三阶段：核心流程（窗口的诞生与消亡）

通过追踪一个 Activity 窗口从无到有的过程，理清 WMS 的运行逻辑。

第四阶段：进阶专题（高级显示控制）

了解现代 Android 在复杂显示场景下的处理机制。

💡 学习建议：

1. 结合 Winscope 工具：利用 Android 提供的 Winscope 录制并查看窗口层级和 Surface 状态，将抽象代码可视化。
2. 理解 Insets 机制：现代 Android 窗口管理很大一部分精力在于处理状态栏、导航栏、挖孔屏等带来的 WindowInsets。
3. 分层阅读：WMS 源码逻辑分散在 services 的核心包中，建议从 WindowManagerService.java 入手，先理清 addWindow 这一条主线。

当应用端调用 WindowManager.addView 时，窗口的添加流程正式开启。这是一个跨越应用进程与 WMS 服务端的重要 IPC 过程。

1. 应用端：ViewRootImpl 的建立

在 WindowManagerGlobal 中，每添加一个窗口都会创建一个对应的 ViewRootImpl。它负责：

• 触发第一次 requestLayout。
• 通过 mWindowSession.addToDisplay 向 WMS 发起跨进程调用。

2. 服务端：WMS.addWindow 核心逻辑

3. 核心对象关系图

App 进程 (ViewRootImpl) <— IWindowSession (Binder) —> SystemServer (WMS)

• WMS 持有 WindowToken (管理组)
• WindowToken 包含多个 WindowState (管理个体)

WindowManagerService (WMS) 是 Android 系统中负责窗口 management 的核心服务。它主要处理窗口的布局、显示次序、窗口动画以及输入事件的派发。

1. WMS 的职责

WMS 的主要工作可以概括为以下四个核心领域：

2. 核心类解析

理解 WMS 的源码，必须先搞清楚这几个核心类及其职责：

3. 窗口的层级管理 (Z-Order)

WMS 使用 WindowType 来区分窗口的层级。层级越高，显示在越上层：

4. 窗口添加流程简述

当我们在 Activity 中调用 setContentView 后，窗口诞生的核心步骤如下：

5. 接下来我们将深入探讨

• WMS 的启动流程
• Surface 的创建与渲染链路
• WMS 动画框架解析

窗口添加后，其大小和位置并非一成不变。每当窗口属性变化、输入法弹出或屏幕旋转时，都会触发 relayoutWindow。

1. 什么是 Relayout？

relayout 是 WMS 及其客户端（应用进程）最频繁的交互点。它主要完成：

• 尺寸计算：WMS 根据屏幕大小、Insets（状态栏等占位）计算窗口的最终 Frame。
• 配置同步：将最新的 Configuration（如横竖屏、语言）同步给应用。
• Surface 状态变更：控制 Surface 的显示、隐藏或尺寸调整。

2. 核心算法：窗口框架 (Frame) 计算

3. Insets 机制（现代 Android 重点）

现代 Android 不再简单地减去状态栏高度，而是使用 WindowInsets 机制。WMS 负责计算这些 Insets（如键盘、手势区域）并将其分发给 View 系统，从而实现沉浸式状态栏或避让输入法。

WMS 不仅管理窗口逻辑，还是图形渲染的“中转站”。它协助应用获取绘制所需的画布 —— Surface。

1. Surface 的本质

在 Android 中，Surface 对应 SurfaceFlinger 中的一个 Layer。它本质上是一块图形缓冲区队列（BufferQueue）的生产者端。

2. 创建流程：从 WMS 到 SurfaceFlinger

3. 渲染“三步走”

1. **申请 (Lock)**：应用通过 lockCanvas() 或 EGL 申请缓冲区。
2. **绘制 (Draw)**：应用调用 Canvas 或 GPU 绘图指令。
3. **提交 (Unlock & Post)**：将绘制好的缓冲区入队，通知 SurfaceFlinger 进行合成显示。