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，下次再也不向這些設備發送推送信息。