Android NoActive 墓碑机制下微信 FCM 唤醒无通知问题排查与解决方案
前言
最近在使用 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 的网络连接在通信过程中异常结束。
一般应该优先检查：
VPN 或代理节点；
防火墙或网络设备；
DNS 和网络分流；
Google FCM 的连接是否被中途关闭；
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 时，应优先检查：
Wi-Fi 或移动数据；
Android 是否正确获得 IP 和默认路由；
VPN、代理或防火墙；
Google Play 服务是否被限制网络访问；
系统是否错误判断当前网络不可用。
因此：
ERR_NET_DOWN → 先检查本地网络
ERR_IO_FIN → 重点检查FCM通信链路
只有恢复到：
Time Connected持续增加
之后，才有必要继续测试微信。
三、确认微信是否注册 FCM
确认 FCM 连接正常后，再检查微信。
进入：
FCM Diagnostics → Events
在顶部搜索框输入：
com.tencent.mm
这是微信 Android 客户端包名。
如果能够找到 com.tencent.mm 相关事件，就说明 FCM Diagnostics 中已经存在微信相关记录。
这一步至少可以帮助确认：
微信已经接入 FCM；
FCM 服务能够识别微信这个应用；
微信具备接收 FCM 唤醒的条件。
也就是说，在后面的测试中，如果微信能够被成功唤醒，就没有必要继续纠结“微信是不是根本没注册 FCM”。
四、开始模拟微信被冻结后的状态
确认 FCM 和微信状态都正常后，就可以开始测试 NoActive。
首先进入：
设置 → 应用 → 微信 → 强制停止
强制停止的目的很简单：
让微信进程完全退出，模拟它已经被后台墓碑机制处理后的状态。
五、确认微信已经退出 NoActive 运行列表
强制停止后，再回到 NoActive 运行列表查看微信。
此时微信已经停止运行，并从运行列表中消失。
接下来保持这个状态，用另一台手机向本机微信发送一条消息。
六、NoActive 默认状态下测试 FCM 唤醒
测试条件很简单：
微信未加入 NoActive 白名单；
微信已经被强制停止；
使用另一台手机给本机微信发送消息。
大约 3 秒左右，可以在 NoActive 运行列表重新看到微信。
也就是说：
另一台手机发送消息 → FCM → Google Play服务 → 唤醒微信
这一步非常关键。
因为微信已经从运行列表消失，但收到消息后又重新出现，说明 FCM 唤醒链路确实跑通了。
微信刚被唤醒时
微信刚被唤醒时，内存占用大约在：
300MB+
说明进程已经真正启动，并开始恢复运行。
随后继续观察。
微信继续恢复运行
经过大约 5 秒，微信内存继续快速增长。
在未加入白名单的情况下，内存最终增长到 900MB 左右，之后基本停止增长。
此时出现一个非常关键的现象：
微信进程已经启动；
内存已经明显增长；
但是没有收到通知；
随后 NoActive 又将微信冻结。
这时候基本可以把问题范围缩小到：
微信已经被 FCM 唤醒，但后台同步还没有完成，NoActive 就重新介入冻结了微信。
七、白名单对比测试
为了确认是不是 NoActive 的冻结策略导致的，接下来进行一个非常简单的对照实验：
把微信加入 NoActive 白名单。
然后：
再次强制停止微信；
确认微信已经退出运行；
再使用另一台手机发送微信消息。
结果非常明显。
微信依然会在大约 3 秒左右被 FCM 唤醒。
但这一次，因为已经加入白名单，NoActive 不会马上重新冻结微信。
八、白名单状态下微信最终可以收到通知
这次测试中：
微信在几秒内快速恢复；
内存增长到 900MB 以上；
微信保持运行；
最终正常收到消息通知。
这个结果基本把问题定位清楚了。
两组测试形成了非常明显的对照：
所以：
FCM连接正常 → 微信注册FCM → FCM成功唤醒微信 → NoActive冻结策略介入 → 微信同步未完成 → 无通知
而加入白名单后：
FCM唤醒 → 微信持续运行 → 完成消息同步 → 生成通知
九、问题真正出在哪里？
到这里其实已经可以把前面几个怀疑全部排除。
不是：
微信没有注册 FCM；
Google Play 服务没有运行；
FCM 无法连接；
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唤醒 → 微信完成同步 → 生成通知 → 再次进入墓碑状态
而不是：
微信长期运行 → 持续保持后台 → 等待消息
这更符合 NoActive 墓碑机制本身的设计目标。
十三、这套测试方法是否适用于其他墓碑软件？
本文实际测试的只有：
NoActive Pro。
所以本文对于 NoActive 的结论可以直接通过前面的实测过程得到。
至于其他 Android 墓碑、冻结类方案，例如：
Root 类后台冻结工具；
Shizuku 类应用管理工具；
LSPosed 相关后台控制模块。
由于它们具体的冻结方式、调度策略和唤醒机制可能不同，不能直接套用本文结论。
不过，这次测试形成的排查思路具有一定通用性：
FCM Diagnostics检查 → Events搜索应用包名 → 冻结状态测试 → 白名单对比测试 → 判断是否为冻结策略影响
也就是说，先证明 FCM 没有问题，再通过冻结与白名单进行 A/B 对比，比单纯猜测“到底是不是 FCM 的锅”更容易定位问题。
十四、最终结论
这次排查最终得到的结果非常明确：
FCM连接正常 → 微信注册FCM → FCM成功唤醒微信 → NoActive冻结策略介入 → 微信同步未完成 → 无通知
而加入白名单后：
FCM连接正常 → 微信注册FCM → FCM成功唤醒微信 → 微信保持运行 → 消息同步完成 → 正常通知
所以这次问题的核心并不是：
微信没有注册 FCM。
也不是：
Google Play 服务没有正常工作。
真正的问题是：
NoActive 在微信被 FCM 唤醒后，过早重新冻结了微信进程，导致微信没有完成后台消息同步。
相比让微信长期加入白名单，更合理的解决方向是调整 NoActive 的 FCM 调度策略，让微信在收到 FCM 唤醒后获得足够的运行生命周期，完成消息同步后再重新进入墓碑状态。
这也是这次实测最重要的结论。