为什么 Android 推送这么难？
在讨论解决方案之前,我们必须先理解 Android 推送的“痛点”，相比于 iOS，Android 的推送环境要复杂得多，主要原因如下：
（图片来源网络，侵删）
- 系统碎片化严重：不同品牌（小米、华为、OPPO、Vivo 等）、不同系统版本的手机，其系统行为和后台管理策略（如“杀后台”）各不相同，一个在 A 手机上正常工作的推送，在 B 手机上可能就失效了。
- 严格的省电策略：为了延长续航，Android 系统和厂商 ROM 会对 App 的后台活动进行严格限制，一旦 App 进入后台，系统可能会随时终止其进程，导致无法接收推送。
- 网络限制：在 Doze 模式（深度睡眠模式）和 App Standby（应用待机模式）下，网络连接会被系统暂停或限制，GCM/FCM 的心跳包可能无法及时送达。
- 依赖第三方服务：国内无法直接使用 Google 的 FCM（Firebase Cloud Messaging），这导致了我们必须寻找替代方案。
正是因为这些痛点,单一的技术方案无法保证 100% 的送达率，因此通常需要采用“组合拳”策略。
推送的核心原理
无论采用哪种技术,推送的基本原理是相通的：
- 客户端：App 安装在用户手机上，需要有一个“守护者”在后台监听消息。
- 服务器：业务服务器，需要将消息发送给指定的用户。
- 推送通道：连接客户端和服务器的关键桥梁。
工作流程如下：
- 设备注册：App 启动时，向某个推送服务（如 FCM、厂商通道）注册，获取一个唯一的设备令牌。
- 绑定关系：App 将这个设备令牌上报给自己的业务服务器，并关联到当前登录的用户 ID，这样，业务服务器就知道“用户 A”的设备令牌是什么。
- 发送消息：业务服务器需要推送消息时，将消息内容和目标用户的设备令牌一起，发送到推送通道。
- 消息投递：推送通道接收到消息后，通过 Google 或厂商提供的服务，将消息推送到目标设备。
- 唤醒 App：设备上的系统级服务接收到消息后，会唤醒 App 的进程（如果已停止）或通过一个广播/Intent 来通知 App 有新消息到来，App 的后台服务接收到通知后，就可以进行相应的处理（如显示通知栏、更新 UI 等）。
主流的推送技术方案
业界主要有以下几种主流的推送方案,每种方案都有其适用场景。
（图片来源网络，侵删）
FCM (Firebase Cloud Messaging) - 国际 App 的首选
这是 Google 官方推出的推送解决方案，是 Android 推送的“黄金标准”。
- 原理：App 在后台时，FCM 通过 Google Play 服务与 Google 的服务器保持一个长连接，当有消息到来时，Google 服务器通过这个长连接唤醒 App。
- 优点：
- 官方支持：Google 亲儿子，兼容性最好，覆盖所有安装了 Google Play 服务的设备。
- 稳定可靠：Google 保证了服务的稳定性。
- 功能强大：支持通知消息和 数据消息，可以控制通知的点击行为、声音、图标等。
- 免费：对开发者免费。
- 缺点：
- 国内无法使用：由于网络原因，国内大部分设备无法连接 FCM 服务器，这是它在国内应用的最大障碍。
- 适用场景：面向海外用户的 App，或国内能稳定访问 Google 服务的特殊环境。
各手机厂商的推送服务 - 国内 App 的“必修课”
为了解决 FCM 在国内不可用的问题，各大手机厂商都推出了自己的推送服务，它们利用系统级的特权，可以更可靠地唤醒 App。
- 代表厂商：华为 (HMS Push)、小米 (Mi Push)、OPPO Push、Vivo Push、魅族 Push 等。
- 原理：厂商提供 SDK，App 集成后，可以利用系统的推送服务，这些服务拥有比普通 App 更高的权限，能更好地绕过系统的后台限制。
- 优点：
- 送达率高：因为是系统级服务，唤醒能力远超第三方方案。
- 针对性强：针对自家 ROM 做了深度优化。
- 缺点：
- 集成复杂：需要为每个厂商分别集成 SDK，处理不同的 API 和回调，维护成本高。
- 用户隐私政策：部分厂商对用户隐私有更严格的要求，需要用户手动开启权限。
- 覆盖不全：只能覆盖使用该品牌手机的用户。
- 适用场景：所有面向国内用户的 App，是保证推送送达率的基础。
第三方推送服务 - “一站式”解决方案
为了解决集成多个厂商 SDK 的麻烦，第三方推送服务应运而生，它们在内部封装了所有主流厂商的 SDK，并提供一个统一的 API 接口。
- 代表厂商：极光推送、个推、腾讯云移动推送、友盟+ 等。
- 原理：开发者只需集成第三方服务的 SDK，当需要推送时，第三方服务会根据目标设备的品牌，自动选择调用华为、小米还是 FCM 的通道进行下发。
- 优点：
- 集成方便：一套 SDK 搞定所有厂商，大大降低了开发和维护成本。
- 通道智能选择：通常具备“通道优先级”策略，例如优先使用厂商通道，失败后再尝试长连接通道（如 MQTT）。
- 功能丰富：除了基础推送，还提供用户标签、消息统计、弹窗等高级功能。
- 覆盖广：整合了厂商通道和自研的长连接通道，覆盖面更广。
- 缺点：
- 依赖第三方：服务稳定性和数据安全依赖于第三方厂商。
- 可能产生费用：虽然基础推送免费，但高级功能和海量推送可能需要付费。
- 适用场景：绝大多数国内 App，特别是中小型团队，能以最低的成本实现较高的推送成功率。
自建长连接方案 - 技术挑战大
这是一种完全自研的方案,不依赖任何外部推送服务。
（图片来源网络，侵删）
- 原理：App 在后台保持一个长连接（通常使用 TCP 或 MQTT 协议），连接到自己的业务服务器，服务器通过这个长连接直接向 App 发送消息。
- 实现方式：
- MQTT：一种轻量级的发布/订阅消息协议，非常适合物联网和移动推送场景，有成熟的客户端库（如 Paho）。
- 自定义 TCP/HTTP 长轮询：App 定期向服务器发送心跳请求，服务器有消息时立即响应。
- 优点：
- 完全可控：不依赖任何外部服务，数据安全和业务逻辑完全掌握在自己手中。
- 可定制化程度高：可以实现任何自定义的通信协议和消息格式。
- 缺点：
- 技术难度高：需要自己解决心跳、重连、消息保序、网络切换、省电模式下的唤醒等一系列复杂问题。
- 送达率保障难：在 Android 严格的省电策略下，长连接很容易被系统杀死，难以保证稳定性和送达率。
- 服务器压力大：需要维护大量的长连接，对服务器的性能和并发是巨大的考验。
- 适用场景：对数据安全和可控性有极高要求的大型互联网公司（如微信、QQ），它们有足够的技术实力和资源来维护这套系统。
方案对比与选择建议
| 方案类型 | 代表技术 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 官方推送 | FCM | 官方支持、稳定、免费 | 国内无法使用 | 海外App |
| 厂商推送 | 华为/小米/OPPO等 | 送达率高、系统级优化 | 集成复杂、覆盖不全 | 国内App的必备补充 |
| 第三方推送 | 极光/个推/腾讯云 | 集成简单、覆盖广、功能全 | 依赖第三方、可能收费 | 绝大多数国内App的首选 |
| 自建长连接 | MQTT / TCP | 完全可控、高度定制 | 技术难度大、送达率难保障 | 大型厂、对安全有极致要求 |
如何选择？
-
如果你的 App 主要面向海外用户：
- 直接使用 FCM，这是最简单、最可靠的选择。
-
如果你的 App 主要面向国内用户：
- 强烈推荐“厂商通道 + 第三方推送服务”的组合方案。
- 首选：集成
- 强烈推荐“厂商通道 + 第三方推送服务”的组合方案。
