在移動互聯網時代，為了運營好一個APP，消息推送是一個優質廉價的渠道。消息推送的使用場景簡單來說，可以包括運營類的消息推送，如活動推廣期間的推送等，還包括通知類的消息推送，如社交場景中的新消息提醒等。 對於APP來說，消息推送能夠起到內容告知、提高日活，甚至召回用戶的作用。那么如何接入第三方推送平台呢？本篇文章中，網易雲信資深研發工程師將和大家聊聊接入各種第三方推送平台的技術方案，分享接入推送平台的一些實用經驗。 如何接入第三方推送
- 推送的一般流程
推送是一種服務器主動push消息到設備端的行為，因此依賴於設備端和服務器的長連接。整體的架構和流程如下：
具體如下：
- 設備和推送服務器建立長連接
- 設備會根據某些規則生成或從推送服務器獲取到一個DeviceToken，推送服務器可以根據DeviceToken定位到具體的設備
- 設備會上報DeviceToken到應用服務器（由應用自己完成）
- 應用服務器根據需要調用推送的服務端接口發起推送
- 推送服務器收到推送請求，根據請求中的DeviceToken定位到具體的設備，下發推送通知
- 設備收到推送消息，可以進行通知欄彈窗或者其他行為
- IOS
蘋果官方提供了APNS推送，有很高的推送送達率。早先的APNS推送提供了一套基於TCP協議的接口，但是該接口使用方式比較復雜，稍有不慎就會導致推送失敗，但調用方還誤以為推送成功。 后來蘋果又提供了一套新的基於HTTP2協議的接口，新接口的一個好處是可以追蹤到每個推送請求是被APNS服務器拒絕了還是成功了，再也不用去猜請求到底是被蘋果服務器給丟了還是接受了。
- 安卓
谷歌官方最早提供了GCM推送，后來又推出了FCM推送來代替GCM，但由於國內的環境不適合使用，因此各個手機廠商又相繼推出了各自的推送，推送的原理都是類似的，都是依賴於設備和推送服務器的長連接，但是廠商推送的優勢在於這樣的長連接可以和自己的手機系統綁定到一起，從而可以不同應用共享同一條長連接，節省了心跳的流量消耗，並且這樣的系統級長連接可以不用擔心應用被殺導致的應用內長連接斷連導致消息推送不可達。 目前已經推出廠商推送的包括小米、華為、魅族、OPPO等，FCM也可以算安裝了谷歌服務的設備的系統級推送。 不同於IOS，安卓陣營的推送服務器接口都是HTTPS接口，並且通過SecretKey的方式來進行安全校驗。 一點經驗
- DeviceToken的管理
我們知道DeviceToken標識了一台具體的設備，但是推送服務本身是不知道應用本身的賬號體系的，因此同一個APP，假設注銷了A賬號，改用B賬號登錄，此時DeviceToken一般來說是沒有變化的，此時應用服務器需要去標識A賬號的該設備屬於注銷狀態，不然一條針對A賬號的推送消息就會被B賬號收到。
- 應用被卸載的情況
應用被卸載的時候（這時候登錄的A賬號），應用本身感知不到，此時針對A賬號的該設備的推送還是會發出去，推送服務器收到推送消息，找不到對應的設備，此時沒有問題，只是會消耗一些資源。假設此時設備上的應用又重新安裝了，然后登錄了另一個賬號B，假設DeviceToken沒有變化，此時針對A賬號的推送將會被B賬號收到。上面這種情況出現的前提條件是DeviceToken沒有發生變化，測試發現華為推送存在這個問題（經過詢問華為推送技術支持，2018年3月之后的設備不存在該問題），其他推送沒有。為了解決這個問題，服務器必須自己管理DeviceToken-用戶賬號的映射關系，並在發現有DeviceToken沖突的情況下去把老的賬號設置為注銷狀態。
- IM場景下推送時機問題
IM場景下，應用服務器有自己長連接服務，此時第三方推送服務的作用是利用第三方廠商推送的系統級長連接來提高消息推送的送達率。 首先對於IOS端，應用無法常駐后台，我們會在應用切換前后台的時候通過IM長連接發送一個標記位，服務器會在設備離線或者處於后台的情況下觸發APNS推送，從而減少設備在前台情況下APNS推送的流量消耗。 而對於安卓端，服務器會在設備處於離線的情況下觸發第三方推送，否則會走IM長連接下發通知，當設備處於后台但還活着的時候，會在收到消息之后主動彈窗以便提醒用戶有新消息。對於安卓端還有一個場景是這樣的，安卓端在后台的某個時刻進程死了，此時過來一條需要推送的消息，服務器發現設備處於離線狀態，嘗試調用第三方推送（可能有也可能沒有）。過了一會進程自己活回來了，重新連接到了IM服務器，拿到了未讀消息，此時一般的邏輯下，進程會主動彈窗告知有消息到達，造成設備端的通知欄有兩條推送。為了解決這個問題，需要IM服務器在設備重連的時候下發未讀消息是否需要彈窗的信息。