iOS 和 Android 的后台推送原理各是什么？有什么区别

　　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://wwwifanrcom/3979。但是复杂度无疑降低很多了。

　　Android 的推送

　　Apps 挂后台一直是 Android 引以为豪的特性（虽然我真的不知道是好处多还是坏处多。。）。。。大家挂后台等待推送就成为技术选择。

　　当然， Google 事后也提供类似苹果的推送方式了。倒也谈不上抄袭，毕竟苹果的整个技术实现也没有什么特别创新之处。

　　用户的电池？

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

　　但是， Google 的方案也并非全是悲剧：

　　也因为整个技术方案非强制， Android 的 Apps 在接收到推送后的表现更为灵活。

　　像 Line 的 Android 版本可以在推送通知的 Popup 上直接回复， iOS 就需要越狱才能做到了。

　　最后的话

　　强制和封闭，有时候并非坏事。他意味着做出这个决定的人，要为此负责。

　　所以，如果说苹果的推送方案有何创新？

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

　　个人相信，担负起这些“额外”的责任，是值得的。。。

　　只要是为了用户。

　　Notification Services是iOS机制的一个重要特色，是Apple为实现IP基础之上的＂移动通讯寻呼＂替代功能的重要举措。Google有类似的Push服务，但从结构上和功能上分析，都没有Apple的给力。

　　1 Notification解决的是下行推送问题，不涉及上行；

　　2 Apple负责建立独立的Notification服务器群，隔绝并代理所有第三方应用的服务器端（Server）针对自己应用的客户端（Client）所发起的推送服务；

　　3 Notification服务器独立建立自身和所有在iOS设备上开启Notification服务的客户端之间的推送关系和数据库，对客户端的识别方案建立在特别的Token上，一个iOS设备可以根据不同的应用申领不同的Token；

　　4 Notification服务器会将基于应用的数据库管理结果通报应用的服务器端，不影响第三方应用的业务逻辑和管理方式，透明；

　　5 Notification服务器建立并维护一一对应的Notification管道，到每一部开启Notification服务的iOS设备，具体形式为TLS-Https安全链接（基于IP），保活方式为每十五分钟触发一次，本质为应用层长链接，但效率有提升且集中管理；

　　6 Apple明文声明不保证推送的及时性和先后顺序，不建议将其作为IM工具的基础，但实际上Apple自有的Facetime和iMessenger类似IM的工具都建立在Notification基础之上，也确实有送不达、次序混乱的现象；

　　7 Apple很棒，系统初期即在iOS上植入Paging功能，高瞻远瞩，有取代运营商旁路整个3GPP体系的决心和才华，让人激赏！

iOS 的推送是统一挂在苹果服务器上的，app安装的时候设备会把token分享给app，app的服务器根据这个token发消息给苹果，苹果根据token发给设备。

设备和苹果的连接由系统挂在流量上的tcp长连接实现，装再多app也只需要挂这么一个连接就能保证推送。

因此，机制是由一个每一个需要推送的app通过API接入苹果提供的一个工具，由苹果来统一收取信息，实现推送，这样的一个设计，用流量换取性能／体验的一个设计，不错的买卖。

消息推送推荐极光。深圳市和讯华谷信息技术有限公司，于2012年05月31日在深圳市市场监督管理局南山局登记成立。公司以极光（JIGUANG）为品牌，因此深圳市和讯华谷信息技术有限公司也简称为极光。极光是以移动大数据的采集、清洗、挖掘、校准、脱敏及产品化为核心业务的移动大数据服务商。极光团队核心成员来自腾讯、摩根士丹利、豆瓣、Teradata和中国移动等公司。

ios消息推送原理主要分为以下几步：

1、由 App 向 iOS 设备发送一个注册通知，用户需要同意系统发送推送；

2、iOS 向 APNs 远程推送服务器发送 App 的 Bundle Id 和设备的 UDID；

3、APNs 根据设备的 UDID 和 App 的 Bundle Id 生成 deviceToken 再发回给 App；

4、App 再将 deviceToken 发送给远程推送服务器(自己的服务器), 由服务器保存在数据库中。

5、当自己的服务器想发送推送时，在远程推送服务器中输入要发送的消息并选择发给哪些用户的deviceToken，由远程推送服务器发送给 APNs。

6、APNs 根据 deviceToken 发送给对应的用户。

想要了解更多ios消息推送原理可以到深圳极光了解一下。深圳市和讯华谷信息技术有限公司于2011年成立，是中国领先的开发者服务提供商，专注于为开发者提供稳定高效的消息推送、一键认证以及流量变现等服务，助力开发者的运营、增长与变现。