📚 课程目录第2章 Android系统启动与Zygote

2. Android系统启动与Zygote

要理解 Activity 为什么能被“启动”、为什么能被“管理”，必须先把视角从应用层拉回到系统启动链路。Android 设备上电后，内核启动第一个用户态进程 init，随后由它解析 init.rc 拉起 Zygote，再由 Zygote fork 出 SystemServer。Activity 管理服务 ActivityManagerService（AMS）正是在 SystemServer 的启动阶段被创建并注册进 ServiceManager 的。也就是说，AMS 并不是一个孤立的服务，而是系统启动流水线在“系统服务阶段”的产物。

一、核心原理：三段式启动链路

Android 用户态启动可以概括为三个关键阶段：init 阶段负责挂载文件系统、解析 rc 脚本、启动 native 服务与属性服务；Zygote 阶段负责预加载类和资源、启动 ART 虚拟机、创建 Socket 等待 fork 请求；SystemServer 阶段负责启动 Binder 线程池、创建并注册上百个系统服务，其中就包括 AMS、PMS、WMS 等窗口与 Activity 体系的核心服务。

这条链路的意义在于：AMS 在创建时就已经处于一个“Binder 可用、SystemServer 进程已就绪、系统上下文已建立”的环境中。因此后续应用进程通过 Binder 调用 AMS 时，AMS 才能以系统服务身份完成进程调度、任务栈管理和生命周期回调。

二、方法流程：从 init.rc 到 AMS 注册

下面用一段简化的启动时序说明关键步骤。真实源码中 init.rc 会通过 service zygote 定义 Zygote 的启动参数，Zygote 在 main() 中完成预加载后进入 runSelectLoop() 等待 fork 请求。SystemServer 被 fork 后，在 SystemServer.main() 中调用 startBootstrapServices()，其中第一项重要服务就是 AMS。

// 简化后的启动链路（伪代码）
init.rc:
  service zygote /system/bin/app_process -Xzygote /system/bin --zygote
      class main
      socket zygote stream 660 root system

Zygote:
  main() -> preloadClasses() -> preloadResources()
         -> startSystemServer() -> runSelectLoop()

SystemServer:
  main() -> startBootstrapServices()
         -> ActivityManagerService am = new ActivityManagerService(context)
         -> ServiceManager.addService("activity", am)
         -> startCoreServices() / startOtherServices()

注意 ServiceManager.addService("activity", am) 这一步：它把 AMS 的 Binder 对象注册到全局服务表。应用进程后续通过 ServiceManager.getService("activity") 拿到 AMS 的代理，才能调用 startActivity()、attachApplication() 等方法。没有这一步，Activity 的跨进程启动就无从谈起。

三、案例场景：一次 startActivity 背后的系统上下文

假设用户在 Launcher 中点击图标启动一个 Activity。应用进程调用 ActivityTaskManager.startActivity()，通过 Binder 进入 AMS。AMS 此时需要判断目标进程是否存在：若不存在，则通过 Zygote 的 Socket 请求 fork 新进程；新进程创建后，AMS 再通过 ApplicationThread 回调 bindApplication() 和 scheduleLaunchActivity()。整个过程中，AMS 依赖的是 SystemServer 启动时建立的 Binder 线程池、PMS 提供的包信息、WMS 提供的窗口令牌，以及 Zygote 提供的 ART 运行时。

从系统上下文看，AMS 的“权力”来自三处：init 建立的属性与权限环境、Zygote 提供的进程孵化能力、SystemServer 提供的服务注册与 Binder 通信框架。理解这三者，才能理解 Activity 为什么能被系统统一调度。

四、误区与复盘

常见误区一：认为 AMS 是“应用启动后才创建”的。实际上 AMS 在 SystemServer 引导阶段就已存在，早于任何普通应用进程。误区二：把 Zygote 当成“应用进程管理器”。Zygote 只负责 fork，不负责 Activity 生命周期；生命周期由 AMS 驱动。误区三：忽略 ServiceManager 的作用，导致无法解释 Binder 调用如何找到 AMS。

启动阶段	关键进程/对象	与 Activity 管理的关系
init 阶段	init、init.rc、属性服务	建立系统环境，定义 Zygote 启动参数
Zygote 阶段	Zygote、ART、预加载类	提供应用进程 fork 能力与运行时
SystemServer 阶段	SystemServer、AMS、PMS、WMS	创建 AMS 并注册到 ServiceManager
应用进程阶段	App Process、ApplicationThread	通过 Binder 调用 AMS 完成 Activity 启动

排障时若遇到 “ActivityManagerService not found” 或 Binder 调用失败，应优先检查 SystemServer 是否正常启动、AMS 是否成功注册到 ServiceManager，而不是只盯着应用层代码。系统启动链路的任何一环断裂，都会表现为 Activity 无法启动。

复盘本节：Android 启动链路是“init → Zygote → SystemServer → 应用进程”的逐级孵化过程。AMS 诞生于 SystemServer 的引导服务阶段，依赖 Zygote 的 fork 能力和 ServiceManager 的注册机制。只有把 AMS 放回这条启动链路中，才能理解 Activity 管理服务真正的系统上下文。