墓碑机制与后台冻结原理

本篇讲清安卓后台冻结（俗称「墓碑机制」）到底是怎么回事：冻结和杀后台差在哪、CPU 为什么会归零、为什么冻结比查杀更适合当日常省电手段。理解了原理，冻结规则与豁免搭配 里的每个开关就好懂了。相关文档：冻结规则与豁免搭配.md · 装完不生效排查思路.md

一、后台应用的两种归宿：被杀，或被冻住

安卓对后台应用的传统处理方式是查杀：内存吃紧时按优先级结束进程。被杀的应用状态全丢，回前台要重新走一遍启动流程，最近任务里的卡片也可能消失。

冻结是另一种思路：进程还在内存里，只是被挂起——不再参与 CPU 调度、不跑任何代码，但内存里的状态原封不动。点开图标时解除挂起，应用从离开时的那一帧继续，几乎无感恢复。这个做法在 Linux 内核层面有现成的支撑，就是 Cgroup Freezer，社区把这套玩法形象地叫「墓碑机制」——应用还「躺」在后台，只是不再活动。

二、冻结态下发生了什么

一个应用被冻结后：

• CPU 占用归零：进程不再被调度，用第三方工具观察会看到占用从百分之几直接掉到 0%。有玩家总结的判据是——应用退后台约 3 秒后占用归零，就是冻住了；一直挂着 2–4% 说明没冻住。
• 网络与唤醒不再打扰：挂起的进程收不到调度，自然也不会在后台跑流量、抢唤醒锁。
• 内存并不释放：这是和查杀最大的区别。冻结靠的是牺牲一部分内存换「回到前台不用重载」，所以内存特别紧张的机器上，冻结机制还要和系统的内存回收协同工作。

三、为什么冻结更适合日常省电

后台耗电的大头是「还在干活」的进程：轮询、定位、心跳、后台计算。查杀能停掉它们，但代价是状态丢失、回前台重载，用户感知很差，而且很多应用马上会把自己拉起来，杀与复活来回拉锯。

冻结把「干活」这件事直接停了，又不破坏状态，应用也不会因为被杀而疯狂自启。对常驻后台的应用（社交、音乐、网盘同步类），冻结既压住了 CPU 与网络活动，又保住了「切回去就能接着用」的体验。配合「定时解冻」这类机制，还能让冻结的应用周期性活动一下，避免长期挂起带来的边缘问题。

四、想在手机上体验这套机制需要什么

原生系统里普通用户碰不到 Cgroup Freezer 的开关，这类能力要通过模块化的方式接入系统框架。以 NoActive 这类后台冻结模块为例，它工作在 Xposed 框架之上，因此需要已 Root 的设备、LSPosed 框架与 Android 12 及以上的系统；应用退后台约 3 秒自动冻结、回前台快速解冻，并按应用的运行状态自动豁免（通话、定位、录音、播放中的不冻）。

它的功能总览、四种冻结方式（V2 / API / V1 / KILL）的选择和完整安装步骤，整理在 NoActive 介绍站，这里不重复展开。

五、一句话总结

墓碑机制的本质是「挂起而非杀死」：省的是后台白干的活，保的是切回前台的那份连续体验。理解了这一点，冻结方式怎么选、每个应用的白名单怎么配，都成了围绕这个核心的参数调优而已。