浅谈iOS和Android后台实时消息推送的原理和区别

640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1

前言


iOS和Android上的实时消息推送差异很大,往小了说是技术实现的差异,往大了说是系统实现理念的不同。实时消息推送在移动端互联网时代很平常,也很重要,它的存在让智能终端真正成为全时信息传播的工具。本文将从原理上谈谈两个平台上实时消息推送的区别。

简要对比


1iOS的实时消息推送


iOS 系统的推送(APNS,即 Apple Push Notification Service)依托一个或几个系统常驻进程运作,是全局的(接管所有应用的消息推送),所以可看作是独立于应用之外,而且是设备和苹果服务器之间的通讯,而非应用的提供商服务器。你的例子里面,腾讯 QQ 的服务器(Provider)会给苹果公司对应的服务器(APNs)发出通知,然后再中转传送到你的设备(Devices)之上。当你接收到通知,打开应用,才开始从腾讯服务器接收数据,跟你之前看到通知里内容一样,但却是经由两个不同的通道而来。

公众号推荐:

640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1

2Android的实时消息推送


而 Android,就不同,更像是传统桌面电脑系统做法。每个需要后台推送的应用有各自的单独后台进程,才能和各自的服务器通讯,交换数据。另外其实 Android 也有类似 APNS 的 GCM(Google Cloud Message),属于开发者可选,非强制。

3小结


所以你大概看出来区别,iOS 的消息推送机制面世之时是一种全新的解决方案(堪称平台中的平台),应用本身不能有常驻的后台进程,系统的开销少,内存使用更少,电量也更少(把更多的运算和资源开销放在云端,非设备端)。而 Android 的特点,虽然开销大,优点是更稳定快速,但不明显。

技术原理


640?wx_fmt=png


在这里,你要寄送的快件儿就是你要发的“消息”,送达房间相当于最终“接收消息的App”,顺丰公司在北京的总站点相当于这里提到的“设备”,送达房间的房间号就相当于这个环节里面提到的“包名”。

公众号推荐:

640?wx_fmt=jpeg

2iOS实时消息推送


iOS的推送是通过苹果自己的APNs服务进行的,用户需要将device_token以及消息内容等推送信息交给APNs服务器,剩下的均由苹果自己来完成。iOS应用的推送大部分情况下都要依赖苹果生态提供的APNs(Apple Push Notification Service)服务。

640?wx_fmt=png

首先作为设备标识的device-token是由APNs颁发的,App开发者或者第三方推送平台(图中的Provider)做的工作是收集这个device-token,APNs的推送是要求基于APNs颁发的device-token来推送的。只有正确的device-token会被APNs接受,如果是一个错误的、或者无效的device-token(比如App已经卸载了),APNs就不会接受。

640?wx_fmt=png

接着开发者使用第三方推送平台(图中的Provider)在将推送内容与范围选定之后进行推送,第三方推送平台将信息提交给APNs,剩下的操作全部都由APNs来进行完成,整个过程第三方推送平台就不能控制了。但是如果提供的device_token是失效的(app被卸载、系统版本升级导致device_token变化等情况)那么推送过程就会被中断,频繁的断线重连甚至会被APNs认为是一直DoS攻击。

640?wx_fmt=png


下图是Android平台消息推送的简单示意图:

640?wx_fmt=png

开发者通过第三方推送服务提供商将信息直接下发给需要的设备,第三方推送服务提供商与设备建立一条长连接通道,并且将消息路由到APP中(图中的设备1与设备2),对于像设备3这种无网络连接或是没有成功建立长连接通道的设备,会在设备3连网且推送消息没有过期的情况下自动收到由第三方推送服务提供商推送过来的消息,保证消息不会丢失。

实现上的差异所带来的直观感受


1iOS的实时消息推送


iOS 在系统级别有一个推送服务程序使用 5223 端口。使用这个端口的协议源于 Jabber 后来发展为 XMPP ,被用于 Gtalk 等 IM 软件中。

640?wx_fmt=png 

所以, iOS 的推送,可以不严谨的理解为:

  • 苹果服务器朝手机后台挂的一个 IM 服务程序发送的消息。

  • 然后,系统根据该 IM 消息识别告诉哪个 Apps 具体发生了什么事。

  • 然后,系统分别通知这些 Apps 。

640?wx_fmt=png


2Android的实时消息推送


Apps 挂后台一直是 Android 引以为豪的特性(虽然我真的不知道是好处多还是坏处多。。),大家挂后台等待推送就成为技术选择。当然, Google 事后也提供类似苹果的推送方式了。倒也谈不上抄袭,毕竟苹果的整个技术实现也没有什么特别创新之处。

用户的电池? Apps 的开发者不会站在系统层面考虑的。他会假设其他 Apps 没有那么“不自觉”。而 Google 不强制的结果就是:没人真正为用户的电池负责。

但是, Google 的方案也并非全是悲剧:也因为整个技术方案非强制, Android 的 Apps 在接收到推送后的表现更为灵活。像 Line 的 Android 版本可以在推送通知的 Popup 上直接回复, iOS 就需要越狱才能做到了。

结语


强制和封闭,有时候并非坏事。他意味着做出这个决定的人,要为此负责。所以,如果说苹果的推送方案有何创新?

我以为是超越技术,不惜让公司承担更多风险和责任的解决方案。(类似的还有 BB 的专用网络, Kindle 的全球 3G )。

个人相信,担负起这些“额外”的责任,是值得的。只要是为了用户!

640?wx_fmt=jpeg


猜你喜欢

转载自blog.csdn.net/gv7lzb0y87u7c/article/details/80276283
今日推荐