蘋果推送的原理
- app 向APNS發請求獲取 device-token（是由APNs頒發的）
- APP 向Client 服務器注冊當前用戶的device-token（說明用戶與device-token 映射關系）
- client 服務器向 APNS服務器發消息（device-token + Payload）.
- APNS 根據 device-token 將消息傳遞給手機，手機在根據bundle ID 傳遞給對應app.
蘋果推送的過程
此圖描述了真實消息推送的過程
App開發者或者第三方推送平臺的服務器(圖例中的Provider)向APNs發起推送指令的請求，推送指令包含了要下發設備的device-token和要下發的內容payload兩部分。
由APNs根據device-token(device-token是APNs生成頒發的)將payload下發到設備上，再由設備路由給具體的App。
APNs要求Provider首先與APNs建立一條長連接，Provider通過長連接可以將單個或者一批device-token發送給APNs，這個過程中，只要有一個device-token是不合法的(錯誤或者失效)，那么APNs就會主動斷掉Provider到APNs的長連接.
Provider探測到連接斷掉之后，需要重新建立連接，跳過上次失敗的device-token，從下一個device-token接著發送。這個過程循環往復，直至將本次要發送的所有的device-token都推送到APNs，那么這次推送任務就算完成了。
剩下的工作就是APNs將消息下發到具體設備了，APNs將消息下發給設備這個過程，不管是App開發者直接和APNs打交道、亦或是第三方推送服務器和APNs打交道，我們都是無法控制的了.
為什么隔了很久之后再去做推送，發送過程會變得非常慢
- 因為長時間不發送的話，會有很多設備上的device-token已經無效了，比如:設備卸載了App，或者系統版本升級過導致device-token變化了，或者是其它導致APNs認為device-token不合法的原因?？傊?，時間長了，不合法的device-token就會變多。
- 那么既然失效的device-token是導致發送變慢的主要原因，那么開發者朋友們肯定會想，能不能提前判斷出失效的device-token，直接從發送列表中剔除掉這些失效的token。
- 其實APNs是提供這樣的feedback接口的，調用這個接口會得到一批失效的device-token列表。那么是不是在一次發送之前去調用一下這個接口，獲取到無效的device-token，在發送的過程中剔除掉這些無效的device-token就能加快發送速度呢？
- 其實不然，因為feedback接口是一個后驗的接口，即只有一次推送任務結束之后，APNs才會把該次失效的device-token更新到feedback接口的返回結果里面。
- 如果你在一次推送任務前調用feedback接口，那么得到的失效device-token是基于上一次推送任務的結果的，兩次推送任務之間發生的失效的device-token，是無法提前獲取到的，只能等當次推送任務結束之后，才可以去獲取新的失效token列表。
原文參考品：https://www.zhihu.com/question/33888020/answer/59658011
iOS和Android后臺實時消息推送的原理和區別
iOS的實時消息推送
iOS 系統的推送（APNS）依托一個或幾個系統常駐進程運作，是全局的（接管所有應用的消息推送），所以可看作是獨立于應用之外，而且是設備和蘋果服務器之間的通訊，而非應用的提供商服務器。
你的例子里面，騰訊 QQ 的服務器（Provider）會給蘋果公司對應的服務器（APNs）發出通知，然后再中轉傳送到你的設備（Devices）之上。當你接收到通知，打開應用，才開始從騰訊服務器接收數據，跟你之前看到通知里內容一樣，但卻是經由兩個不同的通道而來。
- Android的實時消息推送
而 Android，就不同，更像是傳統桌面電腦系統做法。每個需要后臺推送的應用有各自的單獨后臺進程，才能和各自的服務器通訊，交換數據。另外其實 Android 也有類似 APNS 的 GCM（Google Cloud Message），屬于開發者可選，非強制。
Android實時消息推送
