NoActive 网络解冻 - 冻结消息 App 正常接收消息的方案
问题背景
当消息类应用被冻结后，进程暂停执行，网络连接可能被系统回收。这导致即使有新消息到达，应用也无法接收，直到被手动解冻。
网络解冻方案
NoActive 提供了网络解冻功能，专为需要在冻结状态下正常接收消息的应用设计。
工作原理
网络解冻的核心思路是：在保持应用进程冻结的同时，为其保留必要的网络连接能力。当有新消息到达时，短暂解冻应用以处理消息，处理完成后重新冻结。
这需要内核模块（ReKernel 系列配合）的底层支持，才能实现"进程暂停但网络活跃"的状态。
适合的应用
网络解冻主要服务于以下消息类应用：
- 即时通讯：微信、Telegram、Signal 等（但这类更推荐白名单）
- 邮件客户端：Gmail、Outlook 等
- 推送通知聚合：通过 FCM 接收通知的应用
- 企业通讯：Slack、飞书、钉钉等
网络质量与消息延迟
网络不稳定的情况
网络质量低时（信号弱、网络切换、Wi-Fi 不稳定），网络解冻的连接会出现不稳定，消息接收会有明显延迟。
权衡说明
开启网络解冻后，应用在冻结状态下会维持网络连接，这会带来一定的额外耗电。相比白名单（应用始终活跃），网络解冻的耗电更低，但消息接收时效性稍差。
与其他消息接收方案的对比
| 方案 | 消息时效性 | 耗电 | 适用条件 |
|---|---|---|---|
| 白名单 | 即时 | 较高 | 核心应用 |
| 网络解冻 | 准即时（秒级延迟） | 较低 | 有内核模块支持 |
| FCM 推送解冻 | 依赖 Google 服务 | 最低 | 开启 FCM 配置 |
| 不做任何配置 | 差（冻结期间丢失） | 最低 | 非核心应用 |
配合 FCM 使用
NoActive 还支持 FCM 全局解冻和单独配置 FCM 解冻应用。FCM（Firebase Cloud Messaging）是 Google 的推送服务，可在应用进程冻结时通过系统级通道推送消息。
但由于 FCM 的设计原理，NoActive 不保证 FCM 推送的到达率。如果你依赖 FCM 接收重要消息，建议配合其他方案使用。
配置方法
在应用的独立配置页面开启网络解冻开关。如果需要批量配置或 FCM 全局解冻，需要通过配置文件 AdvanceConfig.json 中的 receiveFCM 和 fcmAppSet 字段设置。
内核模块要求
网络解冻功能需要 ReKernel 系列内核模块支持。NkBinder 不支持网络解冻，使用 NkBinder 的设备无法使用此功能。
→ 继续 允许自启配置