IOS學習筆記33—蘋果推送機制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服務實現訊息的推送！