第三方推送已死

国内第三方推送的起源

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

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

推送消息能送达的关键

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

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

SDK 若是不能及时地发起心跳，运营商网络的长链接会被断开。

SDK 的任务若是被杀掉了，不能被拉起，消息就彻底没有机会下发。

参考以前的文章：《推送技术原理》 http://zhang.hu/mobile-push/

若是 SDK 端不能有效地保活，那么不管服务器端怎么优化，都不能保证消息及时地送达。

对 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 有更好的体验，都能提供解决这个问题的方案。

文章做者：@Tiger_张虎 ，云巴 (yunba.io) 创始人，yunba.io 云端实时消息服务。 JPush 创始人，原CTO。 Oracle VM 创始团队成员