標籤：android style blog http io os ar strong 資料
http://blog.163.com/[email protected]/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） 整個過程分為一下幾個階段：
- 管理主控台或者Server SDK初始化IOS App的認證（分為開發版認證和發行版認證）。
- 運行在手機上的Push SDK執行推送的初始化動作，將AppKey和DevicesToken上傳給雲推送伺服器，伺服器保留。
- 管理主控台或者Server SDK向雲推送伺服器發送一條推送指令，伺服器接到指令後，將控制台傳來的UserId(如果是廣播沒有UserId)，Msg，與伺服器保留的DevicesToken和認證一併打包傳給APNS伺服器。
- 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的認證以及認證密碼傳給個推即可。
IOS平台的幾個推送服務的對比
