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

 ·  2017-02-28 22:02:51  ·  北京瑞铭安普科技有限公司

iOS-Push的原理

Push的原理

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


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

APNS Apple Push Notification ServiceApple Push服务器)的缩写,是苹果的服务器。

上图可以分为三个阶段:

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

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

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

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

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

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 GCMGoogle Cloud Message),属于开发者可选,非强制。

 

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