Wear OS休眠（Doze）模式下Firebase数据消息无法持续接收求助

嘿，我太懂你这种“初期正常、过段时间突然收不到消息”的头疼了——Wear OS的后台管控可比手机严格多，哪怕是高优先级消息也容易踩坑。结合你的场景（纯数据消息、pyfcm发送、onMessageReceived()处理、高优先级设置），我推测大概率是这几个原因导致的：

• Wear OS后台应用限制触发
  Wear OS对后台进程的管控逻辑比Android手机更苛刻，哪怕消息是高优先级，如果你的应用后台进程被系统回收，onMessageReceived()根本没机会触发。你可以去设备设置→应用→你的应用→电池，看看是不是被设为“受限”或者“省电模式下限制后台活动”；另外Wear OS的App Standby Bucket机制也可能搞事情，如果应用长时间没用户交互，会被分到低优先级桶，这时候高优先级消息也可能被延迟甚至拦截。

• pyfcm发送的消息参数有遗漏
  虽然你说设了高优先级，但得确认pyfcm的参数完全符合FCM对Wear OS的要求：

  • 有没有遗漏content_available: true？这个参数是唤醒Doze模式设备的关键，纯数据消息也必须加上；
  • 检查priority是不是真的设为high——有些pyfcm版本的参数格式容易写错，别误设成normal；
  • 有没有设置合理的ttl？如果ttl设得太短，消息可能在设备未唤醒时就过期了，建议设为86400（24小时）试试。

• 系统级FCM服务被限制
  有时候Wear OS的Google Play服务（com.google.android.gms.gcm）本身会被省电策略限制，导致没法及时接收消息。可以试试：

  • 重启Wear设备，排查是不是临时的服务异常；
  • 检查Google Play服务是否为最新版本，旧版本的GMS确实存在Doze模式下的唤醒bug。

• onMessageReceived()处理逻辑有问题
  初期正常不代表逻辑没问题，如果处理消息时包含耗时操作（比如同步网络、大量计算），系统会认为你的应用在后台滥用资源，进而限制后续的消息接收。建议把耗时操作放到WorkManager中执行，别在onMessageReceived()里直接阻塞线程。

最后给你几个调试小技巧：

1. 用Firebase控制台发送测试消息（带高优先级和数据字段），和pyfcm发送的消息做参数对比，排查参数差异；
2. 在onMessageReceived()里加详细日志，用adb logcat实时查看，确认消息是没到达还是到达后没处理；
3. 模拟Doze模式测试：把设备静置30分钟以上，再发送消息，看日志里有没有FCM的唤醒记录。

内容的提问来源于stack exchange，提问作者Георги Ангелов