2. SystemServer 启动与 AMS 初始化

SystemServer 是 Android 系统从 Zygote 孵化出来的第一个 Java 进程，承担着所有系统级服务的创建、注册与生命周期管理职责。AMS 作为系统“大管家”，其初始化顺序、依赖关系与 SystemServer 的启动流程深度绑定。理解这一过程，是掌握 Android 系统架构入口的关键。

SystemServer 启动与 AMS 初始化流程 SystemServer 启动 → AMS 初始化流程 Zygote 进程 fork SystemServer SystemServer.main() createSystemContext() AMS 构造 AMS.systemReady() ServiceManager 注册 关键依赖 • Zygote→SystemServer • ActivityThread • ContextImpl • ActivityStackSupervisor • UserController • ServiceManager • WindowManager • PowerManager • PackageManager • DisplayManager

2.1 启动流程与模块边界

SystemServer 的启动是 Android 系统从原生层过渡到 Java 框架层的桥梁。整个流程可划分为以下阶段：

  1. Zygote fork — Zygote 进程通过 ZygoteConnection.processOneCommand 解析启动参数，fork 出 SystemServer 进程，并执行 SystemServer.main()。
  2. Native 初始化 — 加载 libandroid_servers.so，初始化 JNI 函数表，建立与底层服务的 IPC 通道。
  3. 系统上下文创建 — 调用 createSystemContext() 构造 ActivityThread 实例，初始化 ContextImpl、ResourcesManager 等基础设施。
  4. 系统服务启动池 — 按依赖顺序启动约 80 个系统服务，其中 AMS 是首批启动的“核心服务”之一。
  5. AMS 构造与加入 — 创建 ActivityManagerService 实例，完成内部子模块（ActivityStackSupervisor、UserController、BroadcastQueue 等）初始化。
  6. systemReady 回调 — 当必备服务（PMS、WMS、PowerManager 等）就绪后，AMS 调用 systemReady() 正式进入活动管理状态。
  7. 注册到 ServiceManager — 将 Binder 对象 "activity" 注册到 ServiceManager，供其他进程远程调用。
边界划分提示： SystemServer 只负责“启动和注册”，不直接参与组件管理。AMS 的“职责边界”在 systemReady() 之后才完全激活，在此之前仅完成数据结构和线程池的搭建。

2.2 关键初始化步骤

步骤核心操作依赖组件产出物
1. SystemServer.main()设置线程优先级，加载libandroid_serversZygote、RuntimeInitDalvik/ART 运行时环境
2. createSystemContext创建 ActivityThread，并初始化 ContextImpl、ResourcesActivityThread、DisplayManagerSystemContext 全局单例
3. AMS 构造初始化 HandlerThread、Looper、ActivityStackSupervisor、UserController、BroadcastQueue、TaskPersister 等Context、PowerManager、PackageManagerAMS 对象 (mAm)
4. AMS.setSystemProcess将 AMS 自身 Binder 注册到 ServiceManager（名称 "activity"），并创建 ProcessRecord 系统条目ServiceManagerServiceManager 注册表更新
5. AMS.systemReady恢复最近任务、启动桌面（Launcher）、发送 SYSTEM_READY 广播WindowManager、PackageManager、UserControllerAMS 进入正式工作状态
核心源码片段（SystemServer.java）： 
// SystemServer.main() 入口
public static void main(String[] args) {
    new SystemServer().run();
}

private void run() {
    // 1. 创建系统上下文
    createSystemContext();

    // 2. 启动关键服务
    ActivityManagerService ams = mSystemServiceManager.startService(
            ActivityManagerService.class);
    // 3. 将AMS注册到ServiceManager
    ServiceManager.addService(Context.ACTIVITY_SERVICE, ams);
    // 4. 其他服务启动后调用ams.systemReady()
    ams.systemReady();
}

2.3 层次划分与核心组件职责

SystemServer 启动阶段涉及的层次可划分为：

  • Linux 进程层 — Zygote 进程与 SystemServer 进程的领地。
  • Native 层 — libandroid_servers.so 提供 JNI 桥接，负责与 HAL 及底层驱动交互。
  • Java 框架层 — SystemServer.java 作为启动主入口，创建并管理所有服务。
  • 服务注册层 — ServiceManager 作为全局 Binder 注册中心，维护服务名称到 Binder 引用的映射。

核心组件职责对照：

组件在初始化阶段的职责
ActivityManagerService调度进程启动、管理 Activity 栈、处理广播/服务请求
ActivityThread应用主线程的消息循环调度器，AMS 依赖其进行进程通信
ActivityStackSupervisor管理系统所有显示栈（ActivityStack），决定焦点切换
UserController多用户身份管理，处理用户切换时的行为限制
BroadcastQueue有序/无序广播的排队与分发，与 AMS 的 mHandler 交互
TaskPersister持久化保存最近任务列表，用于系统重启后恢复

2.4 控制流与数据流

控制流： 从 Zygote→SystemServer 的进程启动，到 AMS 内部多个 HandlerThread 的分发，形成以下信任链路：

  • Zygote → SystemServer：通过 socket 传递启动参数，信任链基于 Unix 文件描述符继承。
  • SystemServer → AMS：同步调用构造器，确保 AMS 在依赖服务（如 PackageManager）就绪前不被外部访问。
  • AMS → ServiceManager：单次注册，后续所有进程通过 ServiceManager 查找 Binder 代理。
  • AMS → ActivityStackSupervisor：通过显式接口调用（如 startActivity），不允许外部直接操作 SuperVisor。
信任风险： ServiceManager 本身是无权限检查的纯查找表，任何进程都可以尝试调用 getService()。因此 AMS 在 Binder 接口的 onTransact 方法中必须进行严格的 PID/UID 校验，防止恶意调用。

2.5 设计权衡

权衡点方案 A方案 B（Android 实际采用）理由
服务启动顺序所有服务并行启动按依赖关系分阶段启动避免循环依赖，降低初始化复杂度
AMS 构造时机在 systemReady 之后构造尽早构造，但在 systemReady 前对外不可见确保数据结构完整后再暴露接口
ServiceManager 注册AMS 内部自行注册由 SystemServer 统一注册注册逻辑集中，便于统一管理 Binder 域名

2.6 风险点

  • 死锁风险：AMS 初始化内部使用了多个 HandlerThread 和锁（如 mLock、mActivityTaskManager），若依赖的服务未就绪就调用 AMS 方法，可能造成线程阻塞。
  • 服务级联失败：如果 PackageManager 在 AMS 构造时未初始化完毕，AMS 将无法获取应用包信息，导致 Activity 启动失败。
  • 内存峰值：SystemServer 启动阶段一次性创建大量 Service 对象，堆内存可能急剧膨胀，触发 GC 阻塞。
  • 进程优先级影响：SystemServer 的线程优先级设置不当会导致 UI 响应延迟。

2.7 落地步骤与验收标准

落地步骤：

  1. 在 SystemServer.java 的 run() 方法中按 依赖阶段 添加新服务，确保 AMS 排在 PackageManager 等基础服务之后。
  2. 利用 mSystemServiceManager.startService() 统一管理生命周期，避免直接 new 服务。
  3. 在 AMS 构造函数中仅初始化无依赖的内部数据结构（如 HandlerThread、TaskPersister），将涉及其他服务的逻辑放至 systemReady() 中延迟执行。
  4. 通过 ServiceManager.addService() 注册时，检查是否已被注册，防止重复。
  5. 编写集成测试，验证 SystemServer 启动后 getService("activity") 能正确返回 AMS Binder 引用。

验收标准：

  • SystemServer 进程启动后 5s 内完成 AMS 的构造与注册。
  • AMS 的 systemReady() 回调在桌面启动之前被调用。
  • 使用 dumpsys activity 能正常输出 Activity 栈信息，且不抛出 NullPointerException。
  • 长时间压力测试（重启 100 次）无死锁、无服务未注册异常。
← 上一章 📖 返回目录 下一章 →