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