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

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

我们在 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个月,终于搞出一个能用的推送服务了。

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

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


你所看到是推送系列文章中的一篇,更多关于推送的文章:

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏企鹅号快讯

分布式架构的套路No.74

今天小蕉跟大伙一起聊聊分布式系统的架构的套路。在开始说套路之前,大家先思考一个问题,为什么要进行分布式架构? 大多数的开发者大多数的系统可能从来没接触过分布式系...

39290
来自专栏Material Design组件

Human Interface Guidelines — Requesting Permission

14160
来自专栏跟着阿笨一起玩NET

数据库水平切分的原理探讨、设计思路--数据库分库,分表,集群,负载均衡器

数据量巨大时,首先把多表分算到不同的DB中,然后把数据根据关键列,分布到不同的数据库中。库分布以后,系统的查询,io等操作都可以有多个机器组成的群组共同完成了。...

14020
来自专栏NetCore

对于大数据大流量情况下微软架构的水平扩展的遐想(瞎想)

最近回顾SAAS的书籍,书中的扩展架构都有点让我痴迷,但书中介绍的都是以Java,Apache,JBoss,Hadloop等技术实现负载均衡,大数据处理,对于微...

23280
来自专栏沃趣科技

Gitlab删库事件回顾,备份手段还停留在“原始社会”?

作者简介:孙朝阳 沃趣科技高级产品经理。 Gitlab简介 Gitlab是大家很熟悉的开源Git代码托管工具,国内公司大多使用社区版自行搭建私有化的内部代码托...

38060
来自专栏北京马哥教育

百万级访问量网站的技术准备工作

当今从纯网站技术上来说,因为开源模式的发展,现在建一个小网站已经很简单也很便宜,所以很多人都把创业方向定位在互联网应用。这些人里大多数不是 很懂技术,或者不是那...

48360
来自专栏数据和云

云端迁移 - Evernote 基于Google 云平台的架构设计和技术转型(上)

编辑手记:Evernote在短暂的时间里完成了向云端的迁移,其战果可喜可贺,然而每一次成功,都是背后的默默的努力和付出支撑起来的。在迁移的过程中,面对网络、硬件...

398110
来自专栏沃趣科技

备份重于一切:远离“Gitlab删库事件”,QBackup是你的最佳选择!

作者简介:孙朝阳 沃趣科技高级产品经理。 案发现场: Gitlab删库事件回顾 Gitlab是大家很熟悉的开源Git代码托管工具,国内公司大多使用社区版自行搭...

38980
来自专栏BestSDK

人机交互,6种最被BAT认可的加载模式

作为用户体验设计师,不管是产品、交互还是UI,都习惯于站在人机交互的角度去思考产品设计问题,在这个过程中我们往往会忽略了一个重要的过程:数据传输。先看下面这张图...

47040
来自专栏EAWorld

微服务模式系列之九:独享数据库

译者自序: 熟悉我的朋友都知道,我很不喜欢翻译东西,因为在两种语言的思维方式之间做频繁切换对我来说是件很痛苦的事情。但是这次不一样,公司和同事的大力支持降低了我...

35160

扫码关注云+社区

领取腾讯云代金券