iOS 和 Android 的后台推送原理各是什么？有什么区别？
炉门、尘规、陈汤姆 等人赞同 • 收录于 知乎周刊
iOS 系统的推送（APNS，即 Apple Push Notification Service）依托一个或几个系统常驻进程运作，是全局的（接管所有应用的消息推送），所以可看作是独立于应用之外，而且是设备和苹果服务器之间的通讯，而非应用的提供商服务器。你的例子里面，腾讯 QQ 的服务器（Provider）会给苹果公司对应的服务器（APNs）发出通知，然后再中转传送到你的设备（Devices）之上。当你接收到通知，打开应用，才开始从腾讯服务器接收数据，跟你之前看到通知里内容一样，但却是经由两个不同的通道而来。
而 Android，就不同，更像是传统桌面电脑系统做法。每个需要后台推送的应用有各自的单独后台进程，才能和各自的服务器通讯，交换数据。另外其实 Android 也有类似 APNS 的 GCM（Google Cloud Message），属于开发者可选，非强制。（更多请看本回答评论区里面 @Bill Cheng 的补充）
所以你大概看出来区别，iOS 的消息推送机制面世之时是一种全新的解决方案（堪称平台中的平台），应用本身不能有常驻的后台进程，系统的开销少，内存使用更少，电量也更少（把更多的运算和资源开销放在云端，非设备端）。而 Android 的特点，虽然开销大，优点是更稳定快速，但不明显。
更多请阅览话题：APNs - 知乎 | http://www.zhihu.com/topic/19699063
以及开发文档：Apple Push Notification Service (APNs) | http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
编辑于 2012-12-24 17 条评论 感谢
分享
收藏 • 没有帮助 • 举报 • 作者保留权利
122赞同反对，不会显示你的姓名
知乎用户，Old Coder
陈汤姆、Greyson、wayne chen 等人赞同
我感觉以上的回答，并没有正点地谈到“原理“，并且我对其评判断观点也不认同，所以尝试来回答下这个问题。
我的观点是：APNs 是 iOS 成功的一个非常重要的设计！
先说原理。
iOS 的推送：就是 Apple 官方的 APNs （Apple Push Notification service）。
Android 的推送：Google 官方的是 GCM (Google Cloud Messaging）。
本质上，APNs 与 GCM 是类似的技术实现原理：即系统层有一个常驻的 TCP 长连接，一直保持的长连接，即使手机休眠的时候也在保持的长连接。
这里对于大部分人来说，最不理解的就是，休眠时候都保持在那里的 TCP 长连接，不会耗电很厉害么？
答案是：不会。这是手机的设计来做到的。TCP长连接有个心跳的时间，在国外可以很长比如30分钟，在国内则因为网络环境复杂一般10分钟。客户端发起的心跳，会短暂地消耗手机电能，但在这个心跳间隔期间，则消耗电能是很少的。当在心跳期间服务器端有推送信息过来时，客户端可以收到并做处理。
这里有篇文章以 Android 为例做原理解释：http://blog.jpush.cn/index.php/jpush_wireless_push_principle/
再说 APNs 的设计成功处。
iOS 为了真正地为用户体验负责，不允许应用在后台活动。有了这个限制，但是对于终端设备，应用又是有必要“通知”到达用户的，随时与用户主动沟通起来的（典型的如聊天应用）。
这就是 APNs 的逻辑所在：iOS 自己做个长驻后台保持连接。所有应用，有必要（申请）并且被允许（用户可以改设置）的话，可以通过 APNs 中转到达用户。
这样就完善了！
有可能很多人没有真正地体会到 iOS 不允许后台应用的好处。我是 Android 开发人员，Android 手机上一般只保留几个常用的应用，不常用就卸载。但是我的 iPhone / iPad 上则是，除非空间不足，一般不会删除应用。
Android 就像 Windows，你要真的很费心去维护：有软件在干背后干坏事么？设备又给拖慢了，要清理。要考虑杀毒了。。。
Android 因为后台可以长驻，尤其是国内的 Android 的手机上 Google自家的推送服务 GCM 处于基本不可用的状态。所以，各App各显神通。聊天类应用的话，大多数直接借用 XMPP 规范里的一些成果。少量如微信有IM底子的，自己开发协议。这些在实现原理上与 APNs / GCM 没有本质的区别，但有一定的技术门槛。而大多数普遍应用，要使用推送的话，则使用轮询的方式简单实现。
其实，国外如 Urban Airship 自己实现了 Android 上的第三方提供的推送平台。近期国内如极光推送也实现了第三方的推送平台（技术与微信、GCM、APNs类似）。理论上，如果一个 Android 设备上多款应用都使用极光推送这种第三方推送平台的话，也可以如 APNs 一样达到节省电量、流量消耗的效果。
编辑于 2013-01-01 10 条评论 感谢
分享
收藏 • 没有帮助 • 举报 • 作者保留权利
653赞同反对，不会显示你的姓名
李楠，魅族营销中心招募设计师
Feb、炉门、李小琛 等人赞同 • 收录于 知乎周刊
iOS 的推送
iOS 在系统级别有一个推送服务程序使用 5223 端口。使用这个端口的协议源于 Jabber 后来发展为 XMPP ，被用于 Gtalk 等 IM 软件中。
所以， iOS 的推送，可以不严谨的理解为：
苹果服务器朝手机后台挂的一个 IM 服务程序发送的消息。
然后，系统根据该 IM 消息识别告诉哪个 Apps 具体发生了什么事。
然后，系统分别通知这些 Apps 。
这个消息的内容是这样的：
应该说，苹果这种方式在技术上没有什么创新。但是，整个架构是很了不起的。 因为：
1
使用久经考验的协议，技术风险小。
2
苹果勇于承担责任：
他需要维护一个代价不小的服务器集群，而且要为服务器的 down 机负责。
选择低风险的技术方案 Bug 更少，减轻了用户的痛苦，这是构架师的功劳。
苹果承担责任，尽可能的减少了不可控的意外，保证了用户体验。
这，只能说是公司决策者的功劳。
（从侧面说明有个懂技术的 VP 是多重要。。。而 Scott 走人了。。）
他们带给用户的好处也是实实在在的。
1 安全。
只有登录过的开发者可以通过苹果的服务器推送。
2 快速，稳定，可靠。
苹果掌控推送服务器和 OS 。
3 更省电。
4 让整个系统的体验更统一和简单。
不会出现杀后台这种脑残事。（不用大量 Apps / Apps 的服务为了推送挂后台）。
也不会出现 Apps 被杀就收不到推送这种脑残事（早一点的新浪微博 Android 版仍然如此）。
5 开发容易。
当然，开发者还是要做些事情，比如维护个服务器什么的： http://www.ifanr.com/3979。但是复杂度无疑降低很多了。
Android 的推送
Apps 挂后台一直是 Android 引以为豪的特性（虽然我真的不知道是好处多还是坏处多。。）。。。大家挂后台等待推送就成为技术选择。
当然， Google 事后也提供类似苹果的推送方式了。倒也谈不上抄袭，毕竟苹果的整个技术实现也没有什么特别创新之处。
用户的电池？
Apps 的开发者不会站在系统层面考虑的。他会假设其他 Apps 没有那么“不自觉”。而 Google 不强制的结果就是：没人真正为用户的电池负责。
但是， Google 的方案也并非全是悲剧：
也因为整个技术方案非强制， Android 的 Apps 在接收到推送后的表现更为灵活。
像 Line 的 Android 版本可以在推送通知的 Popup 上直接回复， iOS 就需要越狱才能做到了。
最后的话
强制和封闭，有时候并非坏事。他意味着做出这个决定的人，要为此负责。
所以，如果说苹果的推送方案有何创新？
我以为是超越技术，不惜让公司承担更多风险和责任的解决方案。（类似的还有 BB 的专用网络， Kindle 的全球 3G ）
个人相信，担负起这些“额外”的责任，是值得的。。。
只要是为了用户。
PS
勇于承担责任的公司也更像个可靠的成年人，而不是一个随意胡闹的孩子。
编辑于 2012-12-24 47 条评论 感谢
分享
收藏 • 没有帮助 • 举报 • 作者保留权利
5赞同反对，不会显示你的姓名
知乎用户，+
一二天、刘伟、许大人山 等人赞同
可参考这个：
http://news.mydrivers.com/1/250/250312.htm
另外，google最近开始提供一个叫做GCM(google cloud message)的服务，如果一个应用的推送采用这种模式的话，就和@鄭紫陽 讲到的iOS推送一个样了。GCM相关的程序应该是集成在所谓的Gapps中。
除了GCM外，还有别的公司提供android的推送基础设施的服务。
发布于 2012-12-21 添加评论 感谢
分享
收藏 • 没有帮助 • 举报 • 作者保留权利
6赞同反对，不会显示你的姓名
李琰
陈汤姆、薛纪杰、知乎用户 等人赞同
现在手机主流的几个平台都有自家提供Push的功能，让应用开发者能够很方便地把Push能力集成到应用中。
Android 上有 GCM (Google Cloud Messaging）
iOS 上有 APNs（Apple Push Notification service）
Windows Phone 上有 MPNs（Microsoft Push Notification service）。
但是由于Windows Phone的市场占比不高，所以一般也就没有人会专门做wp系统的推送。至于Android的GCM在国内基本上是不可用的。原因主要有以下两点：
一、国内大部分Android手机都不带Google服务，也就用不了GCM，这是主要的问题。
二、在国内Google的服务一般都不太稳定，原因你懂的。
所以现在在做消息推送的时候Android平台采用服务器与设备直接拉一条长连接的方式实现功能，而IOS平台则采用苹果自己的APNs服务。
在分别说这两个平台推送原理的时候，先回答一下题主关于服务器如何先找到设备、再找到app的问题。每一个设备都有一个自己的设备号，而设备中的app又都有一个唯一的包名。所以服务器只需要找到设备号与包名就可以定位到某个设备的某个应用，而这设备号与包名会一起构成一个标识符，叫做device_token，因此问题就简化为把device_token与消息内容等信息交给服务器，服务器把内容发到唯一的device_token上。这就好像你在上海要通过顺丰寄送一个快件儿给某某小区的某某房间，那么快件儿首先会邮递到顺丰公司在北京的总站点，之后再根据小区的地址投递/路由到某某房间，这样一个寄件过程就算完成了。在这里，你要寄送的快件儿就是你要发的“消息”，送达房间相当于最终“接收消息的App”，顺丰公司在北京的总站点相当于这里提到的“设备”，送达房间的房间号就相当于这个环节里面提到的“包名”。
接下来分别简单说一下这两个平台的推送实现原理。
首先是IOS平台，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平台，Android平台在不使用GCM的情况下就需要将自己的服务器或是第三方推送服务提供商的服务器与设备建立一条长连接，通过长连接进行推送。但是不建议自己设置服务器实现推送功能，一是因为成本太高（开发成本、维护成本），自己搭建的服务器无论是稳定性还是速度上都比不了第三方推送服务提供商的效果。另一个是因为自己的数据量较小，使用第三方推送服务提供商可以用他们的维度进行推送，实现精准推送。友盟推送就是做的比较好的，可以根据用户分群、地区、语言等多维度进行推送，最大程度减少对于用户的干扰，仅把消息推送给相关用户。友盟推送的优势是什么？ - 李琰的回答
下图是Android平台消息推送的简单示意图。
开发者通过第三方推送服务提供商将信息直接下发给需要的设备，第三方推送服务提供商与设备建立一条长连接通道，并且将消息路由到APP中（图中的设备1与设备2），对于像设备3这种无网络连接或是没有成功建立长连接通道的设备，会在设备3连网且推送消息没有过期的情况下自动收到由第三方推送服务提供商推送过来的消息，保证消息不会丢失。
对于消息推送想要了解更多，可以关注各推送服务提供商（友盟推送、百度云推送、极光推送等）的官网及论坛。友盟消息推送|app推送、友盟消息推送论坛
发布于 2016-01-08 1 条评论 感谢
分享
收藏 • 没有帮助 • 举报 • 作者保留权利
0赞同反对，不会显示你的姓名
陈宣宣，不会摄影的产品经理不是好运营
以jar的方式出现，集成于第三方客户端，解析第三方下行的数据，并把结果透传给第三方客户端；也可以上行第三方定制的客户端信息。
服务器：
一侧负责维护与成千上万的个推SDK的长时连接，另一侧与第三方服务器对接，将第三方定制数据下行推送至个推SDK。
第三方服务器：
数据推送的发起者，通过对接服务器，将数据发送至第三方客户端。
第三方客户端：
第三方集成SDK的客户端，推送数据正真的接收者和展现者。
发布于 2015-03-10 添加评论 感谢
分享
收藏 • 没有帮助 • 举报 • 作者保留权利
0赞同反对，不会显示你的姓名
杜一，DevStore小兵，不会做菜的码农不是好运营
iOS 系统的推送（APNS，即 Apple Push Notification Service）依托一个或几个系统常驻进程运作，是全局的（接管所有应用的消息推送），所以可看作是独立于应用之外，而且是设备和苹果服务器之间的通讯，而非应用的提供商服务器。你的例子里面，腾讯 QQ 的服务器（Provider）会给苹果公司对应的服务器（APNs）发出通知，然后再中转传送到你的设备（Devices）之上。当你接收到通知，打开应用，才开始从腾讯服务器接收数据，跟你之前看到通知里内容一样，但却是经由两个不同的通道而来。
而 Android，就不同，更像是传统桌面电脑系统做法。每个需要后台推送的应用有各自的单独后台进程，才能和各自的服务器通讯，交换数据。另外其实 Android 也有类似 APNS 的 GCM（Google Cloud Message），属于开发者可选，非强制。
推送服务因为支持平台的不同和链路，耗流量等指标不同而受众也不同，这里有很多的推送服务，你也可以通过他们的特点和配置过程了解对比下，推送服务
发布于 2015-07-28 添加评论 感谢
分享
收藏 • 没有帮助 • 举报 • 作者保留权利
16赞同反对，不会显示你的姓名
匿名用户
陈志鹏、知乎用户、没有人 等人赞同
听楼上说的苹果的推送机制很好用的样子，为什么我同学IPHONE QQ在线，我给他发消息，过了一个下午他才被推送到
发布于 2013-03-18 17 条评论 感谢
分享
收藏 • 没有帮助 • 举报 • 作者保留权利
1赞同反对，不会显示你的姓名
EZLippi，乐于造轮子http://www.ezlippi.com
知乎用户 赞同
Android的消息推送有AndroidPN，极光推送，推聊等，可以看下这个Androidpn 消息推送总结
编辑于 2015-03-29 添加评论 感谢
分享
收藏 • 没有帮助 • 举报 • 作者保留权利
24赞同反对，不会显示你的姓名
LeeJohnC，世界級波浪鼓演奏家
黑伞将军、丁傲林、Terry Chow 等人赞同
大概可能也許是這樣吧
发布于 2015-03-17 6 条评论 感谢
分享
收藏 • 没有帮助 • 举报 • 作者保留权利
2赞同反对，不会显示你的姓名
tyan，BLLLLL
知乎用户、知乎用户 赞同
原来差不多。就是体验上国内外差距大。那句话说的不错。安卓不是android.
发布于 2015-09-26 添加评论 感谢
分享
收藏 • 没有帮助 • 举报 • 作者保留权利
14赞同反对，不会显示你的姓名
Bevan，菇凉，染色体跳楼价，买一条送一条。
知乎用户、黎伟斌、另一种可能 等人赞同
Android用得越多，越觉得iOS的推送设计简直是神一样的存在。
---不是说推送技术牛逼，而且把后台/电量/卡顿这几个复杂取舍的问题，用一种极其巧妙的方法解决了。
发布于 2013-12-10 5 条评论 感谢
分享
收藏 • 没有帮助 • 举报 • 作者保留权利
4赞同反对，不会显示你的姓名
陈阳，Andrpid开发工程师。No coding no life
ipcjs、饶腾飞、知乎用户 等人赞同
做过DAU有50w以上的聊天功能的网络层的Android开发。
任何push都是基于长连接，实现方式就是socket和comet。
ios的推送仅仅推送一条push消息，假如做聊天的功能，聊天消息是推不到客户端的。iOS的push个人感觉比较鸡肋。
android就方便多了，开一个service，启动一个socket连接，定期发发心跳。
补充下：我说的这些，只是表明我之前是这么做推送的，iOS和Android平台的优劣大家都心知肚明，这方面没必要再起纷争。
推送的难点在于推送协议，没想到这块儿没人问及。。。唉。。。
举个例子，微信的协议？ActiveSync？XMPP？MQTT？协议升级的兼容方案，多点登录的同步问题，消息及时性可靠性的保证等等。
哈哈，最近又做了一个Push系统，上线之后DAU大概10w左右吧。抛弃了Comet方式，目前运营商的wap网络直接连着net网络了，核心思路和之前的都差不太多，但是推送协议是我们自己自定义的二进制协议，比之前的纯文本好多了洒～
编辑于 2014-09-09 35 条评论 感谢
分享
收藏 • 没有帮助 • 举报 • 作者保留权利
2赞同反对，不会显示你的姓名
Terry Chow，非著名砖家，吐槽专业户，挨踢技术宅，总…
知乎用户、辉常哥 赞同
目前安卓和IOS用户体验上最大的区别也就是消息推送机制了，如果一家独大的安卓厂商，推广统一的消息推送机制，强制杀掉流氓式常驻后台，那么安卓也可以不那么卡。
发布于 2015-09-23 5 条评论 感谢
分享
收藏 • 没有帮助 • 举报 • 作者保留权利
3赞同反对，不会显示你的姓名
知乎用户，代码弱逼，渣浪穷逼
知乎用户、知乎用户、老王 赞同
其实不止APNs和GCM，像极光推送百度云推送等其他推送的技术最基本的都是长连接和心跳包
而且话说国内没有什么脑残公司会用google提供的推送服务吧(笑)
可是自己维护一个推送服务器又是一件如此忧伤的事情
所以难道就没有人称赞一下牛逼的微信的推送吗
可能是国内环境的因素，微信的推送体验是最快的，IM厂商牛逼的优势有没有
编辑于 2013-12-17 添加评论 感谢
分享
收藏 • 没有帮助 • 举报 • 作者保留权利
1赞同反对，不会显示你的姓名
叶志锴，知之为知之，不知为不知，是知也。
黎伟斌 赞同
我还是喜欢通过统一推送服务去管理所有的推送消息，而不是每个APP自己都在后台开推送服务去强奸内存和电量。
发布于 2015-10-04 添加评论 感谢
分享
收藏 • 没有帮助 • 举报 • 作者保留权利
2赞同反对，不会显示你的姓名
孙少磊，互联网/移动互联网/项目管理 /运营/技术
饭团、Agyness LEE 赞同
两个平台的解决方案各有千秋， IOS推送更注重实现艺术， Android的推送实现则充分交给了应用提供商，第三方可控的地方较多。
发布于 2014-02-19 添加评论 感谢
分享
收藏 • 没有帮助 • 举报 • 作者保留权利
1赞同反对，不会显示你的姓名
黄炜，除了你自己没人知道你要什么。。。
知乎用户 赞同
国内也有不少做类似于google的开发平台，我业余做app都是用bmob的后端云服务平台，里面提供很多功能，比如推送，云存储等等，都是免费的，你可以去看看
Bmob移动后端云服务平台
发布于 2015-05-26 添加评论 感谢
分享
收藏 • 没有帮助 • 举报 • 作者保留权利
0赞同反对，不会显示你的姓名
James Ren，学生
就没有一个可以解决跨平台推送的方法吗？比如MQTT那样 broker发给客户端 无论是Android还是iOS都可以收到 实时run一个mqtt client在客户端？
发布于 2015-09-04 1 条评论 感谢
分享
收藏 • 没有帮助 • 举报 • 作者保留权利
0赞同反对，不会显示你的姓名
匿名用户
基本上现在APP进行信息推送会同时覆盖安卓和IOS。推荐直接使用腾讯信鸽推送吧，在推送的精准性和抵达率上有比较明显的优势。使用第三方推送服务的好处除了性能外，另外的好处是省去了开发成本。