1. AMS总体架构图与系统分层：模块边界、关键组件、核心职责

ActivityManagerService（AMS）是Android系统服务中规模最大、职责最复杂的核心模块，位于SystemServer进程的核心位置。理解AMS的架构需要从系统分层切入，明确其与周边服务（WMS、PMS等）、Native层以及应用进程之间的边界与通信方式。本章作为课程总纲，先建立AMS在整个Android系统中的空间定位与职责边界图谱。

1.1 系统分层与AMS的边界

AMS运行在独立的SystemServer进程内（uid=system），通过Binder IPC暴露接口。分层视角下的AMS位于以下位置：

• 应用层（Application Layer）：通过Context.startActivity/Service等API发起请求，经Binder跨进程到达SystemServer。
• 系统服务层（System Services Layer）：AMS、WMS、PMS等核心服务在此协同，共享SystemServer进程空间。
• 核心库层（Core Libraries）：包含Android Runtime（ART）、Binder驱动支撑层。
• 内核层（Kernel Layer）：提供进程管理、内存管理、Binder驱动、文件系统等底层能力。

1.2 关键组件与核心职责

1.3 数据流与控制流特征

AMS的通信以Binder为核心，主通道方向为：

1. 下行控制流：应用进程（Client）→ Binder → AMS → 调度决策 → 写队列/改状态 → 回调IApplicationThread → 应用进程执行。
2. 上行数据流：应用进程通过Binder向AMS报告组件状态变更（如onResume完成、onStop完成），AMS据此推进状态机。
3. 跨服务协同：AMS与WMS通过WindowManagerService.session.mActivityManager互相持有短引用；与PMS通过PackageManagerInternal接口查询组件信息。

1.4 设计权衡与风险点

1.5 关键源码片段解析

AMS作为Binder服务导出，其实就是继承了IActivityManager.Stub，其核心结构可简化为：

// frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
public class ActivityManagerService extends IActivityManager.Stub
        implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
    
    // 核心数据结构（精简）
    final ActivityStackSupervisor mStackSupervisor;
    final ProcessMap<ProcessRecord> mProcessMap;
    final ServiceMap mServices;
    final BroadcastQueue[] mBroadcastQueues;
    final SparseArray<ProcessRecord> mPidsSelfLocked;
    
    @Override
    public int startActivity(IApplicationThread caller, String packageName,
            Intent intent, ...) {
        // 1. 权限检查
        // 2. 解析Intent确认目标Activity
        // 3. 与任务栈交互（通过mStackSupervisor）
        // 4. 进程／线程调度
        // 5. 回调应用进程执行生命周期
    }
}

AMS虽是一个Java对象，但由于其全局重要性，初始化必须发生在SystemServer的run()方法早期，并注册到ServiceManager：

// frameworks/base/services/java/com/android/server/SystemServer.java
private void run() {
    // ...
    try {
        Slog.i(TAG, "Activity Manager");
        ActivityManagerService am = new ActivityManagerService(context,
                new ActivityTaskManagerService(context));
        ServiceManager.addService(Context.ACTIVITY_SERVICE, am);
    } catch (Throwable e) {
        Slog.e(TAG, "Failure starting Activity Manager", e);
        // 若AMS启动失败，系统将直接进入panic
    }
    // ...
}

1.6 落地步骤与验收标准

在尝试修改或定制AMS时，建议按以下步骤安全推进：

• Step 1：梳理目标分层边界，明确新功能属于AMS内部（如新增生命周期状态）还是跨服务（与WMS/PMS的新交互）。
• Step 2：在AOSP源码中定义精确的Binder接口（.aidl文件），编译通过后再填充实现逻辑。
• Step 3：添加单元测试导向：最小可验证是AMS单进程单元测试（使用tests/ams_test）；验收需通过
  1. CTS/VTS中ActivityManager相关case全部pass；
  2. 连续24小时Monkey/Running Test无AMS崩溃或ANR；
  3. 系统服务堆栈大小（/proc/sys/kernel/threads-max）不变，无内存泄漏。