移动端推送系统
也是綜合了網上部分推送系統總結的如下,感謝其他網友的分享
1 自建推送系統
主要針對服務器和ING終端升級和消息推送;服務器主動向手機推送消息的應用。需要Beacon幀數據鏈路的維護,此鏈路也可以預留為日志的傳輸通道。
| ? | GCM | XMPP | MQTT | HTTP輪循 | comet | Websocket |
| 優點 | Google提供的服務、原生、簡單,無需實現和部署服務端 | 協議成熟、強大、可擴展性強、有開源的Java版的開發實例androidpn。 | 協議簡潔、小巧、可擴展性強、省流量、省電 | 實現簡單、可控性強,部署硬件成本低 | 實時性好(消息延時小);性能好(能支持大量用戶) | 互相溝通的Header是很小的-大概只有 2 Bytes,帶寬效率較高 |
| 缺點 | 該服務在國內不夠穩定、需要用戶綁定Google帳號,受限于Google | 協議較復雜、冗余(基于XML)、費流量、費電,部署硬件成本高 | 低帶寬、不可靠的網絡的遠程傳感器和控制設備通訊而設計的 | 實時性差,請求中有大半是無用,浪費帶寬和服務器資源 | 服務器hold連接會消耗資源,返回數據順序無保證,難于管理維護 | 少部分瀏覽器不支持,瀏覽器支持的程度與方式有區別(不屬于本文討論的范疇) |
常用的服務器消息推送方式
注:使用GCM服務(Google Cloud Messaging)
上表中看出websocket進行消息推送成本相對較小,性價比相對較高;其他方案TCP長連接, 客戶端主動和服務器建立TCP長連接之后, 客戶端定期向服務器發送心跳包, 有消息的時候, 服務器直接通過這個已經建立好的TCP連接通知客戶端(微信,Line,WhateApp有采用這種方式)。
TCP屬于私有協議,建議采用websocket公有協議。由于長連接的維護很耗費資源,手機端采用每天通過Http去服務器Get一次,ING終端的當前版本信息。
XMPP叫做Serverless Messaging無服務器消息:當選擇基于“服務器”的消息模型,存在負載和負載的優點(聯系人列表管理,實體發現,存在授權,離線消息等),但如果采用“Serverless”的P2P客戶端做這些功能,鏈路可能會丟失或性能不佳,因為需要客戶端自己維護工作上面的工作;通常超過70%的XMPP協議的服務器的數據流量的存在和近60%的被重復轉發,XMPP協議目前擁有一個大型架空中存在的數據提供給多個收件人,在移動手機推送中并不是最佳選擇。WebSocket不是基于Serverless Messaging/P2P模型設計,而是基于通過無狀態的HTTP協議實現的推送,簡而言之,是替代hacky comet,長輪詢,分塊編碼,jsonp,基于iframe以及其他通過http實現模擬服務器推送的技術。XMPP(即P2P模式)比較適合終端較強的算法功能的場景,Websocket模式較為輕量級。
2 第三方推送系統
端外推送我們必須依賴第三方的推送平臺,在iOS上我們只用使用APNs就行了。而在Android上,跟APNS對應的服務是谷歌的GCM(Google Cloud Messaging),但很可惜它在國內的可用性不高(主要原因是手機廠商對Android系統的定制化,可能會將GCM服務裁減掉,以及國內運營商的一些限制)。如果我們做的是一個海外的應用,那么端外推送基本只用考慮GCM就可以了。
推送平臺大體可以分為三大類:
第A類:專業的第三方推送:友盟推送、個推、極光推送
第B類:大手機廠商的推送:小米推送、華為推送,OPPO,魅族。
第C類:BAT大廠平臺推送:阿里云移動推送、騰訊信鴿推送、百度云推送。
針對A類專業的第三方推送:最近主流的 Android 手機都會清理后臺服務,禁止服務自動拉起,以前第三方推送服務商的各種 SDK 保活手段相繼失效,這個問題從根本上動搖了 Android 第三方推送服務的基礎,導致幾乎所有的 Android 第三方推送服務都不能保證送達。所以極光推送,友盟推送等可靠性在第三方手機上很難保證。A類第三方推送優勢:有“保活”和“互拉”的能力。舉個例子,假設你接入了友盟,而恰好今日頭條也接入了友盟。有一天你的App被殺死了,但是今日頭條的裝機量估計比你的要大啊,這時用戶啟動了今日頭條,那么推送系統也就會通過共享的推送通道順便把你推送消息送達到手機上,然后還可能把你的進程也喚醒(被“保活”了),所以,風險性不可控。
針對B類手機廠商的推送,他們的推送服務在他們自己生產的手機上屬于系統級別的服務,理論上來說,手機系統對他們自家的推送限制最小。比如,在小米手機上,不在系統自啟動名單里的App,在手機重啟后,App聲明的后臺Service并不會自動運行。但是,小米推送作為手機系統級服務,仍然是可以收到推送的。但華為手機上:正對不同的Emui系統的Push廣播有不同程度的限制,華為推送自己也不太完全能搞得定的。
針對C類BAT大廠優勢:各家的“全家桶”采用的“保活”陣營和推送通道,跟他們開放出來的是兩碼事。比如,用騰訊信鴿推送,不一定能占上微信的光。騰訊新聞使用的小米推送,它沒有使用自己家的信鴿推送;淘寶使用的是小米推送(Google Play上的版本應該應該是 GCM)。百度視頻和愛奇藝使用的是小米推送,沒有用自家的百度推送。
結論:Android通常需要同時集成多家推送平臺:“端內+端外”推送。但由于App進程由于被清理或者其它原因,這時只能走某個第三方端外推送平臺。
總結
- 上一篇: 区块链日报@2019.1.16
- 下一篇: 高并发软件系统的密码