换新手机后，开发者选项中新增了「暂停执行已缓存的应用」功能，默认处于开启状态。官方说明指出，该功能旨在通过暂停后台进程来降低待机功耗。在实际使用一段时间后，待机续航确实有所延长，但同时也伴随着后台应用重载、MacroDroid 自动化脚本触发延迟或丢失等现象。为了验证这些现象的因果关系，我在自己的设备上进行了一次对比测试。
测试设备为 OPPO A3i 5G，系统 ColorOS 15，存储采用 128GB eMMC，内存组合为 6GB 物理内存加 2GB 虚拟内存扩展。这一配置在百元机中较为典型，eMMC 存储的随机读写性能相对较弱，且内存容量中等，这些硬件特性可能会对后台策略的实际表现产生影响。测试全程未涉及 ADB 命令或调试操作，仅通过系统设置界面与第三方监控工具进行记录，以还原普通用户的真实使用场景。
测试方法采用控制变量法，开启功能正常使用两三天，随后关闭功能再使用两三天。在此期间，通过 Battery Guru 记录功耗数据，利用爱玩机工具箱监控内存，并验证 MacroDroid 的任务触发情况。数据显示，开启功能时，熄屏放电速度约为 0.6%/时，深度睡眠时间较长；关闭功能后，放电速度回升至 1.3%/时左右。虽然省电效果客观存在，但从绝对数值来看，对日常整体续航的影响有限。
相比功耗数据，体验上的差异更为直观。开启功能期间，从后台切回浏览器或微信等应用时，偶尔会出现重新加载和页面刷新的情况；关闭功能后，应用状态保留完好，切换更为流畅。MacroDroid 的表现同样如此，开启功能时监听网络变化的任务偶有漏触发或响应迟钝，关闭后则触发稳定。此外，监控数据还显示，开启功能后扩展内存的占用明显上升，这表明系统在冻结进程的同时，很可能配合了内存交换机制，将部分数据转移到了虚拟内存中。
这种现象源于该功能的底层逻辑。系统并不会立即冻结所有后台应用，而是针对被判定为「已缓存」的低优先级应用。系统默认设有十分钟的观察期，若应用在此期间持续无活动，才会真正执行冻结。这套机制对于普通的缓存应用十分有效，但系统无法区分「真正闲置」与「等待事件」。像 MacroDroid 这类自动化软件，常态便是静默等待触发器，在系统看来符合冻结条件，一旦被冻结，监听器随之停止工作，导致任务丢失。同时，受限于 eMMC 存储较弱的随机读写性能，数据在物理内存与扩展内存间频繁交换，进一步加剧了后台切换时的卡顿。
低端的硬件配置在其中起到了放大作用。实测中扩展内存占用的上升，证实了数据交换行为的存在。由于测试设备采用的是 eMMC 存储，其随机读写性能较弱，加之 6GB 物理内存并不宽裕，系统倾向于将后台数据交换到扩展内存以腾出空间。当用户切回应用时，系统需要将数据从扩展内存换回物理内存，这一过程受限于 eMMC 的写入瓶颈，导致解冻时间延长，从而产生卡顿感。这解释了为何在开启功能后，后台切换会出现延迟，不仅仅是进程解冻本身耗时，数据换入的过程也被存储性能拖累。
综合来看，这个功能的设计初衷是在不影响用户体验的前提下，抠出一点待机功耗。根据相关技术文献 「暂停执行已缓存的应用」是如何工作的 的分析，该机制其实很难冻结那些频繁活动的“毒瘤应用”，因为系统不能破坏它们的功能，反倒是像 MacroDroid 这样守规矩、安静等待的后台进程，最容易被判定为可冻结对象。这种“杀良留毒”的特性，使得它在很多场景下显得有些鸡肋。对我个人而言，省的那点电量，换不来日常流畅和自动化的稳定，所以我选择关闭这个功能。日常后台管理可以手动做：常用应用在系统设置里允许后台活动，低频应用交给系统限制，再用监控工具定期排查异常耗电应用。不同机型与配置的表现可能存在差异，建议根据自身实测数据做出判断。
本文为我原创，未经授权禁止转载 | bilibili UID1319899187 | 掘金 ID1048290992076985
