---

前言

最近在使用 NoActive Pro 的墓碑机制优化 Android 后台耗电时，遇到了一个比较奇怪的问题。

微信后台明明已经被冻结，但是收到新消息后，FCM 可以正常唤醒微信，微信进程也重新启动了，却没有收到通知。只有手动打开微信后，消息才会同步出来。

通过 FCM Diagnostics、NoActive运行状态以及白名单对比测试，最终定位问题并非 FCM 链路异常，而是微信被唤醒后的运行生命周期不足。

为了找到真正原因，这次直接从 FCM Diagnostics 开始，一步一步进行排查。

本文所有测试均基于 NoActive Pro 实际测试环境。其他 Android 墓碑、冻结类软件可能存在类似问题，但本文没有对其他软件进行实际验证。

关于国行手机、国行微信、FCM 和 Google Play 服务

这里需要说明几个容易误解的问题。

早期的国行版微信并没有接入 FCM，因此无法使用FCM通知。
随着微信版本更新，目前较新的国行版微信已经加入 FCM 通知能力。

目前部分国行 Android 手机已经内置 Google Play 服务相关组件，只是默认关闭。作者已知可以比较方便开启 Google 服务的品牌：
一加、小米、红米系列、OPPO、真我。
不同品牌开启方式不同，具体方法可以根据机型自行搜索。开启后，需要确认：
Google Play 服务正常运行。

另外一个容易误解的问题：很多人认为国内网络无法连接 Google FCM。实际测试发现：
FCM 在国内网络环境下可以正常建立连接。

在测试FCM连通性过程中可以通过关闭WIFI和开关飞行模来切换网络状态。

---

一、先确认 FCM 到底是不是正常

排查后台推送问题，第一步不是修改 NoActive，而是先确认 FCM 本身正常。

Android 可以通过拨号器输入：

*#*#426#*#*

进入：

FCM Diagnostics

FCM Diagnostics 主界面

进入以后，首先看 Time Connected。

正常情况下，Time Connected 会显示一个持续增加的连接时间，例如：

Time Connected
00:xx:xx

只要这个时间持续增加，就说明 Google Play 服务与 FCM 的连接处于正常状态。

简单理解：

Google Play服务 → FCM服务器 → 持续保持连接

这一步如果正常，才能继续往下排查微信。

---

二、FCM Diagnostics 中常见的两种异常状态

在实际排查过程中，除了正常连接状态，还可能遇到 ERR_IO_FIN 和 ERR_NET_DOWN。

这两个错误看起来很像，但排查方向并不一样。

1. ERR_IO_FIN

如果显示：

ERR_IO_FIN

可以理解为 FCM 的网络连接在通信过程中异常结束。

一般应该优先检查：

1. VPN 或代理节点；
2. 防火墙或网络设备；
3. DNS 和网络分流；
4. Google FCM 的连接是否被中途关闭；
5. Google Play 服务的网络访问是否受到限制。

简单理解：

本地网络正常 → GMS连接FCM → 通信过程中连接被终止 → ERR_IO_FIN

---

2. ERR_NET_DOWN

如果显示：

ERR_NET_DOWN

则说明 Android 网络层当前向 Google Play 服务报告网络不可用。

它与 ERR_IO_FIN 最大的区别，可以简单理解为：

ERR_NET_DOWN：本地没有可用的网络路径
ERR_IO_FIN：网络存在，但 FCM 连接在通信过程中终止

遇到 ERR_NET_DOWN 时，应优先检查：

1. Wi-Fi 或移动数据；
2. Android 是否正确获得 IP 和默认路由；
3. VPN、代理或防火墙；
4. Google Play 服务是否被限制网络访问；
5. 系统是否错误判断当前网络不可用。

因此：

ERR_NET_DOWN → 先检查本地网络
ERR_IO_FIN → 重点检查FCM通信链路

只有恢复到：

Time Connected持续增加

之后，才有必要继续测试微信。

---

三、确认微信是否注册 FCM

确认 FCM 连接正常后，再检查微信。

进入：

FCM Diagnostics → Events

在顶部搜索框输入：

com.tencent.mm

这是微信 Android 客户端包名。

如果能够找到 com.tencent.mm 相关事件，就说明 FCM Diagnostics 中已经存在微信相关记录。

这一步至少可以帮助确认：

1. 微信已经接入 FCM；
2. FCM 服务能够识别微信这个应用；
3. 微信具备接收 FCM 唤醒的条件。

也就是说，在后面的测试中，如果微信能够被成功唤醒，就没有必要继续纠结“微信是不是根本没注册 FCM”。

---

四、开始模拟微信被冻结后的状态

确认 FCM 和微信状态都正常后，就可以开始测试 NoActive。

首先进入：

设置 → 应用 → 微信 → 强制停止

强制停止的目的很简单：

让微信进程完全退出，模拟它已经被后台墓碑机制处理后的状态。

---

五、确认微信已经退出 NoActive 运行列表

强制停止后，再回到 NoActive 运行列表查看微信。

此时微信已经停止运行，并从运行列表中消失。

接下来保持这个状态，用另一台手机向本机微信发送一条消息。

---

六、NoActive 默认状态下测试 FCM 唤醒

测试条件很简单：

1. 微信未加入 NoActive 白名单；
2. 微信已经被强制停止；
3. 使用另一台手机给本机微信发送消息。

大约 3 秒左右，可以在 NoActive 运行列表重新看到微信。

也就是说：

另一台手机发送消息 → FCM → Google Play服务 → 唤醒微信

这一步非常关键。

因为微信已经从运行列表消失，但收到消息后又重新出现，说明 FCM 唤醒链路确实跑通了。

---

微信刚被唤醒时

微信刚被唤醒时，内存占用大约在：

300MB+

说明进程已经真正启动，并开始恢复运行。

随后继续观察。

---

微信继续恢复运行

经过大约 5 秒，微信内存继续快速增长。

在未加入白名单的情况下，内存最终增长到 900MB 左右，之后基本停止增长。

此时出现一个非常关键的现象：

1. 微信进程已经启动；
2. 内存已经明显增长；
3. 但是没有收到通知；
4. 随后 NoActive 又将微信冻结。

这时候基本可以把问题范围缩小到：

微信已经被 FCM 唤醒，但后台同步还没有完成，NoActive 就重新介入冻结了微信。

---

七、白名单对比测试

为了确认是不是 NoActive 的冻结策略导致的，接下来进行一个非常简单的对照实验：

把微信加入 NoActive 白名单。

然后：

1. 再次强制停止微信；
2. 确认微信已经退出运行；
3. 再使用另一台手机发送微信消息。

结果非常明显。

微信依然会在大约 3 秒左右被 FCM 唤醒。

但这一次，因为已经加入白名单，NoActive 不会马上重新冻结微信。

---

八、白名单状态下微信最终可以收到通知

这次测试中：

1. 微信在几秒内快速恢复；
2. 内存增长到 900MB 以上；
3. 微信保持运行；
4. 最终正常收到消息通知。

这个结果基本把问题定位清楚了。

两组测试形成了非常明显的对照：

测试状态	FCM 唤醒	微信运行	收到通知
NoActive 默认状态	正常	正常启动后再次冻结	否
微信加入白名单	正常	持续运行	是

所以：

FCM连接正常 → 微信注册FCM → FCM成功唤醒微信 → NoActive冻结策略介入 → 微信同步未完成 → 无通知

而加入白名单后：

FCM唤醒 → 微信持续运行 → 完成消息同步 → 生成通知

---

九、问题真正出在哪里？

到这里其实已经可以把前面几个怀疑全部排除。

不是：

1. 微信没有注册 FCM；
2. Google Play 服务没有运行；
3. FCM 无法连接；
4. FCM 无法唤醒微信。

真正的问题是：

微信已经被 FCM 成功唤醒，但 NoActive 在微信完成后台消息同步之前，又将微信冻结了。

微信后台收到消息的过程本身是连续的：

微信服务器 → Google FCM → Google Play服务 → 唤醒微信 → 微信恢复运行 → 连接微信服务器 → 同步消息 → 生成通知

NoActive 介入后变成：

微信服务器 → Google FCM → Google Play服务 → 唤醒微信 → 微信恢复运行 → NoActive重新冻结 → 同步未完成 → 无通知

所以：

FCM 唤醒成功，并不等于微信通知已经生成。

FCM 负责把微信叫醒，后面的网络连接、消息同步和通知生成仍然需要微信继续运行。

---

十、解决方案：不要急着把微信长期加入白名单

最直接的解决方式当然是把微信加入 NoActive 白名单。

但是这样做有一个明显缺点：

微信长期后台运行 → 功耗增加

这与使用 NoActive 墓碑机制省电的目的有些冲突。

更理想的方式是：

让 NoActive 正确识别 FCM 唤醒事件，只在需要的时候给微信足够的运行窗口。

理想流程应该是：

FCM唤醒微信 → NoActive识别FCM事件 → 给予运行窗口 → 微信同步消息 → 生成通知 → 再次进入墓碑状态

这样既可以保留墓碑机制，又不需要让微信长期驻留后台。

---

十一、NoActive FCM 配置优化

在 Root 环境下，可以使用 MT 管理器等文件管理工具修改 NoActive 高级配置。

配置文件路径：

/data/system/NoActive_[随机字符]/config/AdvanceConfig.json

部分版本可能没有随机字符，实际路径以设备上的 NoActive 数据目录为准。

配置示例：

{
  "adaptiveIcon": false,
  "fcmAppSet": [],
  "receiveFCM": true
}

重点是：

"receiveFCM": true

配置界面

配置后，需要按照实际版本重启 NoActive 或重启设备，使配置重新加载。

---

十二、为什么这种方式比长期白名单更合适？

两种方案进行比较：

方案	后台状态	推送	功耗
微信加入白名单	长期保持运行	正常	相对较高
FCM 调度放行	需要时唤醒	正常	相对较低

理想状态是：

收到消息 → FCM唤醒 → 微信完成同步 → 生成通知 → 再次进入墓碑状态

而不是：

微信长期运行 → 持续保持后台 → 等待消息

这更符合 NoActive 墓碑机制本身的设计目标。

---

十三、这套测试方法是否适用于其他墓碑软件？

本文实际测试的只有：

NoActive Pro。

所以本文对于 NoActive 的结论可以直接通过前面的实测过程得到。

至于其他 Android 墓碑、冻结类方案，例如：

1. Root 类后台冻结工具；
2. Shizuku 类应用管理工具；
3. LSPosed 相关后台控制模块。

由于它们具体的冻结方式、调度策略和唤醒机制可能不同，不能直接套用本文结论。

不过，这次测试形成的排查思路具有一定通用性：

FCM Diagnostics检查 → Events搜索应用包名 → 冻结状态测试 → 白名单对比测试 → 判断是否为冻结策略影响

也就是说，先证明 FCM 没有问题，再通过冻结与白名单进行 A/B 对比，比单纯猜测“到底是不是 FCM 的锅”更容易定位问题。

---

十四、最终结论

这次排查最终得到的结果非常明确：

FCM连接正常 → 微信注册FCM → FCM成功唤醒微信 → NoActive冻结策略介入 → 微信同步未完成 → 无通知

而加入白名单后：

FCM连接正常 → 微信注册FCM → FCM成功唤醒微信 → 微信保持运行 → 消息同步完成 → 正常通知

所以这次问题的核心并不是：

微信没有注册 FCM。

也不是：

Google Play 服务没有正常工作。

真正的问题是：

NoActive 在微信被 FCM 唤醒后，过早重新冻结了微信进程，导致微信没有完成后台消息同步。

相比让微信长期加入白名单，更合理的解决方向是调整 NoActive 的 FCM 调度策略，让微信在收到 FCM 唤醒后获得足够的运行生命周期，完成消息同步后再重新进入墓碑状态。

这也是这次实测最重要的结论。