NoActive 内存优化 - 可用内存不足时自动清理低优先级应用
内存优化功能概述
内存优化功能在应用页面切换时检测内存使用率。当可用内存低于保留值时，自动从低优先级应用中按后台时长从远到近清理进程，直到内存恢复到保留值以上。
前置条件
内存优化必须先启用后台优化功能（MasterConfig.json 的 backgroundOptimize 设为 true）。后台优化是内存优化的基础。
保留内存配置
默认值
NoActive 默认保留物理内存的 10%（最大值 2GB）作为保留值。超过保留值的部分才会被清理。
自定义配置
在 MemConfig.json 中可以自定义：
| 配置项 | 说明 |
|---|---|
freeRAM | 保留 RAM：负整数（关闭）、0（自动）、正整数（指定 MB） |
freeSWAP | 保留 SWAP：负整数（关闭）、0（自动）、正整数（指定 MB） |
配置示例
{
"freeRAM": 2048,
"freeSWAP": 512
}表示保留 2GB RAM 和 512MB SWAP。
清理策略
触发时机
每次应用页面切换时检测一次。不是持续监控，避免额外 CPU 开销。
清理逻辑
- 检测当前可用内存
- 如果低于保留值 → 开始清理
- 从低优先级应用中，按后台时长排序（最久没切回的先清理）
- 清理该应用的进程
- 检查内存是否恢复到保留值以上
- 未恢复 → 继续清理下一个
- 恢复 → 停止清理
优先级顺序
清理的优先级完全基于 MasterConfig 和 MemConfig 中设置的高/中/低优先级，后台优化分组中有详细说明。
注意事项
不是立即回收
内存优化是"尽量回收"机制，不保证一次触发就能清理到目标值。如果所有低优先级应用已经被清理，内存仍不足，则不再继续。
内存不足时的体验
内存优化可以减少系统因内存不足导致的强制杀死进程（LMK 触发），但它无法完全阻止 LMK。当物理内存真的满了，系统必须杀死进程。
高优先级保护
高优先级应用永远不会被内存优化清理。但这不代表高优先级应用一定不会被 LMK 杀死——如果真的内存耗尽，即使是高优先级也可能被杀死。
与冻结的配合
内存优化清理进程与冻结是独立的两个机制：
- 冻结：进程暂停执行，但仍占用内存
- 内存优化：释放内存（进程可被清理）
如果某个低优先级应用被冻结但内存优化仍认为内存不足，可能会杀死被冻结的进程。这种情况下下次打开应用需要重新加载。
开启方法
MasterConfig.json 中将 memoryOptimize 设为 true，重启生效。确保 backgroundOptimize 已开启。
→ 继续 深度睡眠 Doze 配置