微信不死进程的理解

我的研究缘由很多，你可以听我讲废话。最近搞鲁班猫安卓板卡总是觉得卡卡的，然后发现可能是板卡的ddr只有2g，我安卓镜像用的sd卡启动。

一共1.9g的ddr，用了1.8g真的老实了。只有36m可用，共享内存有15m，缓存816k。swap分区共976m，可用222m，空闲754m。

Ddr：

Ram的一种，动态随机存取存储器。

缓存：

内核中的缓存主要分为 Buffer（缓冲区） 和 Cache（页缓存） 两类。为提升系统 IO 效率和内存复用率而设计的内存管理机制。缓存占用的是 DDR 物理内存。

共享内存：

1. 节省物理内存，避免重复拷贝。多个进程如果需要访问同一份数据（比如系统库、应用的公共资源），不需要各自在内存中存一份副本，而是共享同一块物理内存。
2. 高效进程间通信（IPC）。传统 IPC 方式（如管道、Socket）传输数据时，需要经过 “用户态 → 内核态 → 用户态” 的多次拷贝，效率较低；而共享内存直接让多个进程访问同一块内存，数据无需拷贝，是最快的 IPC 方式。

Swap：

是系统在磁盘 / 闪存（sd卡/emmc）上划分的一块区域，核心作用是 当 DDR 物理内存不足时，临时 “置换” 出部分内存数据到磁盘，释放 DDR 空间给活跃进程使用，相当于 DDR 的 “扩展备胎”。

怎么就剩这么点了，于是我输入ps -e –sort=-rss来查看从大到小排序的执行进程。于是我看到了

这只是一部分。User是用户名。Pid是进程的id。Ppid是这个进程的父进程的id。Vzs是这个软件预计占据空间（实际上没有任何意义，因为存在不被使用的部分，是虚拟的）。Rss是进程当前占用的ddr大小。Wchan用于标识进程当前休眠的原因。ep_poll 是 epoll 机制在内核中的等待标记，epoll 是 Linux 内核提供的高性能 I/O 多路复用机制，核心作用是让单个进程高效管理大量 I/O 描述符（FD），只在 “有事件发生时” 被唤醒，其余时间休眠，避免空耗 CPU。所以wchan是eppoll基本上是等到io操作中，所以才睡眠。Addr是地址，一般是0，是虚拟地址。S是状态，有s可中断休眠，r准备，z僵尸和d不可中断休眠。Name就是进程名字。

上图看到com.tencent.mm进程的名字出现了3次，分别是主进程，push进程和recovery进程。占用了我几百m的内存（ddr内存）。我就想着我板卡b站打不开会不会是因为微信进程吃太多内存了导致没办法开b站。我kill所有的带com.tencent.mm的进程。结果怎么kill都kill不掉。

先看一张流程图

Ams：

是安卓系统的核心进程管家，是一个核心线程，它运行在 system_server 进程中，不是独立进程（所以 ps 看不到），却是微信后台自启、秒重启的总指挥。AMS 负责管理安卓应用的四大组件（Activity/Service/BroadcastReceiver/ContentProvider），微信的 :push 服务就是一个 Service 组件。

Binder：

是安卓系统基于 Linux 内核实现的内核态进程间通信（IPC）驱动 / 机制—— 它是连接 AMS、zygote64、微信进程的 “核心通信总线”，也是微信 “杀不死” 的底层技术基石。

zygote64 ：

是安卓系统的 64 位应用进程孵化器，是所有 64 位安卓应用进程（如微信主进程 /:push/:recovery、B 站进程）的父进程，核心作用是高效创建应用进程。之前我们在进程图看到微信的三个进程父进程都是269，其实269就是zygote64。他的父进程是init进程。

我打开重启系统不久，然后就会发现微信的进程默认在我手机里执行了。可能是因为加入了白名单或者提供了自启动权限，但是我安卓11镜像没找到这些，只能暂时这样理解了。

微信里有这么一个东西

你能看到标志被设置成了start_sticky。这是微信不死的关键，太深入的我就没研究了。

我们讲讲主进程被杀、:push 进程被杀、:recovery 进程被杀、:push+recovery 进程都被杀 这四种场景的重启逻辑。

前提共识：

1、微信的 :push 进程 运行 PushService 组件，向 AMS 注册了 START_STICKY 粘性服务 → AMS 会为其注册 Binder 死亡回调，主动重启。

2、:recovery 进程 是微信应用层的守护进程，和 :push 双向心跳互监 → 属于 “应用层续命”，不影响 AMS 的系统层管控。

3、主进程 运行微信界面（Activity），无粘性服务标记 → AMS 不会主动监听和重启。

场景 1：只杀主进程 → 不会被 AMS 重启，仅在需要时被 :push 唤醒

具体流程：

1、主进程被杀后，AMS 无感知：

主进程没有向 AMS 注册粘性服务，AMS 也没有为其绑定 DeathRecipient 死亡回调 → 主进程被杀后，AMS 完全不干预，不会主动重启。

2、:push 和 :recovery 正常存活：

这两个进程处于 wchan=ep_poll 休眠态，监听 Binder / 网络事件，不影响微信的推送能力。

3、主进程的 “被动重启” 触发条件“：

只有当 :push 进程收到新消息，需要弹出通知或打开微信界面时，:push 才会通过 Binder 向 AMS 发送 START_ACTIVITY 请求 → AMS 调用 zygote64 fork() 生成新的主进程。

关键结论：

主进程被杀后不会自动重启，只有需要展示界面 / 通知时才会被 :push 唤醒。微信的核心推送能力不受影响。

场景 2：只杀 :push 进程 → AMS 主动秒重启，:recovery 辅助兜底

具体流程：

1、Binder 驱动触发 AMS 死亡回调：

:push 进程被杀 → 其与 AMS 之间的 Binder 连接断开 → Binder 驱动立刻触发 AMS 预注册的 DeathRecipient 回调 → 向 AMS 发送「:push 已死」的信号。

2、AMS 主动决策重启：

AMS 读取 ServiceRecord 数据结构，发现 :push 服务是 START_STICKY 标记 → 判定 “必须重启” → 通过 Binder 向 zygote64 发送 FORK_AND_SPECIALIZE 请求。

3、zygote64 快速生成新 :push 进程：

zygote64 基于预加载的系统库，通过 fork() + 写时复制机制，毫秒级创建新的 :push 进程。

4、:recovery 辅助兜底（可选）：

若 AMS 重启延迟，:recovery 会通过心跳感知 :push 死亡 → 主动向 AMS 发 START_SERVICE 请求，加速 :push 重启。

5、新 :push 进程恢复状态：

新进程向 AMS 重新注册 START_STICKY 服务 → 进入 wchan=ep_poll 休眠态，恢复推送监听。

关键结论：

只杀 :push → AMS 必主动重启，这是微信 “杀不死” 的核心场景。

场景 3：只杀 :recovery 进程 → 无系统层重启，:push 主动重建 :recovery

具体流程：

1、:push 进程感知 :recovery 死亡：

:push 和 :recovery 通过共享内存心跳 + epoll 管道监听实现互监 → :push 长时间读取不到 :recovery 的心跳状态 → 判定 “:recovery 已死”。

2、:push 主动发起重建请求：

:push 进程通过 Binder 向 AMS 发送 START_SERVICE 请求，参数是 :recovery 对应的服务组件。

3、AMS 允许启动，zygote64 生成新 :recovery 进程：

由于 :recovery 是微信的普通服务（非粘性），AMS 校验权限合法后 → 通知 zygote64 fork() 生成新的 :recovery 进程。

4、恢复双向互监：

新 :recovery 进程与 :push 重建心跳和管道监听，回到应用层守护状态。

关键结论：

只杀 :recovery → AMS 不主动干预，重启完全由 :push 进程在应用层触发，属于微信自己的 “双保险” 机制。

场景 4：:push + :recovery 进程都被杀 → AMS 主导重启 :push，再由 :push 重建 :recovery

具体流程：

1、AMS 只监听 :push，无视 :recovery：

两个进程同时被杀后，只有 :push 进程的 Binder 断开会触发 AMS 的死亡回调 → AMS 完全不关心 :recovery 的死活。

2、AMS 按规则重启 :push 进程：

流程和场景 2完全一致：Binder 回调触发 → AMS 决策 → zygote64 fork() 生成新 :push 进程。

3、新 :push 进程主动重建 :recovery：

新 :push 进程初始化时，执行微信内置的代码逻辑 → 向 AMS 发送启动 :recovery 的请求 → AMS 允许后，zygote64 生成新的 :recovery 进程。

4、恢复完整保活状态：

新 :push 和 :recovery 重建双向互监，回到 wchan=ep_poll 休眠态，完成重启。

5、后续有通知：

和场景1一样。