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

发布时间:2026/8/26 6:13:09

system_server或Zygote进程死亡后,Zygote fork出的app子进程销毁流程
下面按Android 15 / AOSP 主线实现输出结论、关键代码路径和校验方法。重点回答system_server 或 Zygote 死亡后由 Zygote fork 出来的 app 进程如何被销毁。首先给出数据证据确认system_server和app的process group来自zygoteadb 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 01. 结论概览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. 关键流程图1场景 Asystem_server 死亡23system_server crash / kill4↓5Zygote 收到 SIGCHLD6↓7Zygote SigChldHandler waitpid()8↓9发现 pid gSystemServerPid10↓11Zygote kill(getpid(), SIGKILL) 自杀12↓13init 收到 Zygote SIGCHLD14↓15Service::Reap(zygote)16↓17KillProcessGroup(SIGKILL)18↓19清理旧 Zygote 进程组及其 fork 出来的 app / system_server 残留进程20↓21执行 onrestart22↓23重启 Zygote24↓25新 Zygote fork 新 system_server1场景 BZygote 自身死亡23zygote crash / kill4↓5init 收到 SIGCHLD6↓7Service::Reap(zygote)8↓9KillProcessGroup(SIGKILL)10↓11清理旧 Zygote 进程组中的残留子进程12↓13执行 init.zygote*.rc 中 onrestart 命令14↓15重启 zygote / zygote_secondary16↓17新 system_server 启动18↓19系统服务重新建立app 进程重新按需启动3. 涉及类 / 文件模块关键文件 / 类作用initsystem/core/init/init.cpp安装 SIGCHLD 监听init 主循环处理子进程退出。 [juejin.cn], [blog.csdn.net]initsystem/core/init/sigchld_handler.cppReapAnyOutstandingChildren() 回收退出子进程。 [juejin.cn], [blog.csdn.net]initsystem/core/init/service.cppService::Reap() 中 kill service 进程组并重启非 oneshot 服务。 [cnblogs.com], [juejin.cn]init rcsystem/core/rootdir/init.zygote64.rc / init.zygote64_32.rc定义 Zygote service、socket、onrestart、critical 等。 [blog.csdn.net], [juejin.cn]Zygoteframeworks/base/core/java/com/android/internal/os/ZygoteInit.javaZygote Java 入口preload、fork system_server、runSelectLoop。 [juejin.cn], [blog.csdn.net]Zygoteframeworks/base/core/java/com/android/internal/os/Zygote.java调用 native fork system_server/app。 [juejin.cn], [cnblogs.com]Zygote nativeframeworks/base/core/jni/com_android_internal_os_Zygote.cppfork、SIGCHLD handler、system_server 死亡时 kill Zygote。 [blog.csdn.net], [codeleading.com]system_serverframeworks/base/services/java/com/android/server/SystemServer.javasystem_server Java 入口启动 AMS/PMS/WMS 等系统服务。 [juejin.cn], [blog.csdn.net]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*.rcZygote 由 init 管理不是 oneshotAndroid 15 典型 init.zygote64.rc / init.zygote64_32.rc 中Zygote service 形态如下1service zygote /system/bin/app_process64 -Xzygote /system/bin \2--zygote --start-system-server --socket-namezygote3class main4priority -205user root6group root readproc reserved_disk7socket zygote stream 660 root system8socket usap_pool_primary stream 660 root system9onrestart restart audioserver10onrestart restart cameraserver11onrestart restart media12onrestart restart netd13onrestart restart wificond14task_profiles ProcessCapacityHigh MaxPerformance15critical window${zygote.critical_window.minute:-off} targetzygote-fatal校验点没有oneshotZygote 死亡后 init 会按常驻 service 处理进入 restart 流程。 [juejin.cn], [blog.csdn.net]有onrestartZygote 重启时会联动重启 audioserver、cameraserver、media、netd、wificond 等服务。 [blog.csdn.net], [juejin.cn]有criticalAndroid 15 配置中 Zygote 是 critical service短时间频繁崩溃会触发更高等级故障处理。 [blog.csdn.net], [blog.csdn.net]4.2 ZygoteInit启动时 fork system_server随后进入 select loop1// frameworks/base/core/java/com/android/internal/os/ZygoteInit.java23if(startSystemServer) {4RunnablerforkSystemServer(abiList, zygoteSocketName, zygoteServer);56// r null: parent zygote7// r ! null: child system_server8if(r!null) {9r.run();10return;11}12}1314Log.i(TAG,Accepting command socket connections);15callerzygoteServer.runSelectLoop(abiList);校验点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 nativesystem_server 死亡时 Zygote 自杀关键逻辑如下1// frameworks/base/core/jni/com_android_internal_os_Zygote.cpp23staticvoidSigChldHandler(int/*signal_number*/) {4pid_tpid;5intstatus;67while((pidwaitpid(-1,status, WNOHANG))0) {8if(pidgSystemServerPid) {9ALOGE(Exit zygote because system server (%d) has terminated, pid);10kill(getpid(), SIGKILL);11}12}13}校验点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 initZygote service 死亡后 kill process groupinit 对 service 退出的通用处理如下1// system/core/init/service.cpp23voidService::Reap(constsiginfo_tsiginfo) {4if(!(flags_SVC_ONESHOT)||(flags_SVC_RESTART)) {5KillProcessGroup(SIGKILL);6}78pid_0;9flags_(~SVC_RUNNING);1011// 非 disabled / reset service 后续进入 restart12flags_|SVC_RESTARTING;13onrestart_.ExecuteAllCommands();14}校验点init 通过 SIGCHLD 知道子服务退出然后 ReapOneProcess() 找到对应 Service 并调用 Service::Reap()。 [juejin.cn], [blog.csdn.net]对非 oneshot serviceService::Reap() 会调用 KillProcessGroup(SIGKILL)用于杀掉该服务进程组中的残留进程。 [cnblogs.com], [juejin.cn]Zygote service 没有 oneshot所以 Zygote 死亡会走 kill process group restart 逻辑。 [blog.csdn.net], [juejin.cn]5. app 进程到底在哪里被 kill5.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 appZygote 的 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 源码根目录执行1# 1. 确认源码 tag2repomanifest-r|grep-Eandroid-15|platform/frameworks/base|platform/system/core34# 2. 校验 zygote rc5grep-Rservice zygote-nsystem/core/rootdir/init.zygote*.rc6grep-Rcritical window.*zygote-fatal-nsystem/core/rootdir/init.zygote*.rc7grep-Ronrestart restart-nsystem/core/rootdir/init.zygote*.rc89# 3. 校验 ZygoteInit fork system_server10grep-RforkSystemServer-nframeworks/base/core/java/com/android/internal/os/ZygoteInit.java11grep-RrunSelectLoop-nframeworks/base/core/java/com/android/internal/os/ZygoteInit.java1213# 4. 校验 native SIGCHLD / system_server death14grep-RgSystemServerPid-nframeworks/base/core/jni/com_android_internal_os_Zygote.cpp15grep-RExit zygote because system server-nframeworks/base/core/jni/com_android_internal_os_Zygote.cpp16grep-RSIGCHLD-nframeworks/base/core/jni/com_android_internal_os_Zygote.cpp1718# 5. 校验 init 子进程回收19grep-RInstallSignalFdHandler-nsystem/core/init20grep-RReapAnyOutstandingChildren-nsystem/core/init21grep-RService::Reap-nsystem/core/init22grep-RKillProcessGroup-nsystem/core/init如果第 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系统服务重新建立。一句话总结1system_server 死亡2→ Zygote 自杀3→ init reap zygote4→ init KillProcessGroup(SIGKILL)5→ 旧 app 进程被清理6→ Zygote / system_server 重启1Zygote 直接死亡2→ init reap zygote3→ init KillProcessGroup(SIGKILL)4→ 旧 app 进程被清理5→ Zygote / system_server 重启

相关新闻

为什么选择easy-checker?openEuler社区开发者的效率提升秘诀

为什么选择easy-checker?openEuler社区开发者的效率提升秘诀

2026/8/22 17:42:41

为什么选择easy-checker?openEuler社区开发者的效率提升秘诀 【免费下载链接】easy-checker A series of checking tools used in openEuler community 项目地址: https://gitcode.com/openeuler/easy-checker 前往项目官网免费下载:https://ar.o…

国产大模型网页穿透能力实测:付费墙识别与内容可访问性推理

国产大模型网页穿透能力实测:付费墙识别与内容可访问性推理

2026/8/22 17:42:41

1. 项目概述:一场聚焦“内容穿透力”的务实测评2026年4月,国产大模型已从参数竞赛迈入真实场景攻坚阶段。当用户面对一篇被付费墙拦住的深度行业报告、一份被设置为“仅会员可见”的政策解读PDF、或是一段嵌在加密iframe里的财经数据图表时,真…

锂离子电池过压保护方案与BQ29200应用实践

锂离子电池过压保护方案与BQ29200应用实践

2026/8/22 17:42:42

1. 锂离子电池过压保护的必要性与BQ29200方案选型 锂离子电池因其高能量密度和长循环寿命,已成为便携式电子设备、电动工具乃至电动汽车的主流电源选择。然而过充电是导致锂离子电池性能衰退甚至热失控的最常见诱因——当单体电池电压超过4.35V时,正极材…

基于高德Skill的智能选址:从经验直觉到数据驱动的产品实践

基于高德Skill的智能选址:从经验直觉到数据驱动的产品实践

2026/8/27 4:57:29

1. 从“感觉不错”到“数据说话”:一个产品经理的自我革命做产品,尤其是做那种带点“玄学”判断的产品,比如选址,最怕的就是“拍脑袋”。几年前,我负责一个线下零售的选址分析工具,团队里有个老法师&#x…

智能零售柜商品识别数据集实战:VOC转YOLO与精度提升指南

智能零售柜商品识别数据集实战:VOC转YOLO与精度提升指南

2026/8/27 4:57:29

简介:目标检测技术在智能零售领域的落地,往往受制于标注数据的质量与格式。VOC格式的XML标注文件是公开数据集常用的载体,但直接用于现代检测框架时,常遇到字段不一致、坐标越界、类目划分粒度不足等问题。理解从原始标注到训练数…

从Prompt工程到AI Agent:大语言模型应用开发核心技术栈解析

从Prompt工程到AI Agent:大语言模型应用开发核心技术栈解析

2026/8/27 4:57:29

1. 项目概述:从“玩具”到“工具”的认知跃迁几年前,当我和团队第一次把玩GPT-3的API时,那种感觉更像是在测试一个有趣的“玩具”——输入一些稀奇古怪的问题,看它能吐出什么令人捧腹或惊讶的答案。但今天,当“大语言模…

基于QLoRA的视觉语言大模型高效指令微调实战指南

基于QLoRA的视觉语言大模型高效指令微调实战指南

2026/8/27 4:57:29

简介:指令微调是提升预训练大模型在特定任务上表现的关键技术。其核心原理是通过引入高质量的指令-输出配对数据,引导模型学习并强化特定领域的任务模式与响应格式,从而实现从通用能力到专业能力的迁移。在工程实践中,参数高效微调…

数学建模实战:CNN核心原理与PyTorch应用指南

数学建模实战:CNN核心原理与PyTorch应用指南

2026/8/27 4:57:29

1. 项目概述:当数学建模遇上卷积神经网络 如果你正在准备数学建模竞赛,或者手头有一个涉及图像、信号或序列数据的分析项目,却对“卷积神经网络”这个听起来高大上的词感到既向往又头疼,那你来对地方了。我参加过不少数学建模比赛…

数维杯数学建模实战指南:从环境配置到Docker交付

数维杯数学建模实战指南:从环境配置到Docker交付

2026/8/27 4:47:28

1. 这不是一份“说明书”,而是一份赛前30天的实战作战地图“数维杯”这四个字,对很多数学建模新手来说,第一反应是——“又一个比赛?和美赛、国赛有什么区别?”我带过七届校队,从2017年第一届数维杯开始跟进…

[光学原理与应用-521]:对光的错误理解与纠偏

[光学原理与应用-521]:对光的错误理解与纠偏

2026/8/26 1:50:39

首先光是一种能量的载体和形态,宏观上观察到的光是由无数个微观的光量子组成的,每个光子在产生的瞬间,其在真空的空间中以确定不变的速度沿着一个初始的方向一直向前,在微观层面,每个光量子的运动轨迹是以波函数所展现…

SIP通话转接原理与REFER方法实战解析

SIP通话转接原理与REFER方法实战解析

2026/8/26 1:49:16

1. 通话转接不是“挂断再拨号”,而是SIP会话的动态重定向你有没有遇到过这样的场景:客服坐席A正在和客户通电话,突然需要把这通对话无缝转给专家坐席B,客户完全感知不到中间的断连——既没听到忙音,也没被要求重新拨号…

Kolla-ansible单节点OpenStack部署实战:从环境准备到排坑指南

Kolla-ansible单节点OpenStack部署实战:从环境准备到排坑指南

2026/8/26 17:50:58

1. 为什么选择Kolla-ansible来部署单节点OpenStack?如果你正在寻找一种能把OpenStack从“概念”快速变成“可用的实验环境”的方法,那么Kolla-ansible几乎是当前最主流、最省心的选择。我见过太多人卡在手动编译依赖、配置服务、处理版本冲突的泥潭里&am…

Go语言构建企业级AI服务网关:统一管理英伟达等AI接口调用

Go语言构建企业级AI服务网关:统一管理英伟达等AI接口调用

2026/8/27 0:07:12

1. 项目概述:从零构建一个企业级的AI服务网关 最近在帮一个做内容审核的团队做技术架构升级,他们原来的业务里,每天有几十万张图片和短视频需要过审,最初是接了几个开源的AI模型自己部署,但效果和性能一直不太稳定。后…

LeetCode Hot100(51-60)算法精解与面试技巧

LeetCode Hot100(51-60)算法精解与面试技巧

2026/8/27 0:07:12

1. 题目背景与核心价值"hot100(51-60)"这个标题看起来像是某个编程题库或算法练习集中的一组题目编号。在技术社区中,类似命名通常指向LeetCode、牛客网等平台的热门题目集合。作为刷过300题的算法老手,我理解这类题目的核心价值在于&#xff…

CRC校验实战:从模2除法到HJ212协议排错

CRC校验实战:从模2除法到HJ212协议排错

2026/8/27 0:07:12

1. 为什么一个“校验码”能扛住工业现场90%的数据 corruption? 你有没有遇到过这样的场景:嵌入式设备通过RS-485上传温湿度数据,上位机偶尔收到一帧乱码——温度显示成-273℃,湿度跳到999%,但串口波形看起来完全正常&a…

摆脱论文困扰!盘点2026年全网爆红的的AI论文写作工具

摆脱论文困扰!盘点2026年全网爆红的的AI论文写作工具

2026/8/22 2:02:26

一天写完毕业论文在2026年已不再是天方夜谭。2026年最炸裂、实测能大幅提速的AI论文写作工具,覆盖选题构思、文献整理、内容生成、格式排版等核心场景,真正帮你高效搞定论文难题。 一、全流程王者:一站式搞定论文全链路(一天定稿首…

导师推荐!2026最新AI论文工具测评与实用推荐

导师推荐!2026最新AI论文工具测评与实用推荐

2026/8/26 18:07:30

2026年真正好用的AI论文工具,核心看生成的论文质量、低AI味、格式正确、学术适配四大指标。综合实测,千笔AI、ThouPen、豆包、DeepSeek、Grammarly 是当前最值得推荐的梯队,覆盖从免费到付费、从中文到英文、从文科到理工的全场景需求。 一、…

告别游戏崩溃:XCOM 2模组管理器的智能革命

告别游戏崩溃:XCOM 2模组管理器的智能革命

2026/8/26 17:57:52

告别游戏崩溃:XCOM 2模组管理器的智能革命 【免费下载链接】xcom2-launcher The Alternative Mod Launcher (AML) is a replacement for the default game launchers from XCOM 2 and XCOM Chimera Squad. 项目地址: https://gitcode.com/gh_mirrors/xc/xcom2-lau…