不止是“大管家”：从 AMS 的“分家”史，看现代 Android 架构的演进曾经无所不能的“大管家” AMS，在现代

一句话总结：

曾经无所不能的“大管家” AMS，在现代 Android 系统中已“分家”。它将 Activity 和任务栈的管理权交给了新成立的 ActivityTaskManagerService (ATMS)，自己则更专注于进程管理。理解这一“权力交接”，是看懂现代 Android 运行机制的关键。

在 Android 9.0 及以前的漫长岁月里，AMS 确实是系统的绝对核心，一个大权独揽的“管家”。它的职责几乎涵盖了应用层的所有动态行为，正如你的文章所出色描述的：

这个经典的、单一核心的 AMS 模型，为我们理解 Android 的基础运行原理打下了坚实的基础。但随着系统变得日益复杂，这位“大管家”也变得不堪重负。

从 Android 10 开始，Google 对 AMS 进行了大刀阔斧的架构重构。其核心动机源于现代软件工程思想：

“分家”之后，原 AMS 的权力被重新分配，形成了一个协同工作的“董事会”。

核心职责：
- 进程管理 (Process Management): 这仍然是 AMS 的绝对核心。它负责应用的进程创建（通过 Zygote）、销毁、优先级判定和 OOM Killing。它维护着系统的 LRU 进程列表。
- Service 管理: 负责 Service 的启动、绑定和生命周期。
- Broadcast 管理: 负责广播的分发。
- ContentProvider 管理: 管理 ContentProvider 的生命周期。
现在的定位： 更偏向于一个后台资源管理者。

核心职责：
- Activity 生命周期管理: 所有 Activity 的 onCreate, onResume, onPause 等状态流转，现在都由 ATMS 负责调度。
- 任务栈 (Task) 与返回栈 (Back Stack) 管理: Activity 的组织、排序、切换以及用户按返回键的逻辑，完全由 ATMS掌控。
- 启动模式 (Launch Mode) 处理: standard, singleTop 等复杂的启动行为由 ATMS 解析和执行。
现在的定位： 前台界面导航和状态的最高管理者，与 WMS 合作极为紧密。

当用户点击图标时，一场由“董事会”协同指挥的戏剧上演了：

Launcher -> ATMS: Launcher 通过 Binder 通知 ATMS：“用户想启动 MainActivity”。
ATMS 内部决策: ATMS 检查权限、解析启动模式、确定目标任务栈。
ATMS -> AMS: ATMS 发现目标应用的进程不存在，于是通过内部接口请求 AMS：“请为这个应用启动一个进程”。
AMS -> Zygote: AMS 作为“人事总监”，执行它的核心职责，命令 Zygote fork 一个新进程。
ActivityThread -> AMS: 新进程的 ActivityThread 启动后，通过 Binder 向 AMS “报道”，注册自己。
AMS -> ATMS: AMS 通知 ATMS：“进程已准备就绪”。
ATMS -> ActivityThread: ATMS 作为“运营总监”，正式下达指令：“现在，请创建并启动你的 MainActivity”。
ActivityThread -> WMS: Activity 窗口创建后，会向 WMS （窗口总监）注册，请求一块显示区域。

结论： 在现代系统中，AMS 不再直接指挥 Activity 的创建，而是退居幕后，成为了一个被 ATMS 调用的、更底层的**“进程提供者”**。

职责	经典模型 (Android 9 及以前)	现代模型 (Android 10 及以后)
Activity/任务栈管理	AMS	ATMS (ActivityTaskManagerService)
进程管理	AMS	AMS (核心职责保留)
Service/Broadcast 管理	AMS	AMS (逐步模块化中)
启动流程主导者	AMS	ATMS (AMS 变为被调用方)

理解从“大管家” AMS 到“董事会”协同治理的演变，不仅是了解一个技术细节的更新，更是洞察整个 Android Framework 模块化、精细化、高内聚架构演进方向的钥匙。

不止是“大管家”：从 AMS 的“分家”史，看现代 Android 架构的演进