官方老爹之痛:为什么苹果能收到推送,而安卓不行?

还记得上次我们做过的试验么?

我们在 iOS 设备杀掉进程后能收到推送,而 Android 设备却不行。这个问题可困惑了小树很长时间,这天趁着工作清闲,又跑到小黑工位上请教了。

小黑喝了口茶便开始说,我们现在所有推送消息都是通过第三方推送推出去的。所以了解一下第三方推送是如何实现的非常重要。

当我们的 App 启动的时候,同时会启动我们App中附带的第三方厂商的推送服务,这时候 App 进程中就有一个 Socket 长连接一直与第三方厂商的推送服务器保持着。当我们有消息需要推送到用户设备上时,我们通过调用第三方厂商的推送接口,传入对应的别名就可以了。

小树听到别名感觉有点困惑,什么是别名啊?

其实别名就是第三方厂商用来标记唯一用户的一个标识。

当我们的 App 启动的时候,厂商要求 App 方在合适的时候将别名和该设别的 DeviceToken 这两个参数传给厂商,从而建立起绑定关系。

所以从本质上来说,第三方厂商最后还是通过 DeviceToken 去识别要推送到哪个设备的哪个 App 的。

而这个别名,一般情况下也是要能唯一标识一个用户。所以很多时候我们都用用户ID来作为别名,将其和 DeviceToken 绑定在一起。

小树听完之后 发觉可以画一个流程图来梳理一下整个流程了。

App启动 -> 启动第三方推送服务 -> 注册别名和DeviceToken -> 等待推送消息

画得很不错,非常清晰地表达了第三方推送的流程,小黑说道。

而对于后台开发小哥来说,如果要发送一条推送给用户,只需要将别名和推送内容作为参数调用第三方厂商的接口即可。

但这貌似还没回答之前的问题呢,为什么 iOS 设备在 App 进程被杀掉时能收到推送,而 Android 设备却不行呢?

小伙子果然穷追不舍,我这不是还没讲完嘛,别着急啊。小黑淡定地说。

我们上面说的这种情况,只在 App 进程还未被杀掉时适用。但当我们的 App 进程被杀掉时,第三方服务厂商的进程也会跟着被清除。

此时,如果我们还是通过设备与第三方厂商建立的 Socket 长连接进行推送消息接收,显然是无法正常进行的。所以,安卓设备就无法收到推送了。

而 iOS 设备能够在 App 进程死亡之后还接收到推送,那是因为第三方厂商在检测到自己与 iOS 设备的连接断开后,自动调用苹果官方的 APNS 服务进行消息推送。

而 iOS 设备的官方推送服务只要设备开机,则是永远存在的。所以我们的 iOS 设备就能够做到即使 App 进程被杀掉也能收到推送。虽然这推送推送功能很有限,但是能送达用户总比没送达好吧。

而 Android 设备不能在 App 进程死亡后收到推送,那是因为其没有官方推送的支持。

但现在也有一些情况下能够实现 Android 设备在 App 还未开启的时候,也可以接收到推送。

小树一听到还有这么一招,急忙问到底是什么方式啊?

这功能能否实现,这就依赖于第三方厂商的服务是否强大了。

假设我们手机上有两个 App,分别是「珍爱网」和「知乎」,它们都使用同一个推送厂商的推送服务。

当我们把两个 App 都启动,这时候进程上就会有两个关于推送的服务进程,一个归属于「珍爱网」App,一个归属于「知乎」这个 App。

当我们把「珍爱网」App 杀掉之后,珍爱网 App 对应的推送进程也就完蛋了。但是这时候不是有 知乎 App 里这个推送么。有些厂商就是利用了这一点,通过某些技术手段,使用「知乎」App的推送服务去唤醒「珍爱网」App 的推送服务,从而使得 珍爱网 App 的用户也能收到推送。

原来这还能这么玩啊,果然是自己的服务就可以有无限的想象空间啊。小树感慨道。如果我也能实现自己的一个推送服务就好了,这样我们就不用依赖第三方厂商,能够做更多定制化服务了。

自建推送服务虽然看似美好,但是开发成本和维护成本却是非常高的。如果公司业务规模不大,还是使用第三方推送服务比较靠谱。

不过我们公司规模其实也不小了,有将近上亿的用户,每天进行业务推送的量级也达到了百万级别。公司前阵子组织了开发团队里的开发精英,埋头干了2个月,终于搞出一个能用的推送服务了。

小树听到异常欣喜,觉得又有东西可以学习了。

不过今天还是不说那么多了吧,怕你学太多吸收不了。有机会我们下次来讲讲如何从零开始去设计一个推送系统,再如何一步步将其实现。

点赞