Android Framework模块化机制详解 - 第4节
4.1 模块边界性分析
ActivityManagerService（AMS）是 Android Framework 中体积最大、职责最密集的系统服务。在模块化拆分语境下，首先需要清晰划定 AMS 的外部边界与内部子模块边界，避免职责交叉。
| 核心职责域 | 边界范围 | 外部依赖接口 |
|---|---|---|
| 进程管理 | 应用进程创建、调度、冻结、杀死；oom_adj 计算 | ZygoteProcess、LowMemoryKiller、lmkd |
| 组件生命周期 | Activity / Service / BroadcastReceiver / ContentProvider 的启动、暂停、停止、销毁 | ActivityThread（应用端）、WindowManagerService、PackageManagerService |
| 权限检查 | 运行时权限、系统权限、AppOps 检查；Intent 权限鉴定 | PermissionManagerService、AppOpsService、PackageManager |
4.1.1 外部边界
AMS 对外提供 Binder 接口，客户端（一般为应用进程的 ActivityThread）通过 Binder IPC 调用 AMS 的公开方法。AMS 不直接操作文件系统、不处理网络、不管理窗口绘制，这些职责分属其他 SystemService。
4.1.2 内部子模块边界
- ProcessRecord 模块：维护
mPidsSelfLocked、mProcessNames两张核心映射表。 - ActivityRecord / TaskRecord / ActivityStack 模块：管理 Activity 栈结构和生命周期状态迁移。
- BroadcastQueue / ServiceRecord 模块：分别管理广播分发、Service 绑定与启动。
- PermissionController 模块：提供
checkComponentPermission()等权限鉴定入口。
AMS 内部子模块间通过
mService 回调或锁保护的数据结构交互，不允许跨模块直接访问对方锁域外的数据。4.2 分层架构与核心职责
AMS 处于 SystemServer 进程内部，属于 Framework 层的“系统编排层”，向下控制 Native 守护进程（lmkd、zygote），向上对应用进程发布调度指令。
| 分层 | 职责 | 关键交互对象 |
|---|---|---|
| 接口层 | 暴露 Binder 远程调用入口 | IActivityManager.aidl |
| 调度决策层 | 进程调度、优先级计算、组件状态迁移 | ProcessRecord、ActivityStackSupervisor |
| 同步执行层 | 触发进程创建、发送广播、绑定 Service | ZygoteProcess、ActivityThread（应用端） |
| 权限鉴定层 | 检查调用方 UID / PID 是否具备所需权限 | PackageManager、PermissionManager |
4.3 控制流与信任链路
信任链路是指 AMS 在执行关键操作时，如何验证发起方的身份和权限。以下以“应用进程请求启动一个 Activity”为例展示完整信任链路。
- 客户端发起：应用进程调用
Instrumentation.execStartActivity()->IActivityManager.startActivity()。 - AMS 身份校验：Binder 驱动自动传递 caller pid / uid；AMS 通过
getCallingPid()/getCallingUid()获取。 - 权限检查点 1：若目标 Activity 声明了
android:permission，AMS 调用checkComponentPermission()验证 caller uid。 - 权限检查点 2：若属于跨 Task 启动且涉及
startActivityFromChild，检查START_PERMISSION。 - 进程决断：若目标进程不存在，AMS 通过 ZygoteProcess 请求 zygote fork 新进程，并在新进程初始化后绑定 Application。
信任链路特点：身份信息从 Binder 驱动层直接获取，无法被应用进程仿冒；AMS 不信任任何上层传入的 pid/uid，始终使用 Binder 线程上下文确定的真实身份。
4.4 内联 SVG：AMS 模块边界与控制流信任链路
4.5 数据流分析
AMS 维护多个核心数据结构来支撑三大职责。
- 进程管理数据流：
mPidsSelfLocked // PID -> ProcessRecord 映射 mProcessNames // userId + 进程名 -> ProcessRecord mOomAdjObserver // 监听 oom_adj 变化 - 组件生命周期数据流：
mActivityStacks // 各显示层 ActivityStack mServices // 已注册 ServiceRecord mRegisteredReceivers // 注册的 BroadcastReceiver - 权限检查数据流：
checkComponentPermission(permission, pid, uid, owningUid, exported, exportedPermission)
风险点：AMS 的核心数据流全部在主线程（
mService 线程）上完成，导致长耗时操作（如包名解析、权限查询）会直接阻塞 Activity 启动流程。模块化后，权限查询应异步化或下沉至 PermissionManagerService。4.6 选型权衡与风险点
| 决策项 | 方案 A（当前 AMS 内） | 方案 B（模块化拆分） | 推荐 |
|---|---|---|---|
| 权限检查执行位置 | AMS 主线程同步执行 | 委托 PermissionManagerService 异步回调 | 方案 B |
| 进程管理调度 | AMS 直接调用 ZygoteProcess | 引入 ProcessManager 独立 Service | 方案 A（保持低延迟） |
| 组件生命周期状态机 | AMS 内部状态迁移逻辑与 Binder 调用耦合 | 提取至 LifecycleManager 组件 | 方案 B |
关键风险：
- 单点故障：AMS 服务进程崩溃会导致整个 Framework 失联，减少职责范围（如拆分权限模块）可降低崩溃概率。
- 调用深度：拆分后增加 IPC 跳转次数，需权衡性能与可维护性。
- 状态一致性：进程管理与组件生命周期之间存在强依赖关系（如进程被杀需同步销毁 Activity），拆为独立模块时必须设计严格的事务机制。
4.7 落地步骤
- 梳理调用点：扫描 AMS 中所有对
checkComponentPermission、checkUidPermission的调用，统计频次与耗时。 - 提取权限检查接口：定义
IPermissionVerifier接口，将权限鉴定逻辑迁移至PermissionVerifierImpl，AMS 只保留调度逻辑。 - 明确子模块边界：在 AMS 源码内创建
com.android.server.am.permission包，隔离权限相关类。 - 引入 IProcessManager：将进程创建与调度的对外入口抽象化，AMS 通过
ProcessManager接口转发。 - 压力测试：构造频发 Activity 启动 + 权限检查 + 进程被杀的场景，验证拆分后系统响应时间不劣化超过 5%。
4.8 验收标准
- 边界清晰：权限检查代码从 AMS 主类中完全移除，移入独立包或 Service 后编译通过，所有原有权限测试用例 100% 通过。
- 性能无损：启动 200 个 Activity 场景下，单次 startActivity 从 Binder 入口到返回的平均耗时 ≤ 35ms，拆分后不增加超过 3ms。
- 信任链路完整：权限鉴定仅依赖 Binder 驱动层传递的 uid/pid，无任何上层注入漏洞。
- 文档完备：输出 AMS 模块边界图与数据流图，标注每个模块的依赖关系与锁域范围。