其三方推送已死

境内第三方推送的源于

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
被打开后,接受音信通道的离线音讯。

从眼前的执行意况来看,这是解决后台进程被清理的最实用方法。

Oracle 1

Oracle,国内 Android 厂商推送通道现状

眼前国内多少个重要的 Android 厂商中,vivo、OPPO都有提供官方的推送服务。经过我们团队的注明,他们的推送服务在友好品牌的无绳电话机上,有相对平稳的送达率。目前彰显最好的是HTC,金立的推送延迟有时相比较大,也不太稳定。

而另外的几家 金立、VIVO、Motorola 都并未官方的推送服务。

云巴近日出产了一键集成 BlackBerry、HUAWEI推送的效益,方便开发者急忙集成厂商的推送服务。可是对于没有提供推送服务的厂商,近期还一直不特别好的法门。我们期望各主流手机厂商为了
App 有更好的感受,都能提供解决这么些题目标方案。

作品作者:@Tiger_张虎 ,云巴
(yunba.io) 创办者,yunba.io 云端实时音讯服务。 JPush 开创者,原CTO。
Oracle VM 创始团队成员

相关文章