IOS学习笔记—苹果推送机制APNs

推送是解决轮询所形成的流量消耗和 电量消耗的一个比较好的解决方案，在Android上，虽然Google提供了GCM（以前为C2DM），但在国内基本等于没用，各大Android应用 基本都本身架设推送Server或是使用第三方推送平台，例如新浪微博使用第三方推送平台“个推”（非广告）。今天要学习的是苹果提供的推送服务APNs（Apple Push Notification services）基本原理和工做流程。

苹果的推送服务APNs基本原理简 单来讲就是苹果利用本身专门的推送服务器（APNs）接收来自咱们本身应用服务器的须要被推送的信息，而后推送到指定的iOS设备上，而后由设备通知到我 们的应用程序，设备以通知或者声音的形式通知用户有新的消息。推送的前提是装有咱们应用的设备须要向APNs服务器注册，注册成功后APNs服务器会返给 咱们一个device_token，拿到这个token后咱们将这个token发给咱们本身的应用服务器，当有须要被推送的消息时，咱们的应用服务器会将 消息按指定的格式打包，而后结合设备的device_token一并发给APNs服务器，因为咱们的应用和APNs维持一个基于TCP的长链接，APNs 将新消息推送到咱们设备上，而后在屏幕上显示出新消息来。整个过程基本就这样，下面咱们看一下设备注册APNs的流程图：

上图完成了以下步骤：

1.Device链接APNs服务器并携带设备序列号

2.链接成功，APNs通过打包和处理产生device_token并返回给注册的Device

3.Device携带获取的device_token向咱们本身的应用服务器注册

4.完成须要培推送的Device在APNs服务器和咱们本身的应用服务器注册

执行顺序以下所示：

这 里要提到的一点是，咱们的设备和APNS服务器之间的通信是基于SSL协议的TCP流通信，两者之间维持一个长链接，当从APNS服务器注册成功后，必定 要将device_token发送给咱们的应用服务器，由于在推送过程当中，首相是由咱们的应用服务器（上图中Provider）将须要推送的消息结合 device_token按指定格式（后面会提到）打包而后发送给APNS服务器，而后由APNS服务器推送给咱们的设备。

好了，注册设备的过程完成了，接下来就是如何推送了：

 

推送的过程通过以下步骤：

1.首先，安装了具备推送功能的应用，咱们的设备在有网络的状况下会链接苹果推送服务器，链接过程当中，APNS会验证device_token，链接成功后维持一个长链接；

2.Provider(咱们本身的服务器)收到须要被推送的消息并结合被推送设备的device_token一块儿打包发送给APNS服务器；

3.APNS服务器将推送信息推送给指定device_token的设备；

4.设备收到推送消息后通知咱们的应用程序并显示和提示用户（声音、弹出框）

比较直观的流程参照下图：

上图显示了咱们的应用服务器将消息推送到咱们的App的完整路径，其实真正完成推送的是APNS服务器，咱们本身的应用服务器只是将须要推送的消息告诉苹果服务器，至于如何维护消息队列或如何保证消息能被推送到指定的设备上，这些都由苹果APNS给咱们作完了。

上面提到了将device_token和推送消息打包的过程，那么，接下来就看看这个信息包结构是怎样的：

上图显示的这个消息体就是咱们的服 务器（Provider）发送给APNS服务器的消息结构，APNS验证这个结构正确并提取其中的信息后，再将消息推送到指定的设备。这个结构体包括五个 部分，第一个部分是命令标示符，第二个部分是咱们的device_token的长度，第三部分是咱们的device_token字符串，第四部分是推送消 息体（Payload）的长度，最后一部分也就是真正的消息内容了，里面包含了推送消息的基本信息，好比消息内容，应用Icon右上角显示多少数字以及推 送消息到达时所播放的声音等。接下来咱们拆解看一下Payload（消息体）的结构：

 

这 其实就是个JSON结构体，alert标签的内容就是会显示在用户手机上的推送信息，badge显示的数量（注意是整型）是会在应用Icon右上角显示的 数量，提示有多少条未读消息等，sound就是当推送信息送达是手机播放的声音，传defalut就标明使用系统默认声音，若是传好比 “beep.wav”就会播放在咱们应用工程目录下名称为beep.wav的音频文件，好比当手机锁屏时QQ在后台收到新消息时的滴滴声。

有 这么一种状况，当咱们将应用从设备卸载后，推送的消息改如何处理呢。咱们知道，当咱们将应用从设备卸载后，咱们是收不到Provider给咱们推送的消息 的，可是，如何让APNS和Provider都知道不去向这台卸载了应用的设备推送消息呢？针对这个问题，苹果也已经帮咱们解决了，那就是 Feedback service。他是APNS的一部分，APNS会持续的更新Feedback service的列表，当咱们的Provider将信息发给APNS推送到咱们的设备时，若是这时设备没法将消息推送到指定的应用，就会向APNS服务器 报告一个反馈信息，而这个信息就记录在feedback service中。按照这种方式，Provider应该定时的去检测Feedback service的列表，而后删除在本身数据库中记录的存在于反馈列表中的device_token，从而再也不向这些设备发送推送信息。链接 Feedback service的过程一样使用Socket的方式，链接上后，直接接收由APNS传输给咱们的反馈列表，传输完成后断开链接，而后咱们根据这个最新的反馈 列表在更新咱们本身的数据库，删除那些再也不须要推送信息的设备的device_token。从Feedback service读取的数据结构以下：

结构中包含三个部分，第一部分是一 个时间戳，记录的是设备失效后的时间信息，第二个部分是device_token的长度，第三部分就是失效的device_token，咱们所要获取的就 是第三部分，跟咱们的数据库进行对比后，删除对应的device_token，下次再也不向这些设备发送推送信息。