苹果开发过程“iOS-Push的原理”

Push的原理

Push 的工作机制可以简单的概括为下图

   图中，Provider是指某个iPhone软件的Push服务器，这篇文章我将使用.net作为Provider。 

APNS 是Apple Push Notification Service（Apple Push服务器）的缩写，是苹果的服务器。

上图可以分为三个阶段：

第一阶段：.net应用程序把要发送的消息、目的iPhone的标识打包，发给APNS。 

第二阶段：APNS在自身的已注册Push服务的iPhone列表中，查找有相应标识的iPhone，并把消息发到iPhone。 

第三阶段：iPhone把发来的消息传递给相应的应用程序， 并且按照设定弹出Push通知。

首先是应用程序注册消息推送。IOS跟APNS Server要deviceToken。应用程序接受deviceToken。应用程序将deviceToken发送给PUSH服务端程序。服务端程序向APNS服务发送消息。APNS服务将消息发送给iPhone应用程序。

无论是iPhone客户端跟APNS,还是Provider和APNS都需要通过证书进行连接的。下面我介绍一下几种用到的证书。

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

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

 

苹果这种方式在技术上没有什么创新，但整个架构是很了不起的。

使用久经考验的协议，技术风险小。选择低风险的技术方案 Bug 更少，减轻了用户的痛苦，这是构架师的功劳。

苹果需要维护一个代价不小的服务器集群，而且要为服务器down 机负责。苹果承担责任，尽可能的减少了不可控的意外，保证了用户体验。

 

给用户带来的好处：

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

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

3、更省电。

4、让整个系统的体验更统一和简单。

5、开发容易。当然，开发者还是要维护服务器的。

 

Android 的推送

Apps 挂后台一直是 Android 引以为豪的特性，大家挂后台等待推送就成为技术选择。

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

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

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

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

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

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

 

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