AMS

AMS 思维导图

AMS 体系
├── 核心服务
│   ├── AMS：进程/内存/组件总管
│   ├── ATMS：Activity/Task/栈/多窗口（Android 10+）
│   └── WMS：窗口/视图/显示
├── 核心组件
│   ├── ActivityThread：APP 主线程
│   ├── ApplicationThread：Binder 通信
│   ├── Instrumentation：创建 Activity + 生命周期
│   ├── ActivityStackSupervisor：栈管理
│   ├── TaskRecord：任务栈
│   ├── ActivityRecord：单个 Activity
│   └── ProcessList：进程列表
├── 进程优先级
│   ├── oom_adj：LMK 杀进程优先级
│   ├── procState：进程状态
│   └── schedGroup：CPU 调度组
├── 调度机制
│   ├── updateLruProcessLocked
│   ├── updateOomAdjLocked
│   └── computeOomAdjLocked
├── 内存回收
│   ├── LMK 低内存查杀
│   ├── IdleHandler 空闲回收
│   ├── CachedAppOptimizer
│   └── trimApplications()
├── 启动流程
│   ├── 系统启动：SystemServer 启动 AMS
│   ├── 应用进程：Zygote.fork()
│   ├── 页面启动：AMS → Binder → Handler → 主线程
│   └── 页面构建：PhoneWindow → DecorView → 布局加载
└── 性能优化
    ├── 延迟加载
    ├── 异步初始化
    ├── 服务拆分（ATMS）
    └── 内存与进程回收策略

AMS 架构与组件

AMS 整体架构

AMS 是 Android 核心系统服务，运行在 SystemServer 进程
负责：进程管理、任务栈管理、四大组件调度、内存管理、生命周期管控
采用 Binder IPC 与应用进程通信

核心组件与功能

组件	职责
AMS	系统进程/组件总管理器
ATMS(ActivityTaskManagerService)	Android 10+ 分离，专门管理 Activity/Task/栈
ActivityStackSupervisor	栈管理核心协调者
TaskRecord	一个任务 = 一组 Activity
ActivityRecord	单个 Activity 的描述信息
ProcessList	维护系统所有进程信息
Instrumentation	负责创建 Activity 并执行生命周期

组件间通信

AMS ↔ 应用进程：Binder（ApplicationThread）
AMS ↔ WMS：窗口显示/触摸事件协调
AMS ↔ Zygote：进程孵化
AMS ↔ PMS/PowerManager：包信息、电源、电池统计

AMS 工作原理

工作原理概述

AMS 是系统大脑：统一调度组件、进程优先级、内存、任务栈
全程基于 消息驱动 + 主线程执行
组件生命周期 全部由 AMS 发起，由 Instrumentation 真正执行
任务调度与优先级
- 按进程状态动态排序
- 按 LRU（最近最少使用）回收后台进程
- 按 oom_adj / procState / schedGroup 三重指标决定优先级
消息传递与事件处理
- AMS → ApplicationThread（Binder 线程）
- → Handler 切主线程
- → ActivityThread 处理
- → Instrumentation 执行生命周期

AMS 管理结构总结

AMS
├─ mPidMap (SparseArray)        pid → ProcessRecord
├─ mProcessNames (ArrayMap)     进程名 → ProcessRecord
├─ mProcessMap (HashMap)        AppThread → ProcessRecord
│
└── 每个 value = ProcessRecord 实例
     ├── 进程信息：pid、uid、processName
     ├── 组件列表：
     │    ├─ mActivities → 该进程下的 ActivityRecord
     │    ├─ mServices → 该进程下的 ServiceRecord
     │    └─ mReceivers → 广播
     ├── 优先级：oom_adj、procState
     └── 通信代理：IApplicationThread（与 App 通信）

AMS 内部的层级结构

ActivityStackSupervisor（总管）
   ↓
ActivityStack（栈管理）
   ↓
TaskRecord（任务栈，一个任务 = 一个App打开的一组Activity）
   ↓
ActivityRecord（单个Activity的档案）
   ↓
ProcessRecord（进程档案：这个Activity属于哪个进程）

更直白的对应关系：

ProcessRecord = 一个 App 进程
ActivityRecord = 一个 Activity
一个 ProcessRecord 可以对应 多个 ActivityRecord
一个 ProcessRecord 也可以对应 多个 ServiceRecord

层级关系（必须背）

ActivityStack → 管理所有任务
TaskRecord → 一个任务栈
ActivityRecord → 栈里的每一个Activity信息
App 进程的 Activity → 真正的界面

AMS 内部统一管理结构：

进程级别

ProcessRecord
= 一个 App 进程档案
- 包含多个：
  - ActivityRecord（Activity 档案）
  - ServiceRecord（Service 档案）
  - BroadcastRecord（广播档案）
  - ProviderRecord（内容提供档案）

界面栈级别

ActivityStackSupervisor
- ActivityStack
  - TaskRecord
    - ActivityRecord

服务管理

ActiveServices（AMS 内部管理 Service 的核心）
- ServiceRecord

三者之间的持有关系（代码层面）

1. ActivityThread 持有 ApplicationThread

class ActivityThread {
    // 主线程管家
    private ApplicationThread mAppThread;
    private Instrumentation mInstrumentation;
}

2. ApplicationThread 是 ActivityThread 的内部类

class ActivityThread {
    // Binder 通信，接收 AMS 指令
    class ApplicationThread extends IApplicationThread.Stub {
    }
}

3. ActivityThread 持有 Instrumentation

class ActivityThread {
    // 真正执行生命周期的工具
    Instrumentation mInstrumentation;
}

关键职责区分

ActivityThread 做什么？

管理 App 主线程
管理消息循环 Looper.loop()
管理所有 Activity、Service
调度生命周期，但不直接执行

ApplicationThread 做什么？

Binder 服务端
与 AMS 跨进程通信
运行在 Binder 线程
只负责接收指令 → 转发给主线程

Instrumentation 做什么？

创建 Activity
执行生命周期（onCreate、onStart…）
创建 Application
系统的钩子，插件化必 Hook

关键组件

ActivityManagerService

总管：进程、内存、组件、任务
系统启动由 SystemServer 初始化

ActivityTaskManagerService (ATMS)

Android 10+ 从 AMS 拆分
专门负责：Activity 启动、任务栈、多窗口、生命周期调度
让 AMS 更专注进程/内存

ActivityStackSupervisor

管理所有 ActivityStack
负责：入栈、出栈、切换、返回键、启动模式判断
拥有 mHomeStack 和 mFocusedStack

ProcessList

存储系统所有进程信息
提供进程优先级、状态、PID、UID 等全局视图

TaskRecord

它是 AMS 用来描述**一个任务栈（Task）**的档案类。

AMS 里对应“任务栈”的类：TaskRecord**
路径：android.app.servertransaction.TaskRecord（高版本）
老版本：com.android.server.am.TaskRecord

ActivityTask

ActivityTask 是什么？

ActivityTask 是 Android 11+ 引入的辅助类，作用是封装一次 Activity 启动/调度事务，用于跨进程传递启动指令， 不是任务栈本身。

简单区分：

TaskRecord = 任务栈实体（AMS 内部档案）
ActivityTask = 一次启动事务（消息包）

ActivityRecord

ActivityRecord 是什么？

ActivityRecord 是 AMS 内部的一个类，用来描述和记录一个 Activity 的所有状态信息。

ActivityRecord 就是 AMS 用来“记住、管理、追踪每一个 Activity 信息”的数据模型（Java Bean）。

你可以理解成：AMS 给每个 Activity 发的一张“身份证 + 档案表”**

里面记录了：

这个 Activity 属于哪个 App
属于哪个任务栈（Task）
当前生命周期状态（onCreate / onResume / onPause...）
包名、类名、进程 ID、任务 ID
启动模式、Intent、flag
是否在前台、是否可见
等等...

App 进程 看不到、拿不到、不能修改 ActivityRecord。

只要 Activity 还没销毁，AMS 就靠这张 ActivityRecord 知道它的一切。

ActivityRecord 的核心作用

1. AMS 用来“识别”每个Activity

AMS 不直接操作你的Activity，它只操作 ActivityRecord。

2. 管理生命周期

AMS 决定要启动、暂停、销毁某个Activity时，都是先操作 ActivityRecord，再通过Binder通知App进程。

3. 管理任务栈（返回栈）

ActivityRecord 存放在 TaskRecord 中，返回键、启动模式、CLEAR_TOP 都是在 操作 ActivityRecord。

4. 保存状态

系统内存不足杀死Activity，恢复时也靠 ActivityRecord 里的信息。

最关键的区别（面试 90% 会问）

1. ActivityRecord ≠ 你的Activity

ActivityRecord：系统进程里的“描述信息”
你的Activity：App进程里的“真实界面”

2. 一个 ActivityRecord 对应一个真实Activity

3. ActivityRecord 由 AMS 创建、管理、销毁

最通俗的比喻

AMS = 校长
TaskRecord = 班级
ActivityRecord = 学生档案表
你的Activity = 真实学生

ProcessRecord

ProcessRecord 是什么？

ProcessRecord 就是 AMS 用来描述、管理、追踪一个 App 进程的“档案对象”，完全运行在 system_server 进程里。

只存在于 system_server 进程的 AMS 内部 你的 App 进程拿不到、看不到、改不了它。

它和你 App 里的代码没有任何直接关系，只属于 AMS。

AMS 要管理手机里所有正在运行的 App，就必须给每个进程建一份档案，这份档案就是：ProcessRecord

它记录一个 App 进程的所有关键信息：

进程 ID（pid）
进程名（processName）
包名（packageName）
uid
当前进程的状态（前台/后台/空进程）
进程优先级（oom_adj）
内存使用情况
进程里跑了哪些四大组件（Activity、Service、Receiver）
持有哪些 ActivityRecord、ServiceRecord
进程什么时候被创建、什么时候可能被杀死

一句话： AMS 靠 ProcessRecord 认识、管理、杀死、恢复一个 App 进程。

ProcessRecord 作用

记录进程信息（pid、uid、状态、优先级）
管理进程生命周期
决定进程是否被 LMKD 杀死
关联进程内部所有 Activity、Service

ProcessRecord 层级

ProcessRecord 包含多个 ActivityRecord、ServiceRecordActivityRecord 归属一个 ProcessRecord

ProcessRecord 在AMS中是一个什么数据结构？

ProcessRecord 本身是一个普通 Java 类（Bean），但它在 AMS 内部被统一放在一张「全局 HashMap」里管理，形成 “pid / 进程名 /uid → ProcessRecord” 的映射结构。

它不是数组、不是链表、不是栈，而是以哈希表为载体的全局进程注册表。

ProcessRecord 自身是什么？

它就是一个数据承载类，内部保存一个进程的所有状态：

pid、uid、processName
mServices（该进程内的所有 ServiceRecord）
mActivities（该进程内的所有 ActivityRecord）
oomadj、mAdj、mProcState
mAppThread（ApplicationThread 的 Binder 代理）
进程优先级、adj 分组、crash 次数等

所以：

ProcessRecord ≈ 进程信息的 Java Bean

在 AMS 中以什么数据结构存储？

在 ActivityManagerService(AMS) 内部，使用 HashMap 来管理所有进程：

// AMS 内部源码（核心）
final HashMap<IBinder, ProcessRecord> mProcessMap = new HashMap<>();
final SparseArray<ProcessRecord> mPidMap = new SparseArray<>();
final ArrayMap<String, ProcessRecord> mProcessNames = new ArrayMap<>();

也就是说：

mPidMap
- SparseArray<pid, ProcessRecord>
- 通过 pid 快速查进程
mProcessNames
- ArrayMap<processName, ProcessRecord>
- 通过 进程名 查进程
mProcessMap
- HashMap<IBinder, ProcessRecord>
- 通过 ApplicationThread 的 Binder 代理找到对应进程

所以：

ProcessRecord 在 AMS 中是哈希表（Map/SparseArray）中的一条记录。

ProcessRecord 和 App 进程的关系

App 进程 = 真实运行的 Linux 进程（zygote fork 出来的）
ProcessRecord = AMS 里描述这个进程的“档案”

AMS 不直接跟进程打交道， AMS 只跟 ProcessRecord 打交道。

最通俗的比喻

AMS = 车管所
ProcessRecord = 车辆档案（车牌号、车主、颜色、年检）
App 进程 = 真实在路上跑的汽车
ActivityRecord = 车里坐的乘客

车管所管理车辆，靠的是档案，不是直接抓车。

ServiceRecord

ServiceRecord 是什么？

一句话结论：

ServiceRecord 就是 AMS 用来描述、管理、追踪一个 Service 的 “档案对象”，和 ActivityRecord 对应，只存在于 system_server 进程。

它是干嘛的？

AMS 不直接和你 App 里的 Service 打交道，

它在自己内部用 ServiceRecord 来 “代表” 这个 Service，记录一切信息：

所属的 ProcessRecord（在哪个进程）
Service 的组件名称、包名
当前状态：创建中、已创建、绑定中、已绑定、销毁中
绑定它的所有客户端（Connection 信息）
启动方式：startService /bindService
优先级、oom_adj 权重
Intent、flags 等

一句话：

ServiceRecord = AMS 眼里的一个 Service

你 App 里的 Service 只是真正的实例。

和 ActivityRecord 的对比

对象	作用	对应组件
ActivityRecord	AMS 描述一个 Activity	Activity
ServiceRecord	AMS 描述一个 Service	Service

功能非常对称：

启动 Activity → AMS 创建 ActivityRecord
启动 Service → AMS 创建 ServiceRecord

通俗比喻

AMS = 物业
ProcessRecord = 一栋楼
ActivityRecord = 楼里的住户（前台可见）
ServiceRecord = 楼里的保安 / 保洁（后台运行）

极简总结

ServiceRecord 是 AMS 内部用于记录和管理一个 Service 状态的档案类，运行在 system_server。

作用：

代表一个 Service
记录进程、状态、绑定关系
控制 Service 的启动、绑定、重启、销毁
影响进程优先级（oom_adj）

归属：

ProcessRecord ← ServiceRecord

进程管理（AMS 最核心）

进程优先级（三重指标）

oom_adj

决定 LMK 低内存回收优先级
值越小 → 越重要 → 越不容易被杀
取值：0~906

procState

进程当前状态
如：前台、可见、后台、服务、空进程、缓存

schedGroup

CPU 调度分组
决定进程能分到多少 CPU 时间片
TOP_APP / DEFAULT / BACKGROUND

进程优先级分类

进程类型	adj	procState	schedGroup
前台进程	0-199	FOREGROUND	TOP_APP
可见进程	200-499	VISIBLE	DEFAULT
服务进程	500-599	SERVICE	DEFAULT
辅助进程	600-699	AUXILIARY	DEFAULT
空进程	900-906	EMPTY	BACKGROUND
缓存进程	900-906	CACHED	BACKGROUND