Android聊天应用：为何选Firebase Cloud Messaging而非Intent Service做新消息通知？

嘿，这个问题问到点子上了！Intent Service乍一看确实简单省心，但你心里的顾虑没错——它确实存在几个容易被忽略的关键局限，咱们来拆解清楚，再聊聊FCM为什么是更合理的选择。

• 后台存活能力差：从Android 8.0开始，系统对后台服务的限制非常严格，Intent Service作为后台组件，一旦你的App被系统回收（比如用户清理后台、设备内存不足），onChildAdded的监听就会直接中断，新消息根本触发不了通知。这对聊天App来说是致命的——用户不可能一直把App挂在前台。
• 电量消耗过大：持续维持Firebase数据库的监听连接，会让设备一直处于联网活跃状态，长期下来耗电非常明显。用户一旦发现你的App比同类聊天软件耗电多，卸载率肯定会上升。
• 消息可靠性不足：如果设备网络临时断开，Intent Service的监听会中断，就算网络恢复，也得重新建立连接，这段时间内的新消息很可能就漏掉了，没有重试机制保障。

• 系统级推送通道，存活有保障：FCM是Android官方提供的推送服务，用的是系统统一维护的长连接，优先级远高于App自己的后台服务。哪怕你的App进程被回收，只要设备联网，系统就能帮你接收推送并触发通知，完美解决“App没开也能收到消息”的核心需求。
• 低功耗，符合系统优化要求：FCM的长连接是多个App共享的，系统会统一管理连接状态，不会让每个App都单独占用资源，相比Intent Service的独立监听，耗电量能降低很多，不会触发系统的耗电预警。
• 消息可靠性拉满：FCM自带消息重试和离线存储机制，如果设备暂时离线，消息会存在FCM服务器，等设备上线后自动推送，不会遗漏任何一条消息。另外还支持设置消息优先级，紧急消息可以优先送达，提升用户体验。
• 云端触发，解放客户端：用Firebase Cloud Functions监听数据库变化并触发FCM推送，所有逻辑都在云端完成，客户端不需要一直保持数据库连接，完全节省了客户端的资源开销，代码架构也更清晰。
• 跨平台兼容：如果以后你打算拓展iOS版本，FCM同样能无缝适配，不用再单独对接其他推送服务，一套方案覆盖双平台，减少后续的维护成本。

总结一下：Intent Service只适合用户持续在前台使用App的场景，但聊天App的核心就是离线也能收消息，所以FCM才是更长远、更靠谱的选择。虽然初期配置比Intent Service繁琐一点，但能帮你避开很多后期会头疼的稳定性和功耗问题。

内容的提问来源于stack exchange，提问作者Bas