一、前言

本文要分享的是訊息推送是指手機APP被關倍訓者處于后臺時，還能收到訊息的能力，這種訊息已經廣泛應用在以下場景，

1. IM即時通信應用，比如微信切后臺了依然能收到訊息，
2. 新聞資訊應用，
3. 安防APP的報警應用，比如螢石APP切后臺后依然可以收到視頻報警訊息，
4. 等等其他應用，

二、原生訊息推送

目前移動端絕大部分都是基于兩套系統，安卓和IOS，兩者都有系統級的推送方式，IOS對應的是APNS，安卓對應的是FCM（之前是GCM，18年已廢棄），以APNS推送為例，訊息的推送鏈路圖2-1所示:移動端與APNS保持長連接，即使APP切后臺了，推送服務端可以將訊息推送到APNS服務器，APNS服務器再將訊息推送到手機端，這樣手機端不管裝多少個app，有多少個app在后臺，都只有一條長連接，但是卻能收到各種訊息，低功耗的同時也保障了功能性，

圖2-1 APNS訊息推送程序

三、國內訊息推送現狀

3.1 面臨的挑戰

IOS和安卓在國外利用系統原生的推送機制就能滿足需求（除了華為，由于貿易戰，近兩年部分華為手機在國外也不能使用FCM了），但是到了國內，手機訊息推送就受到了許多挑戰，

首先是IOS，如圖3-1所示，APNS服務器全部在國外，所以國內的服務器向APSN推送訊息的延時、帶寬等就會受到很大的限制，而安卓這邊就更慘了，由于眾所周知的原因，FCM在國內直接無法使用，

圖 3-1

3.2 解決方案

3.2.1 IOS

由于IOS的封閉性，不管什么樣的方案，都無法繞過APNS，所以IOS的推送方法相對比較純粹，主要有以下幾種，

1.推送服務直接與APNS通信

應用的推送服務直接將訊息推送到APNS，開發者自行對接APNS的API，

缺點是推送服務器如果跟APNS服務器之間的網路不暢，可能會有性能問題，不過對小型應用來講是夠用的，

2.推送服務建立與APNS的中間站點實作高速推送

當推送訊息比較多且頻率比較高的時候，簡單的推送服務器可能就難以滿足需求了，此時就需要擴展推送服務器，或者將推送服務器部署到境外，建立一條訊息高速通道，

缺點是成本比較高，開發成本、維護成本以及服務器成本都比較高，適合應用已經有穩定的盈利能力且對訊息推送要求較高的場景，比如微信這種IM應用，

3.使用第三方SDK

方案1需要直接與APNS通信，開發者需要考慮各種實作細節以及處理略顯復雜的網路環境，處理不好性能可能會有問題，方法2的性能較好，但是成本略高，

集成第三方SDK的話一般會簡化開發成本，拆箱即用，而且第三方服務一般會自建與APNS的高速通道，會比自己開發的推送性能更高一些，而且第三方服務一般還會提供一些有用的資料統計功能，比如訊息到達率、打開率等，有利于運營自己的應用，這種方案適用于應用剛生產時能夠快速迭代應用，或者對訊息推送的需求比較弱，不想花費太多成本在這些功能，

但是這種方案也有缺點：開箱即用意味著靈活性不佳，可能有一些特殊的推送需求無法滿足，而且第三方服務一般免費的服務會進行限流、限制部分功能等，而且一旦出了問題由于涉及到許多方面，比較難排查，隨著應用用戶量的增長和功能的迭代，將會與第三方服務產生系結，推送量一旦達到收費的閾值，成本會逐步增高，

3.2.2安卓

安卓系統比較開放，而且廠商也比較多，所以安卓的推送方案相對來說還是比較多樣的，

1.自建通道

雖然國內FCM不可用，但是由于安卓開放性比較高，所以在市場初期的時候許多APP選擇自建通道的方式來實作通信（這也是安卓初期續航不佳的原因之一），即：APP守護一個后臺服務push service，該服務始終與推送服務保持長連接，當有訊息推送過來時由有臺服務處理訊息并展示，這種方法不經過第三方服務，相當于只是簡單的客戶端與服務端的通信，訊息不經過第三方，安全的同時也更加自由靈活，

但是這種方案的缺點也是明顯的，首先是移動端常常是在弱網環境下，后臺服務與推送服務之間的心跳保活面臨很大的挑戰，然后是這種實作方法非常的耗電，用戶體驗不加，另外隨著安卓的權限控制越來越嚴格，而且用戶對后臺行程也越來越敏感，目前這種方法已經算是名存實亡了，

2.集成廠商通道

由于FCM在國內不可用，目前比較大的手機廠商如華為、小米、oppo、vivo、魅族等都自建了自己的推送通道，比如用戶用的是小米手機，那么一般使用小米推送就可以將訊息推送給用戶，其流程如下圖所示：

但是由于手機品牌比較多，意味著推送不同的手機需要走不同的推送通道，這會讓推送服務的設計變得復雜，其互動流程如下圖所示：

移動端開啟應用后，需要查詢本機的資訊并上報給服務端，當服務端需要給用戶推送訊息時，要查詢用戶使用的機器資訊，然后匹配到對應的推送通道，再向該通道推送訊息，由于各個廠商的API、證書、協議格式等不一樣，甚至同一家廠商不同手機型號之間也會存在差異，所以維護這一套推送機制還是比較復雜的，

3.使用第三方SDK

安卓推送使用第三方SDK的話可以很好地屏蔽掉不同廠商的差異，開發者只需要將各種廠商的認證資訊上傳到三方服務器的個人賬戶里即可，三方服務就會做好各個廠商的集成，開發者只需要關注業務本身，將訊息推送給三方服務，由三方服務根據用戶的特性走不同的推送通道，可以大大地減少開發成本，

當然是用三方SDK也會存在一些缺點，已經在IOS推送的章節中做了討論，此處不再贅述，

4、基于傳統SMS通道完成推送

這種方法是在有離線訊息的時候發送一條短信給用戶，APP在后臺攔截并決議短信內容，這種方式隨著安卓權限控制越來越嚴格，實際上也是名存實亡，但是統一推送聯盟基于運營商通道進行離線訊息推送，跟這種方法有著異曲同工之妙，

5、

四、第三方SDK原理

目前做的比較好的手機推送三方SDK的廠商有極光推送、友盟推送、個推、騰訊信鴿等等許多家，各家的實作細節和功能存在小的差異，但整體上原理是大差不差的，

根據上一章節的分析，第三方SDK的原理不言而明：主要就是集成了各種推送通道，然后向用戶提供統一的推送介面，從而屏蔽不同廠商的差異性，第三方SDK不僅僅做到了這些，而且還可以進行統一的認證資訊管理、推送資料分析等增值服務，可以說是對開發者非常友好了，

除了集成各種推送通道外，三方SDK服務還會自建通道，自建通道的原理前文已有介紹，但是三方服務做自建通道相比應用開發者自己做的自建通道還是有一定優勢的，原因在于自建通道在多個應用之間可以貢獻，比如應用A、B、C都集成了某三方的自建通道，此時即使B和C都被強殺了，只要A的通道還處于活躍狀態，那么B和C的訊息依然可以通過該通道推送到手機上，這樣當同一個手機安裝了多個APP都集成了某一通道時，通道保活的概率就大大增強了，

五、訊息推送系統技術選型

前面分析了各種推送方案的原理和優缺點后，技術選型也就比較明朗了，

如果產品初期比較趕工急于實作各種功能，那么選擇一個靠譜的第三方SDK可以大大地減少作業量，如果產品一開始就立志高遠想成為微信這樣的巨無霸，不想隨著推送量增長而修改方案，那么就一步到位直接自己做集成，還有一種情況是推送量雖然不大，但是推送的訊息非常重要，對于安全性要求較高，此時也需要自行集成各種通道來避免資訊泄露，

總而言之，技術選項就是成本與收益的平衡，沒有那種方案能夠適合所有場景，選擇適合自己產品的方案最重要，

六、參考實作方案

當產品越做越大，甚至同一家公司會有多個產品，一個產品有多個版本，都需要用到手機推送業務，如果每個應用都重新設計、實作各種推送細節，就太浪費成本了，所以業界一般會開發一個統一的訊息推送中間件，專注于訊息推送，為各種業務提供服務，讓業務與訊息推送解耦，各自專注在自己的核心業務上，

常見的推送服務具有以下特點：

【1】多點接入，可以同時接入多加第三方推送服務，多家廠商推送服務，

【2】服務端提供統一的推送介面，客戶端提供統一的SDK，業務端只需要呼叫統一的介面即可實作推送功能，推送服務在內部根據發來的訊息做具體的推送邏輯，

【3】訊息持久化，方便追溯和查看，

【4】有失敗重傳機制，提高訊息達到率，

【5】提供資料分析功能，可以分析推送的到達率，打開率等資料，方便運營和優化，

【6】提供推送配置平臺，多種SDK，多種廠商，多種APP的認證資訊可以統一管理，

參考的架構如下圖所示:

移動推送平臺提供統一的服務，對于應用層屏蔽推送服務介面，且實作推送服務可動態輪替，推送平臺將接收到的訊息持久化到資料庫中，方便進行訊息推送失敗后的重發，以及后續資料的統計分析，
客戶端 SDK 對 App 提供統一的使用介面，屏蔽推送服務 SDK 使用細節，且實作多種推送 SDK 可替換，隱藏 SDK 復雜的接入程序，方便使用，
應用管理系統面向 App 開發人員，實作應用申請，推送服務配置，訊息查詢與管理，資料統計與分析，

七、展望未來

2018年，有政府背景的“統一推送聯盟”成立了，致力于統一目前國內混亂的安卓推送現狀，將各個廠商聯合起來制定統一的標準規范，統一推送聯盟由工信部牽頭成立，主辦方為工信部旗下的中國資訊通信研究院泰爾終端實驗室，也許在不久的將來，開發者不再為了各種不同的推送API而犯難了，

八、參考資料

【1】2021年了統一推送聯盟爛尾了嗎？

【2】使用Pushy進行APNs訊息推送

【3】58同城高性能移動端訊息推送技術架構演進之路

【4】喜馬拉雅億級用戶量的離線訊息推送系統架構設計實踐

【5】iOS的推送服務APNs詳解：設計思路、技術原理及缺陷等

【6】實踐分享：如何構建一套高可用的移動端訊息推送系統？

【7】統一推送聯盟：OPPO 完成“推必達”能力適配