冻它说明
更新于 2024-03-10

前言

冻它 是一款运行于安卓(Android)平台的基于Magisk和Xposed框架实现了部分墓碑机制的模块，可以有效阻止各类不安分应用在后台运行(即暂停其使用CPU资源)，在后台应用留存较多的情况下，可节省设备部分电量，省下更多运算资源以提升前台应用的体验。

由于安卓平台的“真后台”机制，应用在切换到后台之后，仍可保持运行状态，会继续网络通信、占用CPU运算资源等等耗能操作。即使近年来随着安卓系统的完善，应用的后台权限持续收紧，但国内应用总有各种办法绕过。受限于“真后台”的历史遗留问题，也无法一下子完全限制应用的后台运行权限。冻它为了实现完全冻结应用后台这套墓碑机制，在系统框架的各个组件上打了诸多补丁来解决强制冻结所带来的不良后果，但无法完全解决所有，所以强行使用冻它会导致部分应用运行异常，如果你的使用习惯能避开或可忽略这些问题，冻它就很适合你的设备。如果这些异常比较影响手机的正常使用，那冻它就非常不适合使用，不建议硬上。

如果你经常主动清理后台，或者系统杀后台行为很积极，则这类后台应用较少的情况下，冻它的效果将微乎其微，那么冻它可能不适合你。

配置选项说明

每个应用可配置以下几个选项：

  1. 杀死后台：该应用进入后台超时后将被直接杀死，而不是冻结。该选项适合那些用完就丢、不用留后台的应用，冻它自动帮你杀掉。

  2. SIGSTOP冻结：使用SIGSTOP信号进行冻结，冻结效果很好，但冻结状态的进程有概率异常终结，其他应用也有权限发送SIGCONT信号进行解冻。

  3. SIGSTOP断网：同上，但冻结后会额外进行应用断网(某些应用断网后才会使用第三方消息推送)。

  4. Freezer冻结：使用cgroup的Freezer子系统进行冻结，FreezerV2的冻结效果比较好，而FreezerV1小概率会冻结延迟或冻结失败，内核版本较旧的FreezerV1还会存在“类内存泄漏”现象，即应用被冻结后，即使出现任何异常都无法被终结，无法释放内存占用，需主动打开应用进行解冻或等待定时解冻才能回收内存等资源。极端情况下，冻结的应用过多导致设备内存不足时，系统也无法通过杀后台来释放内存，导致设备死机或重启。较新版FreezerV1不存在泄漏问题。具体的Freezer版本由内核版本决定。

  5. Freezer断网：同上，但冻结后会额外进行应用断网(某些应用断网后才会使用第三方消息推送)。

  6. 后台自由：即白名单，该应用可在前、后台自由运行，任何情况下都不会被冻结。

注：配置列表底部，不可更改配置的应用，已内置为 后台自由，大多都是经过各种验证，一旦冻结就会出现严重影响的应用。同时，某些可配置冻结的应用，一旦冻结也可能影响系统，特别是系统应用，需谨慎选择。

冻结控制器说明

  1. Freezer 是 cgroup 的其中一个子控制器，用于冻结进程的CPU使用权。开机时，冻它日志顶部有说明本机当前支持的V1或V2版本。

  2. FreezerV1 很早便在内核中支持，3.x/4.x/5.x内核都会支持。部分内核的FreezerV1存在缺陷，进程处于冻结状态时无法被杀死，依旧占据内存，类似内存泄漏，需要解冻才能结束进程并释放内存。这是内核级缺陷，应用层大概率无法解决，只能积极解冻来缓解，因此冻它会在 打开应用(解冻) 和 定时解冻 时解冻这些异常的进程并释放其内存。

    • 注：某些手机厂商基于V1的墓碑机制(例如FreezerV1版Millet)会捕获 杀进程信号 及时解冻，这样会及时释放进程的内存。(充电时或者各类按键事件时，Millet也会积极解冻应用)

  3. FreezerV2 在 5.4 内核(Android11)起支持，冻结效果好，且没有V1的类似内存泄漏问题，高通平台一般在4.19内核就获得支持，但部分厂商的手机可能默认不会开启，需要使用额外模块手动开启。谷歌Pixel某些机型甚至在4.14内核中也有实现。

  4. SIGSTOP 是Linux中编号19的系统信号，不能被进程捕获，一旦进程收到该信号则被立即强制暂停运行。

  5. FreezerV2(frozen) 和 FreezerV2(uid) 操作路径不同，但FreezerV2在初始化uid下的pid路径时会有延迟，因此刚打开的应用不能马上被冻结，继而冻结失败，因此推荐使用FreezerV2(frozen)。

    • FreezerV2(frozen)操作路径: /sys/fs/cgroup/[frozen/unfrozen]

    • FreezerV2(uid)操作路径: /sys/fs/cgroup/uid_10xxx/pid_xxx

    • FreezerV1(frozen)操作路径: /dev/jark_freezer/[frozen/unfrozen]

  6. 安卓平台正统的墓碑机制 “暂停执行已缓存的应用” 会使用FreezerV2和BinderFreeze来冻结应用，前者用于暂停应用使用CPU资源，后者用于阻断应用和其他应用进行Binder通信，只有两者同时工作才算完整的冻结体验。但是BinderFreeze需要Binder驱动支持 BINDER_FREEZE 特性，然而内核 5.10 版本以上才支持该特性，虽然最新主线 5.4 版本 内核源码 也支持了，但目前市面上的5.4内核小版本号仍比较旧，尚不支持该项特性。

  7. Binder驱动 是系统里负责应用之间通信，传递通信数据的驱动，位于 /dev/binder。如果应用只是冻结的运行，而没有冻结其binder通信接口，那么在其冻结状态下，如果遇到其他应用发来的通信请求，就无法及时回复，超时不回复将被安卓框架层认为应用运行异常而杀死。而后应用解冻时，大概率将发生瞬间闪退，重启，重载等等情况。

    • 注：MIUI的 FreezerV1版Millet 通过给旧版内核binder驱动打补丁，获得应用的binder通信事件，一旦有通信事件发生就触发运行解冻，避免了超时不响应。这些通信事件包括开始充电，按下实体按键等等，都会触发应用解冻。

模块说明

  1. 冻它的前台识别有 两种前台级别，不符合前台条件则一律视为在后台，会被冻结：

    1. 严格前台：当应用有顶层显示的窗口，含常规窗口、全屏、分屏、MIUI小窗，原生小窗(FreeForm)，virtualDisplay(ProcessStateNumber: 2 ~ 3)则判定为前台状态，不会被冻结。也是旧版冻它(v2.2.18及以下)的前台判断条件。

    2. 宽松前台：包含 严格前台 判断条件，或存在 悬浮窗、常驻通知栏、音频播放服务 等用户可以感知的服务时(ProcessStateNumber : 2 ~ 6)，均判定为前台状态，不会被冻结。

  2. 请不要与其他功能类似的 墓碑模块 一同使用，避免冲突，暂时与系统自带的 暂停执行已缓存的应用 无冲突。

  3. 底层进程与App通信采用TCP_SOCKET(本地环回 127.0.0.1:60613 ，模块为Server，APP为Client)，因此冻它APP需要网络通信权限，通信范围仅限本机内部，若有疑虑可查看 APP源码。

  4. 部分系统辅助类应用以第三方应用形式存在(可以像普通应用那样卸载掉)，被冻结后会导致系统异常，请手动设为自由后台，若发现此类应用(一般是天气、录音之类的应用)，请及时反馈给作者加入内置自由后台，给其他人避坑。

  5. 在MIUI13/14中，为防止机制冲突，冻它会禁用系统自带的墓碑机制 Millet 。

  6. 模块的文件大多位于模块自身目录内，但异常日志除外，运行时发生的异常日志会追加到: /sdcard/Android/freezeit_crash_log.txt ，若存在该文件，请向作者反馈其内容。若运行一切正常，则不会出现该文件。卸载模块时，该文件会一同被删除，同时也会自动卸载冻它APP, 不会留下其他额外垃圾文件。

  7. 如果使用冻它过程开启了Doze功能，系统的 电池优化白名单 会被替换成冻它的 自由后台(包括内置)应用 ，也就是说，自由后台 应用会设为 电池不优化，而 Freezer冻结、SIGSTOP冻结和杀死后台 的应用设为 电池优化，卸载冻它不会主动还原这些改动，用户有需要可以自行重新设置。(冻它3.0起，黑名单应用只会移出“电池不优化”，但“自由后台”不会再加入“电池不优化”)

冻它Xposed说明：系统框架

专门解决安卓使用墓碑机制的各类副作用：

  1. 广播(Broadcast) ：冻它会主动拦截发往冻结状态应用的广播，避免其冻结状态无法接收处理而堵塞广播系统。否则一旦发生堵塞，系统无法处理其他应用的广播，而依靠广播通信的拨号、安装应用等等行为会出现异常，将导致卡拨号，卡安装应用等现象。

  2. 应用无响应(ANR) ：冻它会屏蔽“应用无响应”弹窗，并阻止因ANR异常而杀后台。应用在冻结状态，如果超时没有响应系统某些服务或状态问询时，系统会弹窗提示 XXX应用未响应 询问等待还是关闭应用，如果无法响应的是重要且限时应答的系统服务，此时应用会被系统认为严重异常而杀死，同时在 /data/anr/ 下输出异常日志。

  3. 唤醒锁(WakeupLock) ：冻它只允许自由后台应用获得唤醒锁。一旦有应用获得唤醒锁而没有释放，系统即使息屏待机状态也不会进入Doze休眠，CPU会一直保持运转，影响待机续航。因此冻它禁止 设为冻结的应用 获得唤醒锁，防止其冻结状态无法主动释放唤醒锁。

  4. 定时器(Alarm) ：冻它只允许自由后台应用设置定时器。应用一旦设置了定时器，到了其设定的条件会被系统唤醒运行，这种后台唤醒操作及其唤醒后的运行都是在后台默默运行，会产生不必要耗电。

  5. 即使有了以上补丁，冻它也无法完全解决系统框架和冻结状态的应用之间交互而产生异常，会导致部分应用在冻结期间无法完全应对来自系统框架的各种交互，例如无法处理来自系统或其他应用的Intent请求等等，也会使应用长时间冻结后丢失对某些系统资源的持有，例如网络连接等等，这样应用在解冻后会出现各种异常行为，虽说积极的解冻会大大缓解各种异常现象，但这也失去了“冻结”的意义，不如不冻。

冻它Xposed说明：电量与性能

  1. 只在MIUI13/14中存在，用于禁用其杀后台的功能，如果不需要，可以不勾选。

注意项

  1. 冻它面具模块 是墓碑机制的核心，而 冻它XPosed模块 负责解决安卓系统使用墓碑机制的副作用，缺一不可，必需勾选 系统框架 ，MIUI可选择是否勾选 电量与性能 ，主要用于禁用其杀后台功能。

  2. 如果 面具Magisk 管理器进行了隐藏操作，使用了随机包名、名称，冻它可能会拦截其广播而导致 启动时卡住 ，请手动设为自由后台。原生包名及Delta版包名已内置自由后台。

  3. 如遇其他问题，请加入 QQ频道 冻它模块 进行讨论。

其他

  1. 教程：冻结QQ并使用HMSPush消息推送

    目前QQ已经接入了MiPush和HMSPush，以下介绍安装HMSPush步骤：

    1. 在酷安或任意应用市场下载安装 HMS Core。

    2. 在 LSPosed仓库 中搜索安装 HMSPush ，勾选 系统框架、系统界面、HMS Core、QQ、和其他支持HMS推送的应用 。

    3. 重启系统，打开 QQ ，再打开 HMSPush 检查其是否已经注册，若已注册，说明可以使用推送了，否则就再重启系统，重复以上操作。

    4. 把QQ设为 Freezer断网 或者 SIGSTOP断网，此时可以去冻结或杀死 QQ，测试是否可以接收信息推送，该推送弹窗图标是QQ的图标。如果图标是对方/群头像，则说明该弹窗是QQ自己弹的，不是HMSPush或第三方推送平台的。

      P1

  2. 检查冻结状态

    冻它进行冻结操作后，如果是FreezerV1模式，冻结可能会延迟甚至无法冻结，此时可以换成SIGSTOP，其冻结方式较为彻底。

    1. 点击冻它APP日志页的 雪花按钮，日志会列出当前进程状态，可以检查是否被冻结。

      P1

    2. 如果是其他墓碑，请使用 Termux终端 (官网 / V0.118下载)，或者使用MT管理器里面的“终端模拟器”，选择以下其中一个命令执行，原理是读取各进程的wchan状态值进行判断：

    3. 以下命令只显示当前 已冻结状态 的进程信息，但是 没有被冻结 的不会显示，先执行 su，再执行以下命令，执行后列出的进程基本处于冻结状态：

       ps -A | grep -E "refrigerator|do_freezer|signal|freezable_schedule"

      P1

    4. 以下命令会显示所有安卓应用进程的状态信息，无论是否冻结状态，先执行 su，再执行以下命令：

       ps -A | grep u0_a

      P1

      • FreezerV1冻结状态: __refrigerator

      • FreezerV2冻结状态: do_freezer_trap

      • SIGSTOP冻结状态：do_signal_stop

      • 大概率是FreezerV2：get_signal

      • 貌似5.15/6.1或以上内核出现的新的冻结状态： freezable_schedule

      • 特别说明：这种冻结状态识别方式依赖于进程的wchan状态，也就是进程当前处于的哪些系统调用状态，虽然冻结时大概率都处于以上几种状态，但也可能例外，甚至非冻结状态也可能出现这些wchan状态。因为不同内核编译环境的优化级别不同，导致内核函数内联优化程度不一样，所以冻结状态的进程所停留的系统调用层级名称不是绝对的，但以上几种wchan状态应该符合目前大多数冻结情况。

      • 其他wchan状态则没有被冻结，处于正常运行中。

相关链接

文章日期：2022-11-15