iOS- 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://www.ifanr.com/3979。可是复杂度无疑下降不少了。

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

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

用户的电池？ 

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

可是， Google 的方案也并不是全是悲剧：
也由于整个技术方案非强制， Android 的 Apps 在接收到推送后的表现更为灵活。
像 Line 的 Android 版本能够在推送通知的 Popup 上直接回复， iOS 就须要越狱才能作到了。

最后的话
强制和封闭，有时候并不是坏事。他意味着作出这个决定的人，要为此负责。

因此，若是说苹果的推送方案有何创新？

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

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

只要是为了用户。

 

 

 

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　清澈Saup——来自知乎