导语：
Apple Push Notification service (APNs)，即苹果推送通知服务，是苹果为 APP 开发商提供「间接的」推送通知到指定设备的一种服务。
为什么会有 APNs ？
由于移动设备内存、CPU、电量的局限性，iOS 不允许 APP 的进程常驻后台（事实上可以申请后台运行一段时间，最长约 10 分钟），这样当用户主动杀掉 APP，或者 APP 进入后台超过约定时长时，就意味着该 APP 进程的结束。这在很大程度上保障了前台 APP 的流畅性，也延长了手机的使用时长，获得了较好的用户体验。但是这也意味着，服务器无法主动和用户交互（如推送实时消息等）。为了解决这个限制，苹果推出了 APNs，允许设备和服务器分别与苹果的推送通知服务器保持长连接状态。
APNs 到底是什么？
iOS 的通知分为本地通知和远程通知。本地通知是由本地应用触发的，一般是基于时间的一种通知形式，如闹钟、待办事件等的提醒。远程通知是由开发商通过自己的服务器推送的一种通知形式，而 APNs 就是远程通知功能的核心。
关于远程推送，记住以下两点就够了：
- 客户端：
客户端发送自身设备的 UDID 和 Bundle Identifier 给 APNs 服务器，经苹果服务器加密后生成 deviceToken，随后只需将用户的 deviceToken 发送服务器保存。 - 服务器：
服务器在需要给某个用户推送消息时，需要将消息内容和 deviceToken 一起发送给 APNs 服务器，苹果服务器对 deviceToken 解密后可以找到具体的设备，然后将消息推送给该用户。
这里就很清楚了，其实 APNs 的本质就是服务器和客户端之间的中介。当服务器需要给客户端推送消息时，先将消息发送给苹果服务器，再由苹果服务器找到对应设备推送下去。
那为什么还要走中介，不直接发送呢？因为这样做一个设备（即所有 APP ）只需要和苹果的服务器建立一条长连接，而不需要每个 APP 都和服务器建立一条长连接。
APNs 的意义在哪里？
可能有些人还是不太明白 APNs 的意义，觉得也只是将多个长连接变成了统一的一个长连接而已，有必要那么做吗？
很有必要！
我们来看下 Android 的推送现状就明白了。
Android 事实上也有类似于 APNs 的一套用于推送的服务，简称 GCM，即 Google Cloud Messaging。但由于 GCM 需要谷歌服务器的支持，在国内由于「墙」的原因基本不能使用。这下就热闹了，国内出现了一大堆第三方推送服务商，如华为推送、小米推送、极光推送等。APP 通过集成这些推送服务来实现推送功能，而这些推送服务为了保持自己的长连接不被杀死，采用了各种保活、唤醒手段，这也是 Android 手机使用不流畅的真凶。之前也有看到「工信部要求国内安卓统一消息推送标准」的新闻，工信部都这么重视，可见统一推送的意义非凡。
APNs 新旧协议的对比
| 基于二进制的旧协议 | 基于 HTTP/2 的新协议 | |
|---|---|---|
| 长连接情况 | 无法维持，空闲会被断开 | 可以通过“PING”心跳包检测维持 |
| 推送结果反馈 | 成功时无响应，失败时断开连接 | 成功失败均有明确响应 |
| 推送长度 | iOS 8 及以上 2 Kb，以下 256 字节 | 统一 4096 字节（4 Kb） |
| 证书类型 | 不同类型的推送，需要配置不同的推送证书 | 只需要配置一种推送证书（Universal Push Notification Client SSL） |
想要了解具体区别，可以参考这篇文章 「国内 90%以上的 iOS 开发者，对 APNs 的认识都是错的」。
不言而喻，当然是尽早升级 HTTP/2 协议了。
收不到 APNs 推送怎么办？
- 首先要知道服务器推送成功，并不代表设备就能收到推送。服务器推送成功只是将消息交给了苹果服务器而已，苹果服务器还需要设备在线才能推送的。
- 其次 deviceToken 可能会在 APP 卸载重装后发生变化，客户端对此需要制定相应的汇报策略，以便服务器及时更新存储的 deviceToken 。
- 客户端只要能上报正确的 deviceToken 就可以说明客户端实现没问题了。否则检查客户端是否开启了远程推送通知服务，Bundle Identifier 是否与申请的推送证书匹配。
- 检查服务器内存缓存的 deviceToken 或者数据库存储的 deviceToken 是否与客户端汇报的一致。
- 排查服务器配置的证书是否过期，是否与客户端的 Bundle Identifier 匹配，或者是否勿用了其他类型的推送证书。
- 采用抓包工具（如 Wireshark ）抓包分析，看看服务器是否将消息交给苹果服务器，客户端是否收到了相应的推送通知。
参考:
（完）
