Android 的 AMS（Activity Manager Service）是 Android 系统中的核心服务之一，负责管理整个应用生命周期、任务栈、进程和四大组件（Activity、Service、BroadcastReceiver、ContentProvider）的运行。它运行在系统进程 system_server 中，是 Android Framework 层的关键服务。
1 AMS 的基本职责
AMS 是 Framework 层的一个系统服务，作用相当于整个应用生命周期的大管家，主要负责
| 主要功能 | 说明 |
|---|---|
| Activity 生命周期管理 | 启动、暂停、停止、销毁 Activity |
| 进程管理 | 创建、绑定、终止应用进程 |
| Service 管理 | 启动、绑定、停止服务 |
| Broadcast 管理 | 注册、发送、分发广播 |
| 任务栈管理 | 管理多个任务栈（Task）和返回栈（Back Stack） |
| ANR 检测 | 监控是否发生 ANR（Application Not Responding） |
| 权限检查 | 检查组件是否具有相应权限 |
2 AMS 所在的位置和通信机制
AMS 是 Java 层的一个单例类，android.app.ActivityManagerService。它运行在 system_server 进程中，系统启动时由 SystemServer.java 初始化。
AMS 使用 Binder IPC 机制 与应用程序通信。应用程序通过 ActivityManager、ActivityTaskManager 等接口与 AMS 通信，AMS 接收到请求后执行相应操作。
AMS 是通过 ServiceManager 向系统注册的，其他模块可以通过 ServiceManager.getService("activity") 获取其 Binder 接口。
3 AMS 启动流程
3.1 系统启动阶段
- init → zygote 启动
- zygote 通过反射启动 system_server
- SystemServer.main() → startBootstrapServices() → ActivityManagerService.main()
3.2 AMS 初始化
- 实例化 ActivityManagerService
- 调用 setSystemProcess() 将 AMS 注册到 ServiceManager
- 调用 mSystemServiceManager.startService(ActivityManagerService.Lifecycle.class) 启动
4 Activity 启动流程与 AMS 的作用
假设你调用 startActivity()，AMS 的工作过程如下：
应用进程调用 startActivity()
→ 通过 Instrumentation → ActivityTaskManager → 跨进程调用 AMS。
AMS 收到请求
→ 调用 ActivityStackSupervisor 查找/创建对应的 Task。
→ 如果目标 Activity 不在当前进程，AMS 启动新的应用进程（使用 Zygote 机制）。
进程启动完成后
→ AMS 通知应用进程执行 ActivityThread.performLaunchActivity()，从而真正执行 Activity 的生命周期方法（如 onCreate()）。
5 AMS 相关重要类和模块
| 类 | 简要说明 |
|---|---|
ActivityManagerService |
核心管理类，负责调度 Activity、Service、广播等 |
ActivityTaskManagerService |
Android 10 后分离出的任务栈管理服务，与 AMS 协作 |
ActivityStackSupervisor |
管理任务栈与 Activity 栈（栈结构管理） |
ActivityStarter |
负责启动 Activity 的执行策略 |
ProcessRecord |
表示一个应用进程的运行状态 |
ApplicationThread |
应用进程端的 Binder 接口，AMS 通过它和应用交互 |
ActivityThread |
应用进程中的主线程类，负责真正执行生命周期方法 |
6 AMS 管理 Service 的流程
启动 Service 的流程：
- Context.startService() → Binder 调用 AMS 的 startService()
- AMS 查找目标 Service 所在进程是否存在，不存在则先启动进程
- 创建或复用 Service 实例，调用其 onCreate() 和 onStartCommand()
- 绑定 Service 的流程：
- Context.bindService() → AMS 的 bindService()
- AMS 管理连接信息，维护客户端和服务端的绑定关系
- 应用进程收到回调，执行
- onServiceConnected() 方法
7 AMS 与进程管理
AMS 维护所有应用的进程信息，并负责：
- 启动进程：通过 Zygote fork
- 回收进程：当内存不足时，杀掉优先级低的进程（如空进程）
- 监控进程状态：如是否运行、是否发生 ANR、是否处于前台等
AMS 使用 ProcessList 维护所有进程的信息，每个进程对应一个 ProcessRecord。
8 AMS 与 ANR
AMS 会检测应用的响应时间：
- 主线程在 5 秒内没有响应 Input 或 Binder 请求
- Service 执行时间超过 20 秒
- BroadcastReceiver 超过 10 秒（前台）或 60 秒（后台）
AMS 会记录调用栈信息，并将错误写入 traces.txt，所以平时开发中如果碰到ANR，我们首先要想到的就是取分析traces.txt日志。里面会打印ANR发生时候的多个线程的调用堆栈。
AMS的总体运行逻辑
Q&A
ContentProvider常用于什么场景？
| 场景 | 说明 |
|---|---|
| 不同应用间的数据共享 | App A 想访问 App B 的数据，App B 提供 ContentProvider 暴露接口 |
| 统一封装本地数据访问接口 | 统一访问数据库（SQLite）、文件、网络等数据源，对外提供统一接口 |
| 系统数据访问 | 系统提供的内容如联系人、短信、图片等，都通过 ContentProvider 对外提供 |
| 数据观察机制 | 可通过 ContentObserver 监听数据变化，实现实时更新 UI |
| 配合 CursorAdapter、Loader 等使用 | 特别适合用于大量数据分页加载和懒加载场景 |
AMS运行在系统进程 system_server 中，是 Android Framework 层的关键服务。这句话是不是有问题，AMS不是单独一个进程吗？
AMS（ActivityManagerService）是 Android Framework 层的一个核心服务类，它本身运行在系统进程 system_server 中，不是单独的一个进程。
具体来说，system_server 是一个进程，Android 启动时，Zygote 进程通过 fork() 创建了 system_server 进程。system_server 进程负责承载 Android Framework 层的各种系统服务。
而AMS 是 system_server 中的一个 Java 类（单例），ActivityManagerService 是一个 Java 类，不是进程。它在 system_server 进程中被实例化，并通过 ServiceManager 注册为名为 "activity" 的服务。
其他组件（包括 App 进程）通过 Binder 调用这个服务。
AMS运行在 system_server 进程中，这个进程还包含很多其他系统服务。
下面是列出的一些例子：
| 系统服务 | 所属进程 | 说明 |
|---|---|---|
| ActivityManagerService（AMS） | system_server | 管理 Activity 和应用进程 |
| WindowManagerService（WMS） | system_server | 管理窗口和界面显示 |
| PackageManagerService（PMS） | system_server | 管理应用包信息（安装、卸载等） |
| SurfaceFlinger | surfaceflinger | 图形渲染服务，独立于 system_server 运行 |
持续更新中。。。