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

前言

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

简要对比

1iOS的实时消息推送

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

2Android的实时消息推送

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

3小结

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

技术原理

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

2iOS实时消息推送

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

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

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

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

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

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

1iOS的实时消息推送

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

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

  • 苹果服务器朝手机后台挂的一个 IM 服务程序发送的消息。
  • 然后,系统根据该 IM 消息识别告诉哪个 Apps 具体发生了什么事。
  • 然后,系统分别通知这些 Apps 。

2Android的实时消息推送

Apps 挂后台一直是 Android 引以为豪的特性(虽然我真的不知道是好处多还是坏处多。。),大家挂后台等待推送就成为技术选择。当然, Google 事后也提供类似苹果的推送方式了。倒也谈不上抄袭,毕竟苹果的整个技术实现也没有什么特别创新之处。 用户的电池? Apps 的开发者不会站在系统层面考虑的。他会假设其他 Apps 没有那么“不自觉”。而 Google 不强制的结果就是:没人真正为用户的电池负责。 但是, Google 的方案也并非全是悲剧:也因为整个技术方案非强制, Android 的 Apps 在接收到推送后的表现更为灵活。像 Line 的 Android 版本可以在推送通知的 Popup 上直接回复, iOS 就需要越狱才能做到了。

结语

强制和封闭,有时候并非坏事。他意味着做出这个决定的人,要为此负责。所以,如果说苹果的推送方案有何创新? 我以为是超越技术,不惜让公司承担更多风险和责任的解决方案。(类似的还有 BB 的专用网络, Kindle 的全球 3G )。 个人相信,担负起这些“额外”的责任,是值得的。只要是为了用户!

原文发布于微信公众号 - IT技术精选文摘(ITHK01)

原文发表时间:2018-05-11

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏携程技术中心

【QCon分享】携程无线App自动化测试实践

背景 近年来,携程的业务急剧增长如2015年第一季度交通票务预订量同比增长104%,而在携程所有的业务中约70%来自于无线,App累计下载量超过7亿(截至201...

277100
来自专栏腾讯云技术沙龙

董朝:打造云存储服务——移动端数据存储与分发

先做一个简单的自我介绍,2011年我毕业以后,一直从事IOS的开发,目前为止大概有七年的工作经验,前四年的时间主要在做APP里开发,之后三年主要做SDK相关的工...

654150
来自专栏张戈的专栏

细说五层网站架构,了解我们的网站压力究竟在哪里?

目前网站架构一般分成网页缓存层、负载均衡层、 WEB 层和数据库层,我其实一般还会多加一层,即文件服务器层,这样我们在后面的讨论过程中,我们可以依次用这五层对网...

47670
来自专栏EAWorld

建设DevOps统一运维监控平台,先从日志监控说起

前言 随着Devops、云计算、微服务、容器等理念的逐步落地和大力发展,机器越来越多,应用越来越多,服务越来越微,应用运行基础环境越来多样化,容器、虚拟机、物...

94070
来自专栏顾宇的研习笔记

Serverless 微服务架构案例无服务器架构 (Serverless Architectures) 简介 AWS Lambda 的编程模型Amazon API Gateway + AWS Lamb

Serverless 架构最早可以追溯到 Ken Fromm 发表的文章《Why The Future Of Software And Apps Is Serv...

28310
来自专栏全华班

springcloud学习手册-什么是微服务?

在介绍springcloud之前,先整体认识一下,什么是微服务?

20980
来自专栏喔家ArchiSelf

程序员眼中的测试

码农的产品和服务大都是以软件形式存在的,我们存在的价值之一就是快速提供高质量的软件产品或服务。如何保障软件的高质量呢?这与软件测试分不开的,测试是保证软件质量的...

20640
来自专栏IT大咖说

每秒处理1000万用户请求…云上架构如何实现高性能和高可用

40010
来自专栏华章科技

全栈工程师的18项基本技能,你会多少

本文总结了正在撰写的《Growth:Web开发思想》里提出的一系列实践,为18个步骤。

11110
来自专栏机器学习算法与Python学习

最新Python学习项目Top10!

过去一个月里,我们对近1000个Python 学习项目进行了排名,并挑选出热度前10的项目。这份清单涵盖了包括Web App, Geospatial Data,...

14320

扫码关注云+社区

领取腾讯云代金券