NoActive 不支持白名单进程和单独杀进程的设计说明
问题背景
有些用户可能希望：
- 应用的主进程被冻结，但 Service 进程保持活跃
- 应用被冻结时，彻底杀死进程而不是暂停执行
NoActive 不支持这些需求，这是设计决策而非功能缺失。
为什么整体冻结应用
子进程与 Binder 通信
如果只冻结主进程而不冻结子进程：
- 已冻结的主进程可能需要与子进程进行 Binder 通信
- 子进程正常运行，但主进程已暂停
- Binder 调用无法得到响应
- 应用内部状态混乱，导致未知问题
整体冻结的好处
- 所有进程同步冻结，状态一致
- 不会产生跨进程的通信阻塞
- 设计简单，行为可预测
为什么不支持杀死进程
Kill vs Freeze 的资源开销
| 操作 | 资源开销 | 应用体验 |
|---|---|---|
| 冻结（暂停） | 极低，进程保留在内存 | 切回后秒开，无需重新加载 |
| 杀死进程 | 较高，内存释放但状态丢失 | 切回后需要重新启动、加载数据 |
反复杀死进程的问题
应用每次后台就杀死进程，下次打开时：
- 需要重新加载全部代码和资源
- 需要重新建立网络连接
- 需要重新获取用户数据
- 系统需要为分配 CPU 时间片和内存页面做大量工作
总开销远大于让进程保持冻结状态。
用户体验
杀死进程的应用再次打开时会有明显的冷启动延迟，体验远不如冻结状态的秒开。
NoActive 的选择
NoActive 选择整体冻结应用的原因：
- 行为一致性：整体冻结避免了跨进程通信问题
- 资源效率：冻结比杀死进程更省资源
- 用户体验：冻结状态下应用秒开
- 设计简洁：减少配置复杂度，降低出错概率
替代方案
如果你确实需要某些应用在后台被彻底清理，而不是冻结：
方案一：使用其他工具
黑阈等工具提供了强停功能，可以配合 NoActive 使用。
方案二：开启内存优化
NoActive 的内存优化可以在内存紧张时自动清理低优先级应用的进程。这比手动或频繁杀死更合理——只在内存真的不够时才释放。
方案三：接受冻结方案
大部分情况下，冻结比杀死进程的综合体验更好。建议多使用几天，习惯后通常不会想换回杀进程方案。
关于白名单进程
同理，白名单特定进程（让某些进程不被冻结）也会导致跨进程状态不一致问题。NoActive 不支持这种粒度的配置。
维护周期
NoActive 团队默认维护最新的 3 个 Android 正式版，最佳适配当前主流 Android 版本。系统版本过旧时可能无法获得完整支持。
→ 全部步骤完成，回到 首页 或运行构建命令验证