国内第三方推送的起源

2010 年左右，Android 手机在国内迅速发展，Google 的原生推送（C2DM，现在的 GCM）由于种种原因不能正常使用，当时的 Android 开发者使用各种办法来解决这个问题，其中就包括 Android 手机厂商开发出自己的推送方案。

对于大部分开发者来说，除了做一个 App，还要独立开发一套推送系统是件异常困难的事情。哪怕是用户数量很大的 App ，这也不是一件容易的事情。于是在 2011 年底，我产生了做独立第三方推送服务的想法，也就有了后来的极光推送。

推送消息能送达的关键

这几年经常有业内的朋友探讨推送能否送达的关键因素。其实最重要的是 SDK 能否保活。

具体地说，有以下两方面：

1. SDK 如果不能及时地发起心跳，运营商网络的长连接会被断开。
2. SDK 的任务如果被杀掉了，不能被拉起，消息就完全没有机会下发。

参考之前的文章：推送技术原理：移动无线网络长连接

如果 SDK 端不能有效地保活，那么无论服务器端怎么优化，都不能保证消息及时地送达。

对 Android 手机厂商来说，这里有一个矛盾的问题。对于各个 App 的推送达到的效果来说是好事，但这样做一定程度上破坏了Android系统的生态，增加了功耗，也违背了系统清理后台设计的初衷。手机厂商都希望自己出产的手机能有尽量长的待机时间，但是 App 定时在后台启动、维持心跳的行为，会极大地影响手机待机时间。

因此，最近几年，手机厂商为了控制后台服务，持续地推出各种限制手段。比如之前的心跳对齐，也就是不允许 App 任意使用 RTC 后台唤醒手机。还有更严厉的手段，就是定时清理所有后台服务，并且不允许服务通过监听广播自动拉起。

第三方推送已死

正如前文所提到的，最近主流的 Android 手机都会清理后台服务，禁止服务自动拉起，以前第三方推送服务商的各种 SDK 保活手段相继失效，这个问题从根本上动摇了 Android 第三方推送服务的基础，导致几乎所有的 Android 第三方推送服务都不能保证送达。

面对这样的问题，App 开发者该如何应对？

更合理的方案

因为推送服务的特点，它最应该以系统原生服务的形态存在。在 iOS/Android 系统推出的早期，都考虑到了这个问题，iOS 有 APNs，Android 有 C2DM（GCM）。可惜的是，Android 的 GCM 在国内早已不能被有效使用，而 Android 方面没有试图解决这个问题，而把问题留给了手机厂商和 App 开发者。

考虑到推送服务的特点，我们自然而然就想到了通过厂商的推送通道来解决这个问题，就像在 iOS 上使用 APNs 一样。使用 App 内的消息通道发消息给 App，再通过厂商的推送通道唤醒 App，App 被打开后，接受消息通道的离线消息。

从目前的实践情况来看，这是解决后台进程被清理的最有效办法。 厂商推送通道

国内 Android 厂商推送通道现状

目前国内几个主要的 Android 厂商中，小米、华为 都有提供官方的推送服务。经过我们团队的验证，他们的推送服务在自己品牌的手机上，有相对稳定的送达率。目前表现最好的是小米，华为的推送延迟有时比较大，也不太稳定。

而另外的几家 OPPO、VIVO、金立 都没有官方的推送服务。

云巴近期推出了一键集成 小米、华为 推送的功能，方便开发者快速集成厂商的推送服务。但是对于没有提供推送服务的厂商，目前还没有特别好的办法。我们期待各主流手机厂商为了 App 有更好的体验，都能提供解决这个问题的方案。