SystemServer知识图谱

本文面向已经读过 Android启动全景、SystemServer.run、SystemServiceManager 和 Process.start 的读者。它不是把前面的文章再压缩一遍，也不替代某个函数的逐行分析，而是建立一套可以反复使用的源码坐标系：看到一个启动问题时，先判断状态属于哪个进程和对象，再找到写入者、消费者、生效时机以及失败后的清理位置。

全文固定在 Android 17。读完后，你应能从 ZygoteInit.main() 解释 Zygote 父进程与 system_server 子进程为何走向不同入口；从 SystemServiceManager 区分“Java 服务实例已启动”“Binder 名称已发布”和“Boot Phase 已到达”；从 ProcessList 的 startSeq 追到 ActivityThread.attach()；最后根据现象选择源码入口，而不是从 SystemServer.java 第一行开始盲目搜索。

1. 四层所有权

SystemServer 系列最容易混淆的不是函数名，而是不同层次都使用“启动”“注册”“就绪”这些词。先把四类所有者分开，后面的调用链才不会串错。

层次	主要所有者	持有的状态	直接消费者	典型完成点
进程孵化	Zygote、`ZygoteServer`	socket、ABI、预加载结果、fork 返回值	`system_server` 或应用子进程	父进程回到 `runSelectLoop()`；子进程执行返回的 `Runnable`
服务编排	`SystemServer`、`SystemServiceManager`	服务实例列表、当前 Boot Phase、并行任务	各 `SystemService`	`onStart()` 返回；某阶段全部 `Future.get()` 返回
服务发现	`servicemanager`、`ServiceManager`	Binder 服务名到 Binder 对象的映射	framework API、其他系统服务、应用进程	`IServiceManager.addService()` 完成
应用进程	AMS、`ProcessList`、`ProcessRecord`	`pendingStart`、`startSeq`、pid、attach 状态	Zygote、`ActivityThread`、AMS	pid 被接收并登记；应用以相同 `startSeq` attach

这四层之间存在依赖，但不存在一个覆盖全部含义的“ready”布尔值。例如，服务对象已经进入 mServices，并不表示它已经发布 Binder 接口；Binder 接口可以查询，也不表示服务已经收到 PHASE_BOOT_COMPLETED；Zygote 已返回 pid，也不表示应用已经完成 attachApplication()。

2. 启动主线

2.1 Zygote分叉

启动主线的第一个关键点是 forkSystemServer() 的返回值。

源码文件：frameworks/base/core/java/com/android/internal/os/ZygoteInit.java

2.2 服务分组

system_server 子进程进入 SystemServer.main() 后，核心编排发生在 run()。

源码文件：frameworks/base/services/java/com/android/server/SystemServer.java

2.3 主循环

服务启动完成后，system_server 主线程进入永久 Looper。

源码文件：frameworks/base/services/java/com/android/server/SystemServer.java

相关位置：SystemServer.run 尾部

java

// 本文注：Binder 错误回调在主要系统服务启动后才安装。
Binder.setTransactionCallback(new IBinderCallback() {
    @Override
    public void onTransactionError(
            int pid, int code, int flags, int err) {
        mActivityManagerService
                .frozenBinderTransactionDetected(
                        pid, code, flags, err);
    }
});

// 本文注：正常运行期间主线程不应从 Looper.loop() 返回。
Looper.loop();
throw new RuntimeException(
        "Main thread loop unexpectedly exited");

这段代码给出两个重要边界。第一，服务分组返回只是初始化主线结束，SystemServer 的长期消费者是主线程消息队列、Binder 线程池和各服务自有线程。第二，Looper.loop() 返回被视为不变量破坏，恢复单位不是“重进 run”，而是由 Zygote/init 侧处理 system_server 进程死亡，详见崩溃恢复链。

3. 服务状态

3.1 实例与名称

SystemServiceManager 管理 Java 服务实例和生命周期回调；ServiceManager 管理跨进程可发现的 Binder 名称。两者经常在一个 onStart() 中连续出现，但不是同一张表。

源码文件：frameworks/base/services/core/java/com/android/server/SystemServiceManager.java

相关函数：startService(Class)、startService(SystemService)

前一个重载通过公开的 Context 构造函数反射创建实例；下面保留后一个重载的真实状态写入顺序。

java

public void startService(@NonNull final SystemService service) {
    // Check if already started
    String className = service.getClass().getName();
    if (mServiceClassnames.contains(className)) {
        Slog.i(TAG, "Not starting an already started service " + className);
        return;
    }

    // 本文注：先登记实例，再同步调用 onStart()。
    mServiceClassnames.add(className);
    mServices.add(service);

    long time = SystemClock.elapsedRealtime();
    try {
        service.onStart();
    } catch (RuntimeException ex) {
        throw new RuntimeException("Failed to start service "
                + service.getClass().getName()
                + ": onStart threw an exception", ex);
    }
    warnIfTooLong(SystemClock.elapsedRealtime() - time, service, "onStart");
}

mServiceClassnames 防止同一类被重复启动，mServices 是以后广播 Boot Phase 和用户生命周期事件的消费者列表。值得注意的是，源码先把实例加入列表，再调用 onStart()；若 onStart() 抛异常，异常会终止当前启动主线，实例不会在这里自动从列表移除。它依赖 system_server 进程级失败恢复，而不是在同一进程内回滚所有已启动服务。

服务需要对其他进程可见时，还要主动发布 Binder 名称。

源码文件：frameworks/base/services/core/java/com/android/server/SystemService.java

相关函数：publishBinderService、publishLocalService

java

protected final void publishBinderService(
        String name, IBinder service,
        boolean allowIsolated, int dumpPriority) {
    // 本文注：跨进程消费者通过 servicemanager 名称查询。
    ServiceManager.addService(
            name, service, allowIsolated, dumpPriority);
}

protected final <T> void publishLocalService(
        Class<T> type, T service) {
    // 本文注：LocalServices 只服务于 system_server 进程内部。
    LocalServices.addService(type, service);
}

因此，“服务注册”至少有三种含义：实例进入 SystemServiceManager.mServices，Binder 对象进入 servicemanager 名称空间，本地接口进入 LocalServices。排查 getSystemService() 返回空时应看 Binder 发布链；排查 system_server 内部依赖为空时应看 LocalServices；排查 onBootPhase() 没被调用时才看 mServices 和阶段推进。

3.2 阶段推进

Boot Phase 是单调递增的全局阶段，不是每个服务独立推进的状态机。

源码文件：frameworks/base/services/core/java/com/android/server/SystemServiceManager.java

3.3 失败边界

失败点	当时已写入的状态	处理方式	不应误判为
服务构造失败	尚未加入 `mServices`	包装为 `RuntimeException`，终止启动主线	服务被忽略后继续启动
`onStart()` 抛异常	类名和实例已加入管理列表	重新抛出，通常进入进程级恢复	自动回滚服务注册
Boot Phase 倒退	`mCurrentPhase` 未改写	`IllegalArgumentException`	忽略重复阶段
串行回调异常	`mCurrentPhase` 已推进	包装后抛出	继续通知剩余服务
并行回调异常	任务已提交	`Future.get()` 将异常带回主线程	后台静默失败
Binder 发布失败	Java 实例可能已启动	`ServiceManager.addService()` 记录远端异常	生命周期和服务发现同时成功

这张表说明服务启动缺少跨服务事务式回滚。关键服务初始化失败时，Android 依靠 system_server 的进程重启重建整体状态；服务自身若持有外部资源，仍应在内部失败路径中及时关闭文件、线程或 native handle，不能假设进程一定立刻退出。

4. 进程主线

4.1 待启动状态

应用进程启动不是“AMS 调用一次 fork”这么简单。AMS 侧先创建一个带序号的待完成事务，Zygote 返回 pid 后再验证这次返回是否仍对应当前 ProcessRecord。

源码文件：frameworks/base/services/core/java/com/android/server/am/ProcessList.java

4.2 参数协议

ProcessList 把安全身份、挂载模式、ABI、SELinux 信息和 startSeq 传给 Process.start()。

源码文件：frameworks/base/services/core/java/com/android/server/am/ProcessList.java

相关位置：startProcess 的 regular Zygote 分支

java

startResult = Process.start(
        entryPoint,
        app.processName,
        uid,
        uid,
        gids,
        runtimeFlags,
        mountExternal,
        app.info.targetSdkVersion,
        seInfo,
        requiredAbi,
        instructionSet,
        app.info.dataDir,
        invokeWith,
        app.info.packageName,
        zygotePolicyFlags,
        isTopApp,
        app.getDisabledCompatChanges(),
        app.getEnabledCompatChanges(),
        useDeliQueue,
        pkgDataInfoMap,
        allowlistedAppDataInfoMap,
        bindMountAppsData,
        bindMountAppStorageDirs,
        bindOverrideSysprops,
        app.getStartSeq(),
        new String[]{PROC_START_SEQ_IDENT
                + app.getStartSeq()});

这些参数不是装饰性元数据。UID/GID 和 supplementary groups 决定 Linux 身份；seInfo 参与 SELinux domain 选择；ABI 决定连接主 Zygote 还是次 Zygote；mountExternal 和 bind-mount 参数决定可见文件系统；startSeq 最终回到 AMS 完成身份校验。修改其中一个字段时，必须继续追踪 Zygote 参数解析和 native specialization，而不是只改 Java 调用签名。

ZygoteProcess.startViaZygote() 将结构化参数编码为换行协议。

源码文件：frameworks/base/core/java/android/os/ZygoteProcess.java

相关函数：startViaZygote、zygoteSendArgsAndGetResult

java

ArrayList<String> argsForZygote = new ArrayList<>();

// 本文注：身份与运行参数位于协议前部。
argsForZygote.add("--runtime-args");
argsForZygote.add("--setuid=" + uid);
argsForZygote.add("--setgid=" + gid);
argsForZygote.add("--runtime-flags=" + runtimeFlags);

// ... 根据 mountExternal 添加对应的挂载模式参数。
argsForZygote.add("--target-sdk-version="
        + targetSdkVersion);

if (gids != null && gids.length > 0) {
    final StringBuilder sb = new StringBuilder();
    sb.append("--setgroups=");

    final int sz = gids.length;
    for (int i = 0; i < sz; i++) {
        if (i != 0) {
            sb.append(',');
        }
        sb.append(gids[i]);
    }

    argsForZygote.add(sb.toString());
}
if (niceName != null) {
    argsForZygote.add("--nice-name=" + niceName);
}
if (seInfo != null) {
    argsForZygote.add("--seinfo=" + seInfo);
}
if (instructionSet != null) {
    argsForZygote.add("--instruction-set="
            + instructionSet);
}
if (appDataDir != null) {
    argsForZygote.add("--app-data-dir=" + appDataDir);
}

argsForZygote.add(processClass);
if (extraArgs != null) {
    Collections.addAll(argsForZygote, extraArgs);
}

上面保留了参数类别、顺序和 supplementary groups 的真实构造过程。真正写 socket 前还有一次完整校验。

源码文件：frameworks/base/core/java/android/os/ZygoteProcess.java

相关函数：zygoteSendArgsAndGetResult

java

for (String arg : args) {
    // 本文注：先验证整个列表，避免只发送半条命令。
    if (arg.indexOf('\n') >= 0) {
        throw new ZygoteStartFailedEx(
                "Embedded newlines not allowed");
    } else if (arg.indexOf('\r') >= 0) {
        throw new ZygoteStartFailedEx(
                "Embedded carriage returns not allowed");
    } else if (arg.indexOf('\u0000') >= 0) {
        throw new ZygoteStartFailedEx(
                "Embedded nulls not allowed");
    }
}

// 本文注：第一行是参数数量，后续每行一个参数。
String msgStr = args.size() + "\n"
        + String.join("\n", args) + "\n";

换行、回车和 NUL 会破坏帧边界，所以校验发生在任何写入之前。这是协议的失败原子性：编码失败不会让 Zygote 收到一个参数计数正确、内容却不完整的请求。socket I/O 失败则属于另一层，调用方会将其包装为进程启动失败并清理 mPendingStarts。

4.3 attach闭环

应用子进程从 RuntimeInit.applicationInit() 找到 ActivityThread.main()。startSeq 作为普通命令行参数进入应用进程，并在 attach 时原样带回 AMS。

源码文件：frameworks/base/core/java/android/app/ActivityThread.java

4.4 失败清理

场景	检测位置	清理动作	恢复单位
参数含换行、回车或 NUL	`ZygoteProcess` 写 socket 前	不发送请求，抛出启动异常	当前启动尝试
socket 或 fork 失败	`ProcessList.handleProcessStart()`	删除 `mPendingStarts`、清除 `pendingStart`、force-stop、early cleanup	包或进程启动请求
迟到的 fork 结果	`isProcStartValidLocked()`	杀新 pid、记录退出原因、early cleanup	当前 pid
pid 被旧记录占用	`attachApplicationLocked()`	清理旧 `ProcessRecord` 和 pid map	pid 映射
attach 无匹配记录	`attachApplicationLocked()`	写 `am_drop_process` 并杀进程	当前应用进程
bind 完成超时	AMS timeout handler	杀掉卡住的 `ProcessRecord`	当前应用进程

这一链路没有“收到 pid 就成功”的单一完成点。至少要观察 Zygote 返回、AMS 接受 pid、应用 attach、bindApplication 执行和最终超时消息移除。需要逐步跟踪参数和 Binder 回调时，可继续阅读 Zygote参数传递协议、子进程PID管理和 handleBindApplication。

5. 故障坐标

下面的关系图把“现象”连接到第一个值得检查的 owner。它不是自动诊断器，而是避免一上来就在错误进程里搜日志。

把图转换成源码搜索表，可以得到更具体的入口：

现象	第一入口	状态 owner	下一消费者	关键边界
`StartServices` 很长	`SystemServer.run()`	SystemServer 主线程	四个服务分组	trace slice 可能不等待服务内部异步任务
某服务 `onStart()` 已运行但客户端查不到	`publishBinderService()`	服务实例与 servicemanager	`ServiceManager.getService()`	Java 生命周期与 Binder 发布是两次操作
Boot Phase 卡住	`startBootPhase()`	`mCurrentPhase`、Future 数组	下一阶段调用方	并行任务仍由 `Future.get()` 汇合
应用启动一直 pending	`startProcessLocked()`	`ProcessRecord`、`mPendingStarts`	Zygote socket	异步投递成功不等于 fork 成功
有 pid 但 attach 被拒绝	`attachApplicationLocked()`	AMS pid map	bindApplication	pid、uid、`startSeq` 必须同时匹配
system_server 崩溃后重启	`ZygoteInit` 与 init service	Zygote/init	新 system_server	恢复单位是进程，不是单个服务
首次启动明显更慢	`isFirstBootOrUpgrade()`、PMS	PackageManagerService	启动统计与 dexopt	不能和普通启动样本直接比较
多用户切换后进程异常	`UserController`、SSM user callbacks	用户状态与 per-user 进程	各系统服务	user 事件与全局 Boot Phase 是两套生命周期
RSS/PSS 持续增长	`dumpsys meminfo`、heap/native owner	system_server heap、native allocator	GC、服务缓存、native 组件	单次 PSS 不能证明泄漏

6. 测试边界

6.1 服务注册测试

源码文件：frameworks/base/services/tests/servicestests/src/com/android/server/SystemServiceManagerTest.java。

java

@Test
public void testDuplicateServices() throws Exception {
    AtomicInteger counter = new AtomicInteger(0);
    SystemService service = new SystemService(getContext()) {
        @Override
        public void onStart() {
            counter.incrementAndGet();
        }
    };

    mSystemServiceManager.startService(service);
    assertEquals(1, counter.get());

    // 本文注：第二次提交同一服务类不能再次执行 onStart()。
    mSystemServiceManager.startService(service);
    assertEquals(1, counter.get());
}

@Test
public void testSealStartedServices() throws Exception {
    // ... 构造 service1 和 service2；service2.onStart() 若被调用会主动失败。
    mSystemServiceManager.startService(service1);
    assertTrue(serviceStarted.get());

    mSystemServiceManager.sealStartedServices();
    assertThrows(UnsupportedOperationException.class,
            () -> mSystemServiceManager.startService(service2));
}

第一个测试的输入是同一个服务实例被提交两次，关键断言是 onStart() 计数仍为 1，它验证类名集合确实承担去重职责。第二个测试先启动一个服务，再封存列表并尝试新增服务，关键断言是抛出 UnsupportedOperationException；它验证封存后的列表不再接受写入。两者都没有覆盖 Boot Phase 并行任务、Binder 名称发布或 onStart() 失败后的进程恢复，不能据此推导这些路径也正确。

6.2 进程超时测试

源码文件：frameworks/base/services/tests/mockingservicestests/src/com/android/server/am/AsyncProcessStartTest.java。

java

@Test
public void testNormal() throws Exception {
    if (mRealAms.mConstants
            .mEnableWaitForFinishAttachApplication) {
        ProcessRecord app =
                startProcessAndWait(false);
        verify(app, never())
                .killLocked(any(), anyInt(), anyBoolean());
    }
}

@Test
public void testWedged() throws Exception {
    ProcessRecord app = startProcessAndWait(true);

    verify(app).killLocked(
            any(), anyInt(), anyBoolean());
}

两个测试共同调用真实测试辅助函数 startProcessAndWait()：它先让 ProcessList 接受 pid，再调用测试 IApplicationThread.bindApplication()；wedge=false 时测试线程回报 finish-attach，wedge=true 时等待超过 PROC_START_TIMEOUT。关键断言分别是正常进程不被杀、超时进程必须被杀。它验证了“fork/pid 已完成仍不代表启动完成”，以及超时消息的消费者确实执行清理；但它没有经过真实 Zygote socket、native fork 或设备调度，因此不能用来衡量真实启动耗时。

6.3 参数解析测试

源码文件：frameworks/base/core/tests/coretests/src/com/android/internal/os/ZygoteArgumentsTest.java。

java

@Test
public void testParseAndMergeCompatChanges_dedup() {
    long[] changes = {1, 2};

    changes = ZygoteArguments.parseAndMergeCompatChanges(
            "--enabled-compat-changes=2,3,3,4",
            changes);

    long[] expected = {1, 2, 3, 4};
    assertArrayEquals(expected, changes);
}

@Test
public void testParseAndMergeCompatChanges_malformed() {
    long[] changes = null;

    changes = ZygoteArguments.parseAndMergeCompatChanges(
            "--disabled-compat-changes=1,,2",
            changes);

    long[] expected = {1, 2};
    assertArrayEquals(expected, changes);
}

这组测试验证 compat change 参数在多次输入下会排序、合并和去重，并允许空片段；它说明 Zygote 参数不是简单字符串透传，而是会形成结构化状态。测试没有覆盖 socket 帧校验、UID/GID 权限限制和 native specialization，阅读参数链时仍要继续跟到 ZygoteArguments.getInstance() 与 Zygote.nativeForkAndSpecialize()。

7. 全篇索引

索引按问题所有者分组。每个链接的可见名称都与文章标题一致；编号只留在目标文件名中，不要求读者记忆。

7.1 Zygote入口

阅读目的	文章
建立全局进程图	Android启动全景
找到 native 入口	app_process入口、AndroidRuntime.start
进入 Java 主线	ZygoteInit.main、Zygote socket注册
理解共享预加载	Zygote预加载、preloadClasses、preloadResources、Zygote fork准备
理解双进程与请求循环	Zygote双进程、ZygoteServer循环、Zygote安全限制

7.2 SystemServer入口

阅读目的	文章
跟踪 fork 后接管	forkSystemServer、SystemServer接管、zygoteInit与RuntimeInit
跟踪 Java 启动骨架	SystemServer.main、SystemServer.run、createSystemContext
分解服务分组	Bootstrap服务、Core服务、Other服务、APEX服务

7.3 服务编排

阅读目的	文章
区分名称注册与实例管理	ServiceManager.addService、SystemServiceManager
理解生命周期和阶段	SystemService生命周期、BootPhase阶段
理解存活监控和顺序	Watchdog监控、核心服务顺序、AMS/WMS/PMS时序
分析依赖与耗时	服务依赖关系、服务启动耗时、Trampoline模式

7.4 应用进程

阅读目的	文章
进入创建请求	Process.start、ZygoteProcess.start
理解 fork 策略	USAP池、fork与COW、进程specialization、ABI进程选择
进入应用 Java 世界	RuntimeInit.applicationInit、ActivityThread.main、handleBindApplication、Application.onCreate

7.5 协议与隔离

阅读目的	文章
跟踪 socket 请求	LocalSocket与Zygote通信、ZygoteConnection.processCommand、Zygote参数传递协议
跟踪 pid 生死	子进程PID管理、SIGCHLD进程死亡处理
理解安全身份	进程UID/GID设置、进程Capability设置、Seccomp沙箱

7.6 启动优化

阅读目的	文章
建立时间线	启动时间分析、开机动画时序、启动场景判定
选择优化手段	预加载优化、并行启动、延迟启动

7.7 运行诊断

阅读目的	文章
处理进程级故障	崩溃恢复链
处理环境差异	多用户进程、容器化启动
处理资源与性能	SystemServer内存、SystemServer分析

8. 问题入口

你要回答的问题	建议起点	继续深入	不要先做什么
哪个阶段拖慢开机	启动时间分析	并行启动、SystemServer分析	先改 preload 列表
某系统服务为什么没起来	SystemServiceManager	SystemService生命周期、服务依赖关系	只搜 `addService` 字符串
应用为什么没有 pid	Process.start	ZygoteProcess.start、Zygote参数传递协议	直接从 `Application.onCreate()` 倒推
有 pid 为什么没进入应用	ActivityThread.main	handleBindApplication、子进程PID管理	把 fork 返回当成启动完成
system_server 为什么反复重启	崩溃恢复链	Watchdog监控、SIGCHLD进程死亡处理	只查看最后一次 Java exception
用户切换后哪些服务被通知	多用户进程	SystemService生命周期	把用户事件当作 Boot Phase
Cuttlefish 中 Zygote 有何差异	容器化启动	进程Capability设置、进程specialization	假设宿主 capability 全部可用
system_server RSS/PSS 为什么增长	SystemServer内存	SystemServer分析	用一份 `meminfo` 直接下泄漏结论
首次启动为何无法复现普通启动	启动场景判定	预加载优化	混合 first boot、OTA 和 runtime restart 样本

9. 源码导航

以下命令都在 AOSP 根目录执行。注释先说明问题，再给出搜索范围，避免全仓搜索产生大量同名符号。

bash

# 找到 SystemServer 服务分组、阶段推进和最终主循环。
rg -n 'start(Bootstrap|Core|Other|Apex)Services|startBootPhase|Looper\.loop' \
  frameworks/base/services/java/com/android/server/SystemServer.java \
  frameworks/base/services/core/java/com/android/server/SystemServiceManager.java

若问题发生在 fork 前后，再把搜索范围切换到 Zygote 入口和请求循环：

bash

# 找到 system_server fork 的父子分支和应用请求循环。
rg -n 'forkSystemServer|handleSystemServerProcess|runSelectLoop' \
  frameworks/base/core/java/com/android/internal/os/ZygoteInit.java \
  frameworks/base/core/java/com/android/internal/os/ZygoteServer.java

若现象是应用进程迟迟不能完成启动，先追踪 AMS 持有的启动序号：

bash

# 跟踪同一个 startSeq 如何从 ProcessList 进入应用，再返回 AMS。
rg -n 'mProcStartSeqCounter|mPendingStarts|PROC_START_SEQ_IDENT|attachApplication' \
  frameworks/base/services/core/java/com/android/server/am/ProcessList.java \
  frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java \
  frameworks/base/core/java/android/app/ActivityThread.java

确认 startSeq 主线后，再检查它与安全身份如何一起编码和解析：

bash

# 查找 Zygote 参数编码、解析和 native specialization 的边界。
rg -n 'startViaZygote|zygoteSendArgsAndGetResult|getInstance|nativeForkAndSpecialize' \
  frameworks/base/core/java/android/os/ZygoteProcess.java \
  frameworks/base/core/java/com/android/internal/os/ZygoteArguments.java \
  frameworks/base/core/java/com/android/internal/os/Zygote.java

完成静态阅读后，可以用对应测试检查服务去重和 attach 超时边界：

bash

# 运行前先确认设备或测试环境支持对应模块；两个测试分别覆盖服务注册和启动超时。
atest SystemServiceManagerTest AsyncProcessStartTest

命令输出的函数位置只是入口。真正阅读时，应继续回答四个问题：谁写状态、在哪把状态交给另一个进程或线程、哪个条件使它生效、失败时由谁清理。

10. 闭环复述

从 ZygoteInit.main() 开始，分别复述父 Zygote、system_server 子进程和普通应用子进程的返回值与下一入口，并指出每条路径关闭哪个 socket。
选择一个 SystemService，分别找到它进入 mServices、执行 onStart()、发布 Binder 或 LocalService、接收关键 Boot Phase 的位置。若四个位置不全，说明缺少的是哪一种能力。
从 ProcessList.startProcessLocked() 的 startSeq 出发，追到 ZygoteProcess 参数列表、ActivityThread.main() 参数解析和 ActivityManagerService.attachApplicationLocked() 校验。然后解释 pid 复用为什么不能只靠 pid 识别启动尝试。
给定“开机慢但 CPU 不高”的现象，先用启动时间分析找长阶段，再检查该阶段是否等待 Future.get()、Binder 返回或锁；只有确认 owner 后，才选择 SystemServer分析中的 Perfetto、BinderCallsStats 或 LooperStats。

这四条主线能完整复述后，SystemServer 就不再是一份超长启动函数，而是一组边界清楚的状态交接：Zygote 交出进程控制权，SystemServiceManager 交出生命周期阶段，servicemanager 交出跨进程可发现性，ProcessList 用 startSeq 把异步 fork 和应用 attach 收拢为同一次启动事务。以后遇到新服务、新启动 flag 或新的进程类型，先把它放回这套所有权坐标，再沿真实调用方和消费者向两端扩展。

SystemServer知识图谱 ​

1. 四层所有权 ​

2. 启动主线 ​

2.1 Zygote分叉 ​

2.2 服务分组 ​

2.3 主循环 ​

3. 服务状态 ​

3.1 实例与名称 ​

3.2 阶段推进 ​

3.3 失败边界 ​

4. 进程主线 ​

4.1 待启动状态 ​

4.2 参数协议 ​

4.3 attach闭环 ​

4.4 失败清理 ​

5. 故障坐标 ​

6. 测试边界 ​

6.1 服务注册测试 ​

6.2 进程超时测试 ​

6.3 参数解析测试 ​

7. 全篇索引 ​

7.1 Zygote入口 ​

7.2 SystemServer入口 ​

7.3 服务编排 ​

7.4 应用进程 ​

7.5 协议与隔离 ​

7.6 启动优化 ​

7.7 运行诊断 ​

8. 问题入口 ​

9. 源码导航 ​

10. 闭环复述 ​

SystemServer知识图谱

1. 四层所有权

2. 启动主线

2.1 Zygote分叉

2.2 服务分组

2.3 主循环

3. 服务状态

3.1 实例与名称

3.2 阶段推进

3.3 失败边界

4. 进程主线

4.1 待启动状态

4.2 参数协议

4.3 attach闭环

4.4 失败清理

5. 故障坐标

6. 测试边界

6.1 服务注册测试

6.2 进程超时测试

6.3 参数解析测试

7. 全篇索引

7.1 Zygote入口

7.2 SystemServer入口

7.3 服务编排

7.4 应用进程

7.5 协议与隔离

7.6 启动优化

7.7 运行诊断

8. 问题入口

9. 源码导航

10. 闭环复述