目录

一、简介

二、APNs推送流程

三、什么是deviceToken

四、消息体

五、APNs推送中的问题

APNs 简介

Apple Push Notification service (APNs)，即苹果推送通知服务。

为什么会有 APNs ？

由于移动设备内存、CPU、电量的局限性，iOS 不允许 APP 的进程常驻后台(事实上可以申请后台运行一段时间，最长约10分钟)。

当用户主动杀掉APP或者APP进入后台超过限定时长时，就意味着该APP进程的结束。这很大程度保障了前台APP的流畅性，也延长了手机的使用时长。这也是苹果用户体验好的原因之一。但是这也意味着，服务器无法主动和用户交互(如推送实时消息等)。为了解决这个限制，苹果推出了APNs，允许设备和服务器分别与苹果的推送通知服务器保持长连接状态。

iOS的通知

iOS分本地通知和远程通知,(APNs)是远程通知功能的核心.

本地通知是由本地应用触发的。一般是基于时间的一种通知形式，如闹钟、待办事件等的提醒。

远程通知是通过我们自己的服务器推送消息的一种通知形式。

APNs推送流程

假如我们的苹果设备(AC电脑、笔记本、iPad、iPhone等)安装了一个名叫XXX的应用。那么我们具体是怎样接收到推送通知的那？？接下来我们就说说具体这个过程。下面是苹果APNs官方简介 中提供的APNs推送流程的图

APNs_img1.png

Provier 代表我们自己的应用服务器

APNs 代表苹果的APNs推送服务器

接着是代表的就是苹果的设备

Client App 代表我们开发的应用

说明：

安装了XXX应用的苹果设备需要向APNs服务器注册，注册成功后APNs服务器会返回一个deviceToken，并且二者之间会维持一个长连接(这个长连接是基于SSL协议的TCP流通讯)

拿到这个deviceToken后我们将这个deviceToken发给我们自己的服务器

当有消息需要被推送时，我们自己的服务器会将消息按指定的格式结合设备的deviceToken一并打包 然后发给APNs服务器

APNs将新消息推送给我们的设备上，然后就在设备的屏幕上显示出来了 (因为我们的设备和APNs服务器二者之间维持了一个长连接)

注意说明：

真正完成推送的是APNS服务器。消息一定是由APNs服务器推送给我们的设备的，我们自己的应用服务器只是将需要推送的消息告诉APNs服务器。至于如何维护消息队列或如何保证消息能被推送到指定的设备上，这些都由苹果APNs做好的。

什么是deviceToken ？

deviceToken是一个APP装在一个设备上的唯一标识符。一个APP在不同的设备上deviceToken不一样；一个APP删除之后再次安装deviceToken也不一样。

在项目代码AppDelegate里面有一个回调方法，当APNs注册成功通过该回调方法可以获取到返回的deviceToken

- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken

上面说过当有消息需要被推送时，我们自己的服务器会将消息按指定的格式结合设备的deviceToken一并打包 ，APNs拿到这个包之后验证这个包结构是否正确并提取其中的信息后，再将消息推送到指定的设备。

接下来就来看看这个包的结构：

APNs_img2.jpg

这个包分五个部分

第一个部分是命令标示符

第二个部分是我们的deviceToken的长度

第三个部分是我们的deviceToken字符串

第四个部分是推送的消息体(Payload)的长度

最后一个部分也就是真正的消息内容了，里面包含了推送消息的基本信息。(比如消息内容，应用icon右上角显示的数字角标以及推送消息到达时所播放的声音等)

接下来详细看一下Payload(消息体)的结构

APNs_img3.png

Payload(消息体)其实就是个JSON结构体。上面的图只是简单的一种消息体更多详细类型的消息体类型，请看消息体苹果官方相关介绍

alert里的就是会显示在用户手机上的推送标题内容

badge显示的数量(注意是整型)是会在应用icon右上角显示的数量，提示有多少条未读消息等

sound就是当推送信息送达是手机播放的声音，传defalut就标明使用系统默认声音，如果传比如“xxx.wav”就会播放在我们应用工程目录下名称为xxx.wav的音频文件，比如当手机锁屏时QQ在后台收到新消息时的滴滴声。

安全架构

为了保证安全性，APNs用连接信任(connection trust)和token信任(token trust)来控制通信入口，你要用APNs则必须用通过这两种验证。

连接信任

连接信任第一个作用是保证APNs连接的provider是苹果已经同意可通信的，然后第二个是保证与APNs连接的设备的合法性，第二步是APNs处理的，你所要处理的是provider与APNs之间的连接安全性。

服务器与APNs之间的连接信任

每个服务器都必须要有唯一的provider证书和私钥，都是用来验证连接的。provider证书就是在开发者官网申请的。

服务器通过TLS验证和APNs连接，HTTPS中用的也是TLS协议，即四步握手，首先初始化TLS连接，即provider(服务器)发送请求给APNs，APNs服务器返回APNs证书(即公钥)给provider，然后服务端收到后生成provider证书后再返回给APNs，APNs收到后验证后即可以建立TLS连接，不过APNs用的不是HTTPS，而是HTTP/2，具体过程如下图

APNs推送中的问题

问题一： 当应用从设备卸载后，推送的消息改如何处理？？

我们知道当应用从设备卸载后，是收不到推送消息的。但是，如何让APNs和Provider知道不再向这台卸载了应用的设备推送消息呢？

针对这个问题苹果也已经帮我们解决了(那就是Feedback Service)。它是APNS的一部分，APNs会持续的更新Feedback service的列表，当我们的Provider将信息发给APNs服务器，APNs推送信息到我们的设备时，如果这时设备无法将消息推送到指定的应用(应用已经删除)，就会向APNs服务器发送一个反馈信息，而这个信息就记录在Feedback service中。按照这种方式，Provider应该定时的去检测Feedback service的列表，然后删除在自己数据库中记录的存在于反馈列表中的deviceToken，从而不再向这些设备发送推送信息。连接Feedback service的过程同样使用长连接的方式，连接上后，直接接收由APNs传输给我们的反馈列表，传输完成后断开连接，然后我们根据这个最新的反馈列表在更新我们自己的数据库，删除那些不再需要推送信息的设备的deviceToken。

从Feedback service读取的数据结构如下：

从Feedback service读取的数据结构

结构中包含三个部分

第一部分是一个时间戳，记录的是设备失效后的时间信息

第二个部分是deviceToken的长度

第三部分就是失效的deviceToken，我们所要获取的就是第三部分，跟我们的数据库进行对比后，删除对应的deviceToken，下次不再向这些设备发送推送信息

问题二：iOS 重复推送之谜 文章地址

问题三：收不到 APNs 推送怎么办？

首先要知道服务器推送成功，并不代表设备就能收到推送。服务器推送成功只是将消息交给了苹果服务器而已，苹果服务器还需要设备在线才能推送的。

其次 deviceToken 可能会在 APP 卸载重装后发生变化，客户端对此需要制定相应的汇报策略，以便服务器及时更新存储的 deviceToken 。

客户端只要能上报正确的 deviceToken 就可以说明客户端实现没问题了。否则检查客户端是否开启了远程推送通知服务，Bundle Identifier 是否与申请的推送证书匹配。

检查服务器内存缓存的 deviceToken 或者数据库存储的 deviceToken 是否与客户端汇报的一致。

排查服务器配置的证书是否过期，是否与客户端的 Bundle Identifier 匹配，或者是否勿用了其他类型的推送证书。

采用抓包工具(如 Wireshark )抓包分析，看看服务器是否将消息交给苹果服务器，客户端是否收到了相应的推送通知。

参考文档：