iOS与Android的消息推送

iOS 系统的推送（APNS，即 Apple Push Notification Service）

依托一个或几个系统常驻进程运作，是全局的（接管所有应用的消息推送），所以可看作是独立于应用之外，而且是设备和苹果服务器之间的通讯，而非应用的提供商服务器。

• 例如，腾讯 QQ 的服务器（Provider）会给苹果公司对应的服务器（APNs）发出通知，然后再中转传送到你的设备（Devices）之上。当你接收到通知，打开应用，才开始从腾讯服务器接收数据，跟你之前看到通知里内容一样，但却是经由两个不同的通道而来。

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

• 所以， iOS 的推送，可以不严谨的理解为：
  APNs朝手机后台挂的一个 IM 服务程序发送的消息。
  然后，系统根据该 IM 消息识别告诉哪个 Apps 具体发生了什么事。
  然后，系统分别通知这些 Apps 。

  • iOS 自己做个长驻后台保持连接。所有应用，有必要（申请）并且被允许（用户可以改设置）的话，可以通过 APNs 中转到达用户。

使用久经考验的协议，技术风险小。
苹果勇于承担责任：他需要维护一个代价不小的服务器集群，而且要为服务器的 down 机负责。

选择低风险的技术方案 Bug 更少，减轻了用户的痛苦，这是构架师的功劳。
苹果承担责任，尽可能的减少了不可控的意外，保证了用户体验。

APNs的优点

• 安全。
  只有登录过的开发者可以通过苹果的服务器推送

• 快速，稳定，可靠。
  苹果掌控推送服务器和 OS 。

• 更省电。
  iOS 也为了真正地为用户体验负责，不允许应用在后台活动，这点也安全。

• 让整个系统的体验更统一和简单。
  不会出现杀后台这种事。（不用大量 Apps / Apps 的服务为了推送挂后台）。
  也不会出现 Apps 被杀就收不到推送这种事（早一点的新浪微博 Android 版仍然如此）。

• 开发容易。
  当然，开发者还是要做些事情，比如维护个服务器什么的： http://www.ifanr.com/3979 但是复杂度无疑降低很多了。

Android 的推送

Android 的推送：更像是传统桌面电脑系统做法。每个需要后台推送的应用有各自的单独后台进程，才能和各自的服务器通讯，交换数据。另外其实 Android 也有类似 APNS 的 GCM（Google Cloud Message），属于开发者可选，非强制。
Apps 挂后台一直是 Android 引以为豪的特性（虽然我真的不知道是好处多还是坏处多。。）大家挂后台等待推送就成为技术选择。

当然， Google 事后也提供类似苹果的推送方式GCM了。

用户的电池

• APNs 与 GCM 是类似的技术实现原理：即系统层有一个常驻的 TCP 长连接，一直保持的长连接，即使手机休眠的时候也在保持的长连接。

• 休眠时候都保持在那里的 TCP 长连接，不会很耗电。这是手机的设计来做到的。TCP长连接有个心跳的时间，在国外可以很长比如30分钟，在国内则因为网络环境复杂一般10分钟。客户端发起的心跳，会短暂地消耗手机电能，但在这个心跳间隔期间，则消耗电能是很少的。当在心跳期间服务器端有推送信息过来时，客户端可以收到并做处理。

题外话

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

但是， Google 的方案也并非全是悲剧：
也因为整个技术方案非强制， Android 的 Apps 在接收到推送后的表现更为灵活。
像 Line 的 Android 版本可以在推送通知的 Popup 上直接回复， iOS 就需要越狱才能做到了。
强制和封闭，有时候并非坏事。他意味着做出这个决定的人，要为此负责。

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

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

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

只要是为了用户。
勇于承担责任的公司也更像个可靠的成年人，而不是一个随意胡闹的孩子。