IOS平臺的幾個推送服務的對比

http://blog.163.com/scuqifuguang@126/blog/static/171370086201399113833299/

       最近研究了一下 極光推送 （JPush），百度雲推送和個推在IOS平臺的推送機制，作了一下對比。
       首先, 介紹蘋果推送通知服務的推送機制（APNS: Apple Push Notification Service）:

                                                  圖1  APNS的推送流程

上圖清晰地展現了APNS整個工做流程，其中Provider是第三方開發者的服務器。整個流程分三個階段：

• 第一階段：應用程序把要發送的消息、目的iPhone的標識打包，發給APNS。
• 第二階段：APNS在自身的已註冊Push服務的iPhone列表中，查找有相應標識的iPhone，並把消息發送iPhone。
• 第三階段：iPhone把發來的消息傳遞給相應的App，而且按照設定彈出Push通知。

極光推送（JPush）：
      JPush在IOS平臺上有完整的推送服務，他整個推送過程徹底不依賴APNS的服務，也就是圖1中的APNS變成了JPush本身的Push服務器。Iphone到Client App這個過程被簡化了，JPush採用的是透傳方式，消息的傳遞對於用戶是透明的，不可見的，消息從JPush服務器直接就傳到了Client App，用戶沒法感知。

百度雲推送：
      百度雲推送是基於APNS的，也就是說他僅僅是APNS的一個代理，他的推送過程以下圖：

                      
                                                     圖2  百度雲推送的推送流程（IOS）

 

 整個過程分爲一下幾個階段：

1. 管理控制檯或者Server SDK初始化IOS App的證書（分爲開發版證書和發行版證書）。
2. 運行在手機上的Push SDK執行推送的初始化動做，將AppKey和DevicesToken上傳給雲推送服務器，服務器保留。
3. 管理控制檯或者Server SDK向雲推送服務器發送一條推送指令，服務器接到指令後，將控制檯傳來的UserId(若是是廣播沒有UserId)，Msg，與服務器保留的DevicesToken和證書一併打包傳給APNS服務器。
4. APNS接到數據後，根據UserId,將消息推送給指定的IPhone設備。

PushSDK 在APNS的編碼基礎上增長本身服務的初始化和綁定接口代碼。

 

個推：

     個推的作法就更簡單了，他的整個交互圖以下：

      

                                                              圖3  個推推送交互圖（IOS）

       他對開發商的要求最高，他的官方論壇上有這麼一句話：「開發者首先有一個本身的iOS推送組件，該組件能夠實現從大家到蘋果服務器的推送，根據咱們提供的協議增長相應接口」。圖3的右半部分，也就是第三方到APNS這個部分都是由第三方本身實現的，個推僅僅是實現個推服務器與第三方之間的交互。
       圖中各個函數的含義：

• auth（）：個推服務器向第三方發送「驗證」指令，若是驗證結果正確，則第三方返回Token，8個推服務器保留這個Token。
• get_tags（）：個推服務器向第三方發送「獲取tag」指令，第三方向個推服務器返回當前存在的tag列表，個推服務器保留。
• push_by_tags（）：個推服務器根據保留的tag列表，能夠選擇向一些tag發送消息，講「向tag發送消息」的指令傳遞給第三方，第三方完成消息發現送任務。
• push_by_divece（）：個推根據divicesId調用第三方發送接口，完成發送任務。

縱觀整個流程，個推服務器作的都是一些比較簡單的事情，他要求第三方根據他的協議完成auth(),get_tags(),push_by_tags(),push_by_divice()接口，並給出API的地址，供個推服務器調用。筆者認爲他這樣作的緣由是但願可以與android平臺的推送共用一套系統，便於管理維護。

2014年2月25日更新：    筆者今天去個推主頁查看的時候發現個推的解決方案換了，個推最近本身提供了到APNS組件，這樣第三方開發者就不須要本身實現到APNS的組件服務了，只須要把IOS的證書以及證書密碼傳給個推便可。