1、APNS介紹（原生推送實現原理）
在iOS平台上，大部分應用是不允許在后台運行並連接網絡的。在應用沒有被運行的時候，只能通過 Apple Push Notification Service (APNs) 把數據發送到終端用戶。對於互聯網應用，正確高效的使用APNs 顯然非常重要。
Apple為應用開發者提供了一個APNS推送接口，稱為binary interface。
（1）Binary Interface V1
最初版本的binary interface 協議如下圖，這里我們稱之為v1。
v1 協議有幾個問題：
1、消息是否發送成功沒有明確的反饋；
2、如果一個消息發送失敗，比如因為deviceToken 不合法，APNs 會在大約500ms 后斷掉鏈接，在斷鏈前發送的消息也會發送失敗；
3、經驗證，feedback service 只有報告應用被卸載后，造成deviceToken 失效的錯誤。而不會報告deviceToken 不合法這種類型的推送錯誤。
也就是說如果我們給一批用戶發消息，只要有一個deviceToken 不合法，將會有可能造成若干個用戶收不到消息。並且沒辦法確認哪些deviceToken不合法，哪些deviceToken 需要被重發。這應該是APNs 丟消息的一個重要的原因。
（2）Binary Interface V2
經過開發者不斷的向Apple 反饋這個問題，Apple 終於推出了一個新版本的binary interface，稱為enhanced binary interface，我們稱這為v2。
我們發現，在v1 的基礎上增加了兩個字段：
Identifier一個任意的值，用於一條消息的識別。如果發送出現問題，錯誤應答里會把Identifier 帶回來。
Expiry離線消息超時的時間，如果為0或者小於0，APNs 不會保存這條消息。
和v1 一樣，如果消息發送沒有問題，APNs 不會有任何返回。和v1 不同，並且很重要的改進是，如果發送出現錯誤，v2 會在斷鏈之前返回一個錯誤應答，帶上發消息時的Identifier 和一個錯誤碼。
根據這個錯誤應答，我們有機會找到是哪條消息發送出錯，並確定哪些消息需要被重發。
2、應用內消息和推送的區別
應用內消息（以下簡稱消息）和推送通知的區別，消息：不需要Apple 推送證書。由第三方的服務器下發，而不是APNs。相比通知，更快速，幾乎沒有延遲，可用於IM 消息的即時送達。能夠長時間保留離線消息，可獲取所有歷史消息內容。
通過長連接技術下發消息，因此：手機必須啟動並與第三方服務器建立連接。
如果手機啟動立刻切至后台，很可能連接沒有建立。手機必須處於前台才能收到消息。手機從后台切回前台，會自動重新建立連接，並收到離線消息。
沒有任何展示（橫幅、通知中心、角標、聲音），因此可以：自定義字段實現UI 效果。完全在靜默情況下處理App 內部邏輯。
應用內消息在App離線下，接收到應用內消息，把消息緩存到服務器，當App在線時和服務器建立長連接，服務器再把所有緩存的離線消息一起推給App，這是目前iOS聊天類App實現的方案。第三方服務提供的免費資源一般里面緩存條目是有限制的（極光緩存5條）。
3、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 推送有什么好處？
減少開發及維護成本：
1、應用開發者不需要去開發維護自己的推送服務器與APNs 對接。
2、集成了JPush iOS SDK 后不必自己維護更新device token。
3、通過JPush 的Web Portal 直接推送，也可以調用JPush的HTTP 協議API 來完成，開發工作量大大減少。
減少運營成本：
1、極光推送支持一次推送，同時向Android, iOS, WinPhone 三個平台。支持統一的API 與推送界面。
2、極光推送提供標簽、別名綁定機制，以及提供了非常細分的用戶分群方式，運營起來非常簡單、直觀。
提供應用內推送：
1、除了使得APNs 推送更簡單，也另外提供應用內消息推送。這在類似於聊天的場景里很有必要。
個人集成使用體驗：集成相對簡單，SDK集成度高，推送體驗效果優異，很少出現延時情況，唯一的缺點是免費版本沒有做離線點擊通知做統計，可以為用戶設置標簽進行組推送、別名實現用戶的單一推送，支持定時推送，能實現康加App推送需要的所有功能。
收費情況：
提供VIP服務，免費和VIP差別在最大並發數、專享高速推送通道、離線保存消息時間、消息送達統計等，詳情見https://www.jiguang.cn/push-price
（3）信鴿推送
信鴿是深圳市騰訊計算機系統有限公司推出的一款專業的免費移動消息推送營銷平台。針對iOS設備的消息推送，信鴿平台目前只借助APNs通道，暫不支持應用內自有通道的消息下發。
1、設備Token的自動化獲取和注冊，降低接入門檻。
2、賬號、標簽與設備的綁定接口，以便開發者實現特定群組的消息推送，豐富推送方式。
3、點擊量上報，統計消息被用戶點擊的次數。
個人集成使用體驗：官網目前主要版本是2.5.0，個人體驗較差，SDK代碼集成度不是太高，大部分實現還是用iOS原生API，官網已提供3.1.0版本SDK，集成度和極光相似度很高，3.1.0版本使用體驗很好，能為用戶設置標簽進行組推送、賬號綁定實現用戶的單一推送，能實現康加App的推送需求。
收費情況：
暫時沒有提供付費服務，提供無限量推送條數
（4）個推
個推iOS SDK為應用提供推送服務，當應用在前台時，維持與推送服務器的長連接，實時接收推送消息；當應用在后台時，通過蘋果APNs推送通知。集成簡單快速。
1、可以根據用戶屬性建立不同標簽，進行定向推送，也可以進行A/B分組測試，從而進行精細化運營。
2、提供別名接口、靜默時間設置接口、推送控制接口，滿足APP的各種需求。
3、個推SDK不僅能提供雲端到客戶端的推送服務，也可以提供從客戶端上傳至雲端的服務，即推送消息鏈路支持上下行雙向通道，開發者與客戶端之間互動更便利。
4、支持APNs 多媒體推送和通知的展示、點擊統計功能。
5、最新SDK還支持獨有的APNs 展示和點擊統計，有助於開發者掌握更精准的推送數據，優化運營效果。
個人集成使用體驗：SDK集成度介於極光和信鴿之間，略差於極光，實現了APNS推送和消息內通道，在方法回調處理上相比極光不是很優異，個推和極光、信鴿最大的區別是（App在前台，推送會走應用內消息通道）。能為用戶設置標簽進行組推送、別名實現用戶的單一推送，技術支持較好，反饋問題能得到及時的解決。免費下暫不支持定時推送。
收費情況：
個推提供VIP服務，和免費的主要區別在於用戶數限制、推送通道、定時推送、獨立推送通道等，詳情參考：http://www.getui.com/cn/getui.html
（5）雲巴推送
1、集成APNs
雲巴SDK 集成了APNs，開發者無需開發與APNs 對接的模塊，也不必自己負責Device Token 的更新，一切交給雲巴。
2、確保消息的送達
眾所周知，APNs 並不保證消息的送達。 而雲巴SDK 支持 離線消息的功能，可保證消息送達客戶端。
在推送消息時，如果客戶端當前不在線，消息將暫存在雲巴服務器上（多達50 條，長達15 天）。 當客戶端上線並成功連接到雲巴的服務器后，服務器會把離線消息推送給該客戶端。客戶端成功接收后，服務器才會刪除保存的離線消息。
個人集成使用體驗：SDK只能代碼集成，不能用cocoapods，下載的官方demo比較老舊，遠程通知收不到， 遠程通知只能做一個保存等進入前台時再顯示出來。目前已反饋給雲巴技術，技術支持較差，在群里發送一天沒人回應。技術文檔比較老舊，寫的較亂，找東西比較費勁。個人綜合體驗是這幾個推送體驗最差的一個。而且免費消息量有限制，對於用戶量趨於增大漸漸的會打到推送瓶頸。能設置頻道和別名進行指定推送。
收費情況：
雲巴提供付費服務，與免費的差別主要是推送消息量、離線消息保存時間、傳輸速度，免費20次每秒，付費5000次每秒，詳情參考https://yunba.io/pricing/
4、各個方案優缺點分析
搭建推送服務：自己搭建推送服務，需要人力、技術、工作量、運營成本等，對我公司目前狀況不適合考慮此方案。
極光推送：也是國內最早的移動推送平台，一直是免費狀態，由於其出色的推送體驗被大多開發者依賴。極光推送免費狀態下支持無限推送條數。
信鴿推送：是騰訊移動推送，2.5.0版本個人使用體驗不是很好，但新版本3.1.0版本體驗出色，能實現推送的需求。目前信鴿推送的條數也不受限制，免費權限很高。
個推：免費服務不支持定時推送。內部集成雙通道服務，App前台使用個推服務消息，App后台使用APNs推送，這樣在前台收到消息無延時。
雲巴推送：體驗最糟糕的一個，官網技術文檔亂，技術支持差，推送條目有限制。
5、App推送建議
（1）公司App推送需求
從當前App需求功能角度分析，用戶打開App會以手機號或者唯一ID作為推送別名，當用戶測量報告完成康加服務器調第三方API，向指定用戶推送報告信息，推送過程用戶可能在當前App（在前台），或在桌面和其他App等，在前台時最佳推送是不通過APNs，優點見消息內消息，在App后台必須使用APNs推送。App推送還有一個需求是多少天沒有測量需要提醒用戶測量，既需要具備定時推送功能。
（2）幾種推送免費下做到程度
極光：無限推送條目、APNs推送通道、定時推送、（免費）不支持統計
信鴿：無限推送條目、APNs推送通道、定時推送、支持統計
個推：無限推送條目、兩種推送通道、（免費服務）不支持定時推送
雲巴：有限推送條目、兩種推送通道、不支持定時推送、注冊用戶數限制
綜合公司App推送需求：無限推送條目、定時推送是當前的基本需求，而實現這一點的有極光推送和信鴿。極光和信鴿都使用APNs推送通道。個人感覺兩種都可以使用，都有很出色的體驗。信鴿支持免費統計功能，如果運營對統計要求的話信鴿更好些，極光是國內最早做第三方推送平台的，經過這么多版本的優化，無論是推送技術程度和使用體驗都是很優異的。
6、離線推送
（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
https://www.cnblogs.com/r360/p/5741136.html