導語：

Apple Push Notification service (APNs)，即蘋果推送通知服務，是蘋果為 APP 開發商提供「間接的」推送通知到指定設備的一種服務。

為什么會有 APNs ？

由于移動設備內存、CPU、電量的局限性，iOS 不允許 APP 的進程常駐后臺（事實上可以申請后臺運行一段時間，最長約 10 分鐘），這樣當用戶主動殺掉 APP，或者 APP 進入后臺超過約定時長時，就意味著該 APP 進程的結束。這在很大程度上保障了前臺 APP 的流暢性，也延長了手機的使用時長，獲得了較好的用戶體驗。但是這也意味著，服務器無法主動和用戶交互（如推送實時消息等）。為了解決這個限制，蘋果推出了 APNs，允許設備和服務器分別與蘋果的推送通知服務器保持長連接狀態。

APNs 到底是什么？

iOS 的通知分為本地通知和遠程通知。本地通知是由本地應用觸發的，一般是基于時間的一種通知形式，如鬧鐘、待辦事件等的提醒。遠程通知是由開發商通過自己的服務器推送的一種通知形式，而 APNs 就是遠程通知功能的核心。

關于遠程推送，記住以下兩點就夠了：

1. 客戶端：
   客戶端發送自身設備的 UDID 和 Bundle Identifier 給 APNs 服務器，經蘋果服務器加密后生成 deviceToken，隨后只需將用戶的 deviceToken 發送服務器保存。
2. 服務器：
   服務器在需要給某個用戶推送消息時，需要將消息內容和 deviceToken 一起發送給 APNs 服務器，蘋果服務器對 deviceToken 解密后可以找到具體的設備，然后將消息推送給該用戶。

這里就很清楚了，其實 APNs 的本質就是服務器和客戶端之間的中介。當服務器需要給客戶端推送消息時，先將消息發送給蘋果服務器，再由蘋果服務器找到對應設備推送下去。

那為什么還要走中介，不直接發送呢？因為這樣做一個設備（即所有 APP ）只需要和蘋果的服務器建立一條長連接，而不需要每個 APP 都和服務器建立一條長連接。

APNs 的意義在哪里？

可能有些人還是不太明白 APNs 的意義，覺得也只是將多個長連接變成了統一的一個長連接而已，有必要那么做嗎？

很有必要！

我們來看下 Android 的推送現狀就明白了。

Android 事實上也有類似于 APNs 的一套用于推送的服務，簡稱 GCM，即 Google Cloud Messaging。但由于 GCM 需要谷歌服務器的支持，在國內由于「墻」的原因基本不能使用。這下就熱鬧了，國內出現了一大堆第三方推送服務商，如華為推送、小米推送、極光推送等。APP 通過集成這些推送服務來實現推送功能，而這些推送服務為了保持自己的長連接不被殺死，采用了各種保活、喚醒手段，這也是 Android 手機使用不流暢的真兇。之前也有看到「工信部要求國內安卓統一消息推送標準」的新聞，工信部都這么重視，可見統一推送的意義非凡。

APNs 新舊協議的對比

想要了解具體區別，可以參考這篇文章 「國內 90%以上的 iOS 開發者，對 APNs 的認識都是錯的」。
不言而喻，當然是盡早升級 HTTP/2 協議了。

收不到 APNs 推送怎么辦？

1. 首先要知道服務器推送成功，并不代表設備就能收到推送。服務器推送成功只是將消息交給了蘋果服務器而已，蘋果服務器還需要設備在線才能推送的。
2. 其次 deviceToken 可能會在 APP 卸載重裝后發生變化，客戶端對此需要制定相應的匯報策略，以便服務器及時更新存儲的 deviceToken 。
3. 客戶端只要能上報正確的 deviceToken 就可以說明客戶端實現沒問題了。否則檢查客戶端是否開啟了遠程推送通知服務，Bundle Identifier 是否與申請的推送證書匹配。
4. 檢查服務器內存緩存的 deviceToken 或者數據庫存儲的 deviceToken 是否與客戶端匯報的一致。
5. 排查服務器配置的證書是否過期，是否與客戶端的 Bundle Identifier 匹配，或者是否勿用了其他類型的推送證書。
6. 采用抓包工具（如 Wireshark ）抓包分析，看看服務器是否將消息交給蘋果服務器，客戶端是否收到了相應的推送通知。

參考:

• Apple Push Notification service
• 國內 90%以上的 iOS 開發者，對 APNs 的認識都是錯的

（完）