system_server或Zygote进程死亡后，Zygote fork出的app子进程销毁流程

下面按Android 15 / AOSP 主线实现输出结论、关键代码路径和校验方法。重点回答：system_server 或 Zygote 死亡后，由 Zygote fork 出来的 app 进程如何被销毁。

首先给出数据证据，确认system_server和app的process group来自zygote：

adb shell ps -ef |grep -Ei "test|system_server|zygote" root 431 1 0 10:13:32 ? 00:00:01 zygote64 system 785 431 6 10:13:34 ? 00:00:16 system_server webview_zygote 1144 431 0 10:13:36 ? 00:00:00 webview_zygote u10_a211 3023 431 0 10:14:21 ? 00:00:00 com.example.test adb shell cat /proc/785/stat 785 (system_server) S 431 431 0 0 -1 4194624 189396 1902 1086 0 1075 558 0 1 18 -2 237 0 724 18295746560 92123 18446744073709551615 96517870370816 96517870375168 140733830651120 0 0 0 4612 1 1073775864 0 0 0 17 3 0 0 0 0 0 96517870403584 96517870403608 96517893808128 140733830654952 140733830655051 140733830655051 140733830660062 0 adb shell cat /proc/1144/stat 1144 (webview_zygote) S 431 431 0 0 -1 4194624 2618 0 20 0 1 0 0 0 20 0 5 0 916 34071162880 23922 18446744073709551615 96517870370816 96517870375168 140733830651120 0 0 0 4612 1 1073775864 0 0 0 17 3 0 0 0 0 0 96517870403584 96517870403608 96517893808128 140733830654952 140733830655051 140733830655051 140733830660062 0 adb shell cat /proc/3023/stat 3023 (om.example.test) S 431 431 0 0 -1 4194624 18081 0 7 0 76 14 0 0 10 -10 23 0 5476 17149894656 42262 18446744073709551615 96517870370816 96517870375168 140733830651120 0 0 0 4612 1 1073775864 0 0 0 17 2 0 0 0 0 0 96517870403584 96517870403608 96517893808128 140733830654952 140733830655051 140733830655051 140733830660062 0

1. 结论概览

1.1 system_server 死亡后的销毁链路

system_server 是 Zygote fork 出来的关键子进程；Zygote 会监听子进程 SIGCHLD，一旦发现死亡的是 system_server，就会主动 kill 自己。经典逻辑是 Zygote 的 SigChldHandler 中 waitpid(-1, ..., WNOHANG) 回收子进程，若 pid == gSystemServerPid，则执行 kill(getpid(), SIGKILL) 让 Zygote 自杀。 [blog.csdn.net], [codeleading.com]

随后init 作为 Zygote 的父进程收到 SIGCHLD，进入 service reap 流程；Zygote service 不是 oneshot，因此 init 会对该 service 的进程组执行 SIGKILL 清理，并按 rc 配置重启 Zygote。init 对子进程 SIGCHLD 的监听、ReapAnyOutstandingChildren()、Service::Reap()、KillProcessGroup(SIGKILL) 这一套机制，在 Android init 中用于回收死亡服务并重启非 oneshot 服务。 [juejin.cn], [cnblogs.com]

因此：system_server 死亡 → Zygote 自杀 → init 回收 Zygote service → init kill Zygote 进程组/相关子进程 → Zygote 重启 → system_server 重新 fork → Java framework 重建。Zygote 和 system_server 在设计上是“共存亡”的关系；system_server 死亡会触发 Zygote 退出，而 Zygote 退出会由 init 处理并重启。 [blog.csdn.net], [jianshu.com]

1.2 Zygote 死亡后的 app 进程销毁链路

Zygote 自身死亡时，app 进程不是靠 AMS 正常逐个 kill 的，因为 system_server/AMS 也会随 Zygote 重启链路一起失效；真正兜底的是 init 对 Zygote service 的 reap/kill process group 逻辑。在 Service::Reap() 中，非 oneshot service 退出时会调用 KillProcessGroup(SIGKILL)，其目的就是杀掉该服务进程组中残留的子进程，防止旧 Zygote fork 出来的进程继续运行。 [juejin.cn], [cnblogs.com]

Android Zygote 启动时会把自己放入独立进程组，ZygoteInit.main() 中存在 Os.setpgid(0, 0) 这类逻辑，Zygote fork 出来的 system_server/app 进程天然和 Zygote 有同源进程关系；旧版本文档和源码分析中也明确指出 Zygote 挂掉时 init 会 kill 其进程组，从而清理 system_server 和 app 子进程。 [juejin.cn], [blog.csdn.net]

简单说：app 进程的销毁不是由新 Zygote 或新 system_server 事后“扫描旧 app 再 kill”，而是 Zygote service 死亡瞬间，由 init 的 service reap / process group kill 机制完成大清场。

2. 关键流程图

3. 涉及类 / 文件

4. 关键代码校验点

说明：下面代码片段是为了说明机制，实际 Android 15 代码请以本地 AOSP android-15.0.0_r* tag 为准。AOSP 官方说明源码由 Google 托管在 Git 仓库中，可通过 repo init / repo sync 获取；也可用 cs.android.com 在线浏览。 [source.and....google.cn], [mirrors.tu...hua.edu.cn]

4.1 init.zygote*.rc：Zygote 由 init 管理，不是 oneshot

Android 15 典型 init.zygote64.rc / init.zygote64_32.rc 中，Zygote service 形态如下：

校验点：

• 没有oneshot：Zygote 死亡后 init 会按常驻 service 处理，进入 restart 流程。 [juejin.cn], [blog.csdn.net]
• 有onrestart：Zygote 重启时会联动重启 audioserver、cameraserver、media、netd、wificond 等服务。 [blog.csdn.net], [juejin.cn]
• 有critical：Android 15 配置中 Zygote 是 critical service，短时间频繁崩溃会触发更高等级故障处理。 [blog.csdn.net], [blog.csdn.net]

4.2 ZygoteInit：启动时 fork system_server，随后进入 select loop

校验点：

• Zygote 启动后会先 fork system_server，然后父进程继续 runSelectLoop() 等待 AMS/ProcessList 请求 fork app。 [juejin.cn], [blog.csdn.net]
• app 进程并不是 system_server 直接 fork() 出来的，而是 system_server 通过 socket 请求 Zygote fork。AOSP 文档也说明 Zygote 作为 root/孵化器，负责生成系统和应用进程，system_server 通过 Unix domain socket 请求 Zygote 创建进程。 [source.and....google.cn], [blog.csdn.net]

4.3 Zygote native：system_server 死亡时 Zygote 自杀

关键逻辑如下：

校验点：

• Zygote 监听所有子进程 SIGCHLD。 [blog.csdn.net], [jianshu.com]
• 只有死亡的是 gSystemServerPid 时，Zygote 才会主动 SIGKILL 自己。 [blog.csdn.net], [codeleading.com]
• 普通 app 进程死亡不会导致 Zygote 自杀；普通 app 死亡由 AMS/ProcessList 维护进程状态，必要时重启对应组件。此点可从 handler 只判断 gSystemServerPid 推出。 [blog.csdn.net], [jianshu.com]

4.4 init：Zygote service 死亡后 kill process group

init 对 service 退出的通用处理如下：

校验点：

• init 通过 SIGCHLD 知道子服务退出，然后 ReapOneProcess() 找到对应 Service 并调用 Service::Reap()。 [juejin.cn], [blog.csdn.net]
• 对非 oneshot service，Service::Reap() 会调用 KillProcessGroup(SIGKILL)，用于杀掉该服务进程组中的残留进程。 [cnblogs.com], [juejin.cn]
• Zygote service 没有 oneshot，所以 Zygote 死亡会走 kill process group + restart 逻辑。 [blog.csdn.net], [juejin.cn]

5. app 进程到底在哪里被 kill？

5.1 不是 AMS 正常 kill

当 system_server 已经挂了，AMS 自身也不存在了；因此不可能依赖 AMS 按 ProcessRecord 一个个执行正常 kill。system_server 是承载 AMS/PMS/WMS 等 Java framework 服务的核心进程，死亡后 framework 控制面已经失效。 [blog.csdn.net], [segmentfault.com]

5.2 不是 Zygote 自己遍历 kill app

Zygote 的 SIGCHLD handler 主要做的是回收子进程并判断 gSystemServerPid；发现 system_server 死亡后，Zygote 选择 kill(getpid(), SIGKILL) 自杀，而不是遍历所有 app pid。 [blog.csdn.net], [jianshu.com]

5.3 真正兜底：init kill Zygote service 进程组

Zygote 被 kill 后，init 作为其父进程收到 SIGCHLD，进入 Service::Reap()；Zygote 非 oneshot，因此 init 会 KillProcessGroup(SIGKILL) 清理旧 Zygote service 相关进程，达到销毁旧 app 进程的目的。 [cnblogs.com], [juejin.cn]

6. 本地代码校验命令

建议在 Android 15 源码根目录执行：

如果第 4 步能查到 gSystemServerPid、waitpid、kill(getpid(), SIGKILL) 相关代码，第 5 步能查到 Service::Reap() 中对非 oneshot service 调用 KillProcessGroup(SIGKILL)，就可以确认本文结论成立。

7. 最终结论

Android 15 上，system_server 死亡后，Zygote 会通过 SIGCHLD 发现gSystemServerPid退出，然后主动 SIGKILL 自己；Zygote 死亡后，init 会回收 Zygote service，并对该 service 的进程组执行 SIGKILL 清理，旧 Zygote fork 出来的 app 进程随之被销毁。之后 init 根据init.zygote*.rc重启 Zygote，新 Zygote 再 fork 新 system_server，系统服务重新建立。

一句话总结：