一、APNS介紹（原生推送實現原理）
在iOS平臺上，大部分應用是不容許在後臺運行並鏈接網絡的。在應用沒有被運行的時候，只能經過 Apple Push Notification Service (APNs) 把數據發送到終端用戶。對於互聯網應用，正確高效的使用APNs 顯然很是重要。html
Apple爲應用開發者提供了一個APNS推送接口，稱爲binary interface。ios
（1）Binary Interface V1
最第一版本的binary interface 協議以下圖，這裏咱們稱之爲v1。 緩存
v1 協議有幾個問題：服務器
一、消息是否發送成功沒有明確的反饋；網絡
二、若是一個消息發送失敗，好比由於deviceToken 不合法，APNs 會在大約500ms 後斷掉連接，在斷鏈前發送的消息也會發送失敗；併發
三、經驗證，feedback service 只有報告應用被卸載後，形成deviceToken 失效的錯誤。而不會報告deviceToken 不合法這種類型的推送錯誤。app
也就是說若是咱們給一批用戶發消息，只要有一個deviceToken 不合法，將會有可能形成若干個用戶收不到消息。而且沒辦法確認哪些deviceToken不合法，哪些deviceToken 須要被重發。這應該是APNs 丟消息的一個重要的緣由。ide
（2）Binary Interface V2
通過開發者不斷的向Apple 反饋這個問題，Apple 終於推出了一個新版本的binary interface，稱爲enhanced binary interface，咱們稱這爲v2。測試
咱們發現，在v1 的基礎上增長了兩個字段：優化
Identifier一個任意的值，用於一條消息的識別。若是發送出現問題，錯誤應答裏會把Identifier 帶回來。
Expiry離線消息超時的時間，若是爲0或者小於0，APNs 不會保存這條消息。
和v1 同樣，若是消息發送沒有問題，APNs 不會有任何返回。和v1 不一樣，而且很重要的改進是，若是發送出現錯誤，v2 會在斷鏈以前返回一個錯誤應答，帶上發消息時的Identifier 和一個錯誤碼。
根據這個錯誤應答，咱們有機會找到是哪條消息發送出錯，並肯定哪些消息須要被重發。
二、應用內消息和推送的區別
應用內消息（如下簡稱消息）和推送通知的區別，消息：不須要Apple 推送證書。由第三方的服務器下發，而不是APNs。相比通知，更快速，幾乎沒有延遲，可用於IM 消息的即時送達。可以長時間保留離線消息，可獲取全部歷史消息內容。
經過長鏈接技術下發消息，所以：手機必須啓動並與第三方服務器創建鏈接。
若是手機啓動馬上切至後臺，極可能鏈接沒有創建。手機必須處於前臺才能收到消息。手機從後臺切回前臺，會自動從新創建鏈接，並收到離線消息。
沒有任何展現（橫幅、通知中心、角標、聲音），所以能夠：自定義字段實現UI 效果。徹底在靜默狀況下處理App 內部邏輯。
應用內消息在App離線下，接收到應用內消息，把消息緩存到服務器，當App在線時和服務器創建長鏈接，服務器再把全部緩存的離線消息一塊兒推給App，這是目前iOS聊天類App實現的方案。第三方服務提供的免費資源通常裏面緩存條目是有限制的（極光緩存5條）。
三、App推送方案彙總
（1）本身搭建推送服務器
根據以上介紹要搭建本身的推送服務器，要根據APNs提供的推送協議，證書配置，搭建本身的推送服務，經過APNs推送在App殺死、後臺、前臺狀態均可以收到通知，以下圖咱們搭建的就相似於Provider的做用，經過APNs推送會受到網絡、APNs服務器併發量等限制會出現延時（可忽略不計）。
本身搭建推送服務優勢：不受限於第三方服務，擁有本身的推送服務，獨享消息推送通道，對本身業務的擴展擴大頗有必要。缺點是：一直須要人員維護推送服務和APNs服務的對接，增長開發和運營成本，顯然在發展公司從起點去作是很是艱難的。
如上圖是推送流程圖，服務器根據APNs提供的協議格式，把消息傳遞到APNs服務器，而後APNs服務根據deviceToken推送到指定設備，設備根據App包名找到對應的App。
上圖是上面的一個內容補充，更詳細的說明APNs的推送流程。設備向APNs服務註冊deviceToken，設備把deviceToken發送給第三方服務，服務器根據APNs的協議格式組合成消息轉發給APNs服務，APNs服務通知設備。
（2）極光推送
極光推送（JPush）是國內首個爲移動應用開發者提供專業、高效的消息推送服務的產品。從上圖能夠看出，JPush包括2個部分，APNs推送（代理），與JPush應用內消息。
紅色部分是APNs 推送，JPush 代理開發者的應用（須要基於開發者提供的應用證書），向蘋果APNs服務器推送。由APNs Server推送到iOS設備上。
藍色部分是JPush應用內推送部分，即App啓動時，內嵌的JPush SDK會開啓長鏈接到JPush Server，從而JPush Server能夠推送消息到App裏。
JPush iOS 推送相比直接向APNs 推送有什麼好處？
減小開發及維護成本：
一、應用開發者不須要去開發維護本身的推送服務器與APNs 對接。
二、集成了JPush iOS SDK 後沒必要本身維護更新device token。
三、經過JPush 的Web Portal 直接推送，也能夠調用JPush的HTTP 協議API 來完成，開發工做量大大減小。
減小運營成本：
一、極光推送支持一次推送，同時向Android, iOS, WinPhone 三個平臺。支持統一的API 與推送界面。
二、極光推送提供標籤、別名綁定機制，以及提供了很是細分的用戶分羣方式，運營起來很是簡單、直觀。
提供應用內推送：
一、除了使得APNs 推送更簡單，也另外提供應用內消息推送。這在相似於聊天的場景裏頗有必要。
我的集成使用體驗：集成相對簡單，SDK集成度高，推送體驗效果優異，不多出現延時狀況，惟一的缺點是免費版本沒有作離線點擊通知作統計，能夠爲用戶設置標籤進行組推送、別名實現用戶的單一推送，支持定時推送，能實現康加App推送須要的全部功能。
收費狀況：
提供VIP服務，免費和VIP差異在最大併發數、專享高速推送通道、離線保存消息時間、消息送達統計等，詳情見https://www.jiguang.cn/push-price
（3）信鴿推送
信鴿是深圳市騰訊計算機系統有限公司推出的一款專業的免費移動消息推送營銷平臺。針對iOS設備的消息推送，信鴿平臺目前只借助APNs通道，暫不支持應用內自有通道的消息下發。
一、設備Token的自動化獲取和註冊，下降接入門檻。
二、帳號、標籤與設備的綁定接口，以便開發者實現特定羣組的消息推送，豐富推送方式。
三、點擊量上報，統計消息被用戶點擊的次數。
我的集成使用體驗：官網目前主要版本是2.5.0，我的體驗較差，SDK代碼集成度不是過高，大部分實現仍是用iOS原生API，官網已提供3.1.0版本SDK，集成度和極光類似度很高，3.1.0版本使用體驗很好，能爲用戶設置標籤進行組推送、帳號綁定實現用戶的單一推送，能實現康加App的推送需求。
收費狀況：
暫時沒有提供付費服務，提供無限量推送條數
（4）個推
個推iOS SDK爲應用提供推送服務，當應用在前臺時，維持與推送服務器的長鏈接，實時接收推送消息；當應用在後臺時，經過蘋果APNs推送通知。集成簡單快速。
一、能夠根據用戶屬性創建不一樣標籤，進行定向推送，也能夠進行A/B分組測試，從而進行精細化運營。
二、提供別名接口、靜默時間設置接口、推送控制接口，知足APP的各類需求。
三、個推SDK不只能提供雲端到客戶端的推送服務，也能夠提供從客戶端上傳至雲端的服務，即推送消息鏈路支持上下行雙向通道，開發者與客戶端之間互動更便利。
四、支持APNs 多媒體推送和通知的展現、點擊統計功能。
五、最新SDK還支持獨有的APNs 展現和點擊統計，有助於開發者掌握更精準的推送數據，優化運營效果。
我的集成使用體驗：SDK集成度介於極光和信鴿之間，略差於極光，實現了APNS推送和消息內通道，在方法回調處理上相比極光不是很優異，個推和極光、信鴿最大的區別是（App在前臺，推送會走應用內消息通道）。能爲用戶設置標籤進行組推送、別名實現用戶的單一推送，技術支持較好，反饋問題能獲得及時的解決。免費下暫不支持定時推送。
收費狀況：
個推提供VIP服務，和免費的主要區別在於用戶數限制、推送通道、定時推送、獨立推送通道等，詳情參考：http://www.getui.com/cn/getui.html
（5）雲巴推送
一、集成APNs
雲巴SDK 集成了APNs，開發者無需開發與APNs 對接的模塊，也沒必要本身負責Device Token 的更新，一切交給雲巴。
二、確保消息的送達
衆所周知，APNs 並不保證消息的送達。 而云巴SDK 支持 離線消息的功能，可保證消息送達客戶端。
在推送消息時，若是客戶端當前不在線，消息將暫存在雲巴服務器上（多達50 條，長達15 天）。 當客戶端上線併成功鏈接到雲巴的服務器後，服務器會把離線消息推送給該客戶端。客戶端成功接收後，服務器纔會刪除保存的離線消息。
我的集成使用體驗：SDK只能代碼集成，不能用cocoapods，下載的官方demo比較老舊，遠程通知收不到， 遠程通知只能作一個保存等進入前臺時再顯示出來。目前已反饋給雲巴技術，技術支持較差，在羣裏發送一天沒人迴應。技術文檔比較老舊，寫的較亂，找東西比較費勁。我的綜合體驗是這幾個推送體驗最差的一個。並且免費消息量有限制，對於用戶量趨於增大漸漸的會打到推送瓶頸。能設置頻道和別名進行指定推送。
收費狀況：
雲巴提供付費服務，與免費的差異主要是推送消息量、離線消息保存時間、傳輸速度，免費20次每秒，付費5000次每秒，詳情參考https://yunba.io/pricing/
四、各個方案優缺點分析
搭建推送服務：本身搭建推送服務，須要人力、技術、工做量、運營成本等，對我公司目前情況不適合考慮此方案。
極光推送：也是國內最先的移動推送平臺，一直是免費狀態，因爲其出色的推送體驗被大多開發者依賴。極光推送免費狀態下支持無限推送條數。
信鴿推送：是騰訊移動推送，2.5.0版本我的使用體驗不是很好，但新版本3.1.0版本體驗出色，能實現推送的需求。目前信鴿推送的條數也不受限制，免費權限很高。
個推：免費服務不支持定時推送。內部集成雙通道服務，App前臺使用個推服務消息，App後臺使用APNs推送，這樣在前臺收到消息無延時。
雲巴推送：體驗最糟糕的一個，官網技術文檔亂，技術支持差，推送條目有限制。
五、App推送建議
（1）公司App推送需求
從當前App需求功能角度分析，用戶打開App會以手機號或者惟一ID做爲推送別名，當用戶測量報告完成康加服務器調第三方API，向指定用戶推送報告信息，推送過程用戶可能在當前App（在前臺），或在桌面和其餘App等，在前臺時最佳推送是不經過APNs，優勢見消息內消息，在App後臺必須使用APNs推送。App推送還有一個需求是多少天沒有測量須要提醒用戶測量，既須要具有定時推送功能。
（2）幾種推送免費下作到程度
極光：無限推送條目、APNs推送通道、定時推送、（免費）不支持統計
信鴿：無限推送條目、APNs推送通道、定時推送、支持統計
個推：無限推送條目、兩種推送通道、（免費服務）不支持定時推送
雲巴：有限推送條目、兩種推送通道、不支持定時推送、註冊用戶數限制
綜合公司App推送需求：無限推送條目、定時推送是當前的基本需求，而實現這一點的有極光推送和信鴿。極光和信鴿都使用APNs推送通道。我的感受兩種均可以使用，都有很出色的體驗。信鴿支持免費統計功能，若是運營對統計要求的話信鴿更好些，極光是國內最先作第三方推送平臺的，通過這麼多版本的優化，不管是推送技術程度和使用體驗都是很優異的。
六、離線推送
（1）APNs離線推送
若是推送的時候deviceToken對應的機器在APNS服務器上是離線狀態，蘋果會保存推送信息「一段時間」。當機器恢復在線狀態時，推送信息到該機器。若是機器長時間不在線，蘋果會拋棄掉這條消息。這個「一段時間」沒有明文說多久，並且不知道蘋果在不一樣狀況下對這個時間有沒有動態調整，因此沒法推測這個時間對於信息丟失狀況的影響。
對於連續推送的狀況，針對離線設備，蘋果永遠只存儲最新的一條，上一條信息會被拋棄。
（1）極光非APNs離線推送（信鴿暫不支持非APNs離線推送）
對於Apple通知來講，斷網（斷開了與Apple服務器的鏈接），即爲離線。該狀態下，Apple服務器只會保存1 條消息，在聯網後發給手機。
對於應用內消息，有網，且處於前臺時纔是在線狀態（與極光服務器有鏈接），其餘均爲離線。該離線狀態下，極光服務器免費保存5 條離線消息，在線後發給手機。
參考資料：
https://docs.jiguang.cn/jpush/client/iOS/ios_sdk/#jpush-apns_1
https://redth.codes/the-problem-with-apples-push-notification-ser/
http://docs.developer.qq.com/xg/ios_access/ios-tui-song-fu-wu-jie-shao.html
https://www.jianshu.com/p/e9c313df746f