03 SystemServer：system_server 的三阶段启动与生命体征

本页导读：system_server 是一个由 zygote fork 出来的 Java 进程，却装着整机最重要的几十个系统服务。它的出生只有三步——bootstrap、core、other——但每一步放什么服务、服务从 onStart 到开机完成要过几道生命周期关卡、出了事谁来兜底（Watchdog），正是本页要讲清楚的「政务区作息表」。基线 Android 16（API 36），服务清单以 AOSP main 分支为准，OEM 系统常有增删。

---

一、出生即工作：SystemServer 的启动路径

zygote fork 出 system_server 后不走普通 App 的 ActivityThread，而是执行 com.android.server.SystemServer.main()：

// frameworks/base/services/java/com/android/server/SystemServer.java（示意骨架）
private void run() {
    // 1. 准备本进程 ClassLoader（只加载 services.jar，不加载应用 dex）
    // 2. 初始化时区、Looper（主线程即 SystemServer 主线程）
    // 3. 三阶段串行启动：
    startBootstrapServices();
    startCoreServices();
    startOtherServices();
    // 4. 最后 systemReady：AMS 放闸，Launcher 获准出场（第 01、06 页）
}

三个关键事实：

1. 它不是普通应用：uid=system、持有大量签名权限、运行在 system_server SELinux 域，dumpsys 能看它的一切；
2. 主线程只做启动编排：跑完三阶段后主线程进 Looper，但真正的重活在各服务自己的 handler 线程与 Binder 线程池里；
3. 单点故障：system_server 崩溃 → Watchdog 拉起或整机软重启，App 全部幸存（它们是独立进程）——这就是「手机自己重启了，但应用没崩」的原理。

二、bootstrap 阶段：先有裁判再有比赛

bootstrap 放的是「被所有人依赖、且不能依赖别人太多」的地基层服务。AOSP 主干的典型名单（顺序即大致依赖序，具体以 AOSP 当前版本为准）：

服务	为什么必须在 bootstrap
SystemServiceManager 自身	后续所有服务的注册表与生命周期驱动器
Watchdog	比几乎所有服务都早，才有资格监督别人
PlatformProperties	特性开关，后面的服务都来查
UserManagerService	多用户骨架，PMS/AMS 都要查用户状态
ActivityManagerService	进程与调度的总管，attach 流程等着它
PackageManagerService	包与权限档案库，AMS/WMS 都要查（第 08 页）
DisplayManagerService	显示拓扑，WMS/亮度策略的地基
PowerManagerService	亮灭屏与 wakelock 中枢，早注册早收事件（第 11 页）
SensorManager/Lights 等硬件代理	与显示联动的早鸟

bootstrap 的特征：这些服务在 ActivityManagerService.systemReady() 之前必须全部就绪，因为 AMS 一开门，第一波组件就要进来。

三、core 阶段：账本与公共设施

core 放「记账与底座」类服务（示意性清单，以 AOSP 为准）：

• BatteryStatsService：全机耗电账本（第 11 页依赖它做归因）；
• StorageManagerService：卷与挂载（第 08 页安装链路的地基之一）；
• NetworkManagementService/NetworkStats：网络策略与流量账本；
• GpuService、UsageStatsService 等统计/资源类服务。

特征：没有它们系统也能亮屏、能起进程，但账本会缺页——所以可以比 bootstrap 晚，但不能晚于第一批应用。

读源码小技巧：AOSP 主干中每个服务的启动行都带 traceBegin("...") 或 startupTracer.trace(...)，perfetto 上按名字直接索引，不必背顺序。

四、other 阶段：大部头都在这

其余几十上百个服务集中在这里（示意性分组）：

• 窗口与交互：WindowManagerService（第 07 页）、InputManagerService（第 09 页）、Vibrator 等；
• 生命周期与通知：AlarmManagerService、JobSchedulerService、NotificationManagerService；
• 内容与应用：ContentService（Provider 服务）、JobScheduler、WebViewFactoryConfiguration；
• Mainline 桥接：EnergyStatsService、PermissionManagerService、RoleManager 等（第 12 页）；
• 其余：LocationProxy、StorageStats、DeviceIdleController（Doze，第 11 页）、Telephony 系列。

other 阶段末尾会做一件大事：ActivityManagerService.systemReady() 被调用——它触发 finishBooting()、拉起 persistent 进程、最后由 ActivityTaskManagerService 发出 HOME intent（第 01、06 页）。

五、SystemServiceManager：服务的生命周期总线

所有经 mSystemServiceManager.startService() 注册的服务都要过 com.android.server.SystemService 的生命周期钩子（签名以 AOSP 当前版本为准）：

钩子	时机	典型用途
onStart()	阶段内构造后立即	注册 binder、读配置、起线程
onBeforeStartUser()	用户会话启动前	按用户准备存储/策略
onUserUnlocking()	用户解锁过程中	迁移旧数据、补装包
onUserSwitching()	切换前台用户	刷新视图归属
onBootPhase()	开机里程碑（历史机制，逐步废弃）	老服务等 PHASE_SYSTEM_SERVICES_READY 等阶段
dump()	dumpsys <name>	可观测性义务

早期 AOSP 用 onBootPhase(PHASE_*) 排队等依赖，Android 12+ 明确转向「用户生命周期回调 + 显式 startService 顺序」双轨制；读老代码看到 PHASE_THIRD_PARTY_APPS_CAN_START 不要慌，知道那是旧式里程碑即可。

还有两类「编外服务」要知道：

• 原生服务（surfaceflinger 等）不由 SystemServiceManager 管理，它们活在 init 的服务体系里，生命周期看 rc；
• APEX 内服务（如 MediaMetricsManager 所在的媒体模块）由模块自带的 SystemService 插件机制加载，钩子时机仍服从本总线（第 12 页）。

六、Watchdog：唯一的「猝死急救员」

Watchdog（frameworks/base/services/java/com/android/server/Watchdog.java）注册监视 android.fg、android.ui、android.io、android.display、ActivityManager、monitor 等线程：每向目标线程 post 一个哨兵消息，超时未回即判定卡死（默认超时 60s 量级，常量以 AOSP 为准）。

触发后动作序列（可被 OEM 策略调整）：

1. dump 全部线程栈与 system_server 状态（落 dropbox/dumpstate）；
2. 拉 bugreport；
3. 杀掉 system_server（软重启，App 存活）或按策略直接整机重启。

// Watchdog 的核心把戏（示意）：给每个被监线程投哨兵
final Message message = Message.obtain(handler, WATCHDOG_BIT_MASK, callback);
handler.sendMessageAtFront(message); // 哨兵排在队头，处理不完就别想回来

实践提示：Watchdog 日志（Watchdog: *** WATCHDOG KILLING 或 blocked for）出现时，第一现场永远是它的线程转储——找「持锁且没在 IO、又在等别的锁」的那个线程。

七、服务注册与发现的三件套

一个典型 Java 服务在 SystemServer 里的标准三连：

// frameworks/base/services/java/com/android/server/SystemServer.java（示意片段）
WindowManagerService wm = new WindowManagerService(context, ...);
mSystemServiceManager.startService(wm);                  // 生命周期总线
ServiceManager.addService("window", wm);                 // Binder 注册，供跨进程
LocalServices.addService(WindowManagerInternal.class, wm); // 同进程直连（不过 Binder）

LocalServices 是页面级小抄重点：同进程服务互调不走 Binder，性能与死锁特性都和 Binder 不同（第 04 页）；这也是「system_server 内部死锁不会表现为 Binder 超时，而是表现为 Watchdog」的原因。

八、启动耗时怎么量

adb shell getprop | grep boottime            # 各里程碑起点（表格内书写需转义竖线）
adb shell dumpsys activity | grep -e "start=" -e "displayed"
 # systrace/perfetto 上直接看 SystemServer 主线程：
 # startBootstrapServices / startCoreServices / startOtherServices 三大色块

经验：startOtherServices 里 WMS 初始化与 PMS 收尾常占大头；若看到某个服务耗时异常，perfetto 时间线里的 slice 名就是 SystemServerManager 打的 startService <name> 标签，定位非常直接。

另外两个可观测入口：

• boot_progress_* 系列（events buffer，从 boot_progress_start 到 boot_progress_enable_screen）串起用户可感知的里程碑，适合拉甘特图。

九、常见故障模式与定位

症状	定位思路
开机后反复软重启	logcat 过滤 Watchdog/ShutdownThread，看 dumpbox SYSTEM_RESTART
卡在开机动画不动	多半某服务 onStart 里同步等外部（网络/HAL），perfetto 看 startService 长尾
dumpsys 某服务无输出	服务根本没起来/构造抛异常，logcat -b crash 找 SystemServer 栈
某功能开机可用几分钟后失效	Watchdog 前兆线程阻塞，bugreport 的 system_server 线程栈对比前后两次
用户解锁后功能异常	忘了实现 onUserUnlocking 类回调，双用户/工作资料下必翻车

十一、线程与内存画像

拿到一份 bugreport，system_server 的线程名几乎能当地图用：

线程名（前缀）	归属	干什么
main	SystemServer/各服务共用主 Looper	开机编排后只处理少量主线程消息
android.fg/android.ui/android.io/android.display	HandlerExecutor 家族	各服务指定线程族处理重活，Watchdog 监督对象
ActivityManager/ActivityTaskManager	AMS/ATMS 主 Handler	进程表、组件调度串行化点
android.bg	后台服务线程	低优先级异步任务
Binder:<pid>_N	Binder 线程池（上限高于普通进程，具体值以 AOSP 为准）	所有跨进程请求入口

内存侧：system_server 常驻 RSS 常见数百 MB（堆 + 预加载类共享部分），dumpsys meminfo 与 procrank 都能看到它稳坐前排——这是架构设计而非泄漏：预加载类、包信息、窗口状态都刻意常驻。

十二、版本注记

• Android 5（API 21）：SystemServer 拆出 SystemServiceManager，onBootPhase 体系成型。
• Android 10（API 29）：ATMS 从 AMS 拆出，bootstrap 阶段职责重排（第 06 页）。
• Android 11~12（API 30~31）：Mainline 模块服务经 APEX 提供，SystemServer 里大量「注册即桥接」；用户生命周期回调替代 onBootPhase 的迁移加速。
• Android 13（API 33）：部分子系统继续拆入 services 子包与 mainline jar。
• Android 15~16（API 35~36）：更多能力（如 pkg 设置存储、EnergyStats 稳定接口）下沉模块；SystemServer 主干保持三阶段骨架不变——骨架十年未动，变的是名单。

本页小结

本页小结：三阶段是一条依赖拓扑序：bootstrap 定规则、core 记账、other 交活；SystemServiceManager 是作息表，Watchdog 是急救员。读 system_server 源码的正确姿势不是通读，而是拿着「某个功能在哪个服务、什么时候 onStart、卡住时哨兵在哪条线程」这三问去定位。

参考

• SystemServer 源码：cs.android.com/android/platform/frameworks/base/+/main/services/java/com/android/server/SystemServer.java
• SystemServiceManager 源码：cs.android.com/android/platform/frameworks/base/+/main/services/core/java/com/android/server/SystemServiceManager.java
• Watchdog 源码：cs.android.com/android/platform/frameworks/base/+/main/services/core/java/com/android/server/Watchdog.java
• 开机与生命周期：developer.android.com/guide/components/fundamentals