苹果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，下次不再向这些设备发送推送信息。

本篇主要介绍了苹果推送机制APNS的基本原理和响应的组件及服务，下篇将介绍如何在我们自己的项目中集成APNS服务实现消息的推送！

上一篇介绍了一下APNs的基本原理和处理流程，通过介绍，对APNs的机制有了大致的了解后，我们就来看看如何把APNS服务集成到我们自己的项目中来，首先登陆我们的Apple Developer后台为将要使用推送服务的App新建一个App ID，如下图，点击新建后输入基本信息：

新建完毕后找到我们刚申请的App ID，把“Enable for Apple Push Notification service”的勾选上

从上面可以看到，推送证书分为两个版本，一个是Development版，一个是Production版，分别对应开发证书和发布证书（这样确实有点麻烦，不过Apple这么做肯定是有自己的理由的）。由于现在我们用做开发测试用，所以只配置Development Push的SSL证书，如果是要发布App到市场的话，就配置Production证书，流程是完全一样的。点击右侧的Configure，进入认证界面，在下一步操作之前，我们要准备好我们本机的认证证书，这个证书在我们配置开发者账号时就申请过，如果没保存的话也可以重新生成一个，其生成方式如下：
首先打开“钥匙串”程序，点击菜单选项如下图：

然后输入基本信息，确认后将后缀名为.certSigningRequest的认证证书文件保存到本地：

保存证书到本地，待会会用到：

然后回到之前的页面，点击Configure进入，点击Continue后然后选择文件，上传我们刚刚申请的.certSigningRequest文件：

上传成功后，点击Generate按钮，Apple会根据我们上传的证书颁发一个开发板的推送证书给我们：

继续点击Continue，最后就进入到下载界面，下载推送证书到本地，保存备用：

下载下来的文件名为aps_development.cer，如果是发布版的推送证书，就为aps_production.cer。然后双击该证书，将推送证书安装到我们的Mac机器上，安装成功后会看到如下界面（如果是发布版，则证书的Development部分显示的是Production）

到这里，推送证书的申请和安装就完成了，接下来的操作就是根据我们之前申请的App ID，为其产生Provisioning证书，该证书申请完成后同样双击安装到我们的Xcode里面，开发时，将签名证书选择我们对应的Provisioning文件即可。这里主要介绍如何申请和安装推送证书，太详细的就不再叙述了，如果想了解更多，可以参考前人总结的文章（个人觉得很不错）http://article.ityran.com/archives/194

为了方便自己以后查找：
转载至：http://blog.csdn.net/ryantang03/article/details/8482259
和
http://blog.csdn.net/ryantang03/article/details/8540362