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