Android消息推送機(jī)制研究
1.基于HTTP協(xié)議的推送機(jī)制
基于HTTP協(xié)議的推送機(jī)制是一種請求-響應(yīng)模式,由于HTTP協(xié)議是應(yīng)用層的單工通信模式,因此它很難實現(xiàn)真正意義上的即時推送。用HTTP協(xié)議實現(xiàn)推送有以下兩種方式.
(1)定期輪詢:
這種方式是使客戶端每隔固定時間向服務(wù)器端以post方式發(fā)出HTTP請求。在一次請求的開始,客戶端詢問服務(wù)器是否存在需要推送的消息,服務(wù)器端收到請求并處理,隨后向客戶端響應(yīng)處理結(jié)果,這樣一次請求就結(jié)束了。一段固定時間后,客戶端將再次向服務(wù)器端發(fā)出詢問請求并等待服務(wù)器端的返回結(jié)果。
(2)長輪詢:
這種方式是服務(wù)器端在接收到客戶端向其發(fā)出的請求時將請求掛起,直到該連接請求出現(xiàn)異常、超時、或者需要推送消息時再處理該請求,并向客戶端返回響應(yīng),客戶端接收到響應(yīng)后會立即再向服務(wù)器端請求連接。這樣就使得服務(wù)器與客戶端之間的連接始終未中斷,比客戶端定期輪詢的方式具有更好的實時性。
基于HTTP協(xié)議的推送機(jī)制實際上并不是真正的推送,而是依賴客戶端請求-服務(wù)器端響應(yīng)的模式。雖然該機(jī)制的實現(xiàn)簡單快速且可控性強(qiáng),但推送具有延遲性,實時性差。另外,雖然其中長輪詢形式的推送具有一定的實時性,但是服務(wù)器端需要管理大量掛起的請求,會造成服務(wù)器端資源消耗,同時由于HTTP協(xié)議是無狀態(tài)的,服務(wù)器端不能監(jiān)控客戶端的在線離線狀態(tài),因此就不能判斷推送的消息能否達(dá)到客戶端。
2.基于C2DM的推送機(jī)制
C2DM (Cloud to Device Messaging)服務(wù)是Google公司提供的移動終端消息推送服務(wù)。開發(fā)者可以將該服務(wù)引入自己開發(fā)的應(yīng)用程序中,服務(wù)器端推送給客戶端的消息是經(jīng)過C2DM服務(wù)器推送的,客戶端也可以直接與服務(wù)器通信獲取信息。其中C2DM服務(wù)器類似與推送消息的中間轉(zhuǎn)發(fā)者,負(fù)責(zé)處理用戶權(quán)限、消息隊列等事務(wù)并向指定客戶端轉(zhuǎn)發(fā)由服務(wù)器推送的消息。具體使用機(jī)制如下圖所示。
(1)客戶端首先將應(yīng)用名和賬號發(fā)送給C2DM服務(wù)器進(jìn)行注冊,注冊成功后客戶端會收到并存儲C2DM返回的注冊標(biāo)識。
(2)客戶端向自己的服務(wù)器發(fā)送該標(biāo)識和注冊成功的賬號,使得服務(wù)器能使用標(biāo)識和賬號向C2DM請求消息推送。
(3)當(dāng)服務(wù)器需要向客戶端發(fā)送數(shù)據(jù)時,獲取該客戶端注冊使用C2DM功能的用戶賬號的登陸權(quán)限。
(4)服務(wù)器把要發(fā)送的消息、客戶端注冊標(biāo)識、賬號登陸權(quán)限一并發(fā)送給C2DM服務(wù)器。
(5) C2DM服務(wù)器會把收到的消息推送給相應(yīng)的客戶端。
由于其為Google公司提供的原生服務(wù),因此無需實現(xiàn)和部署服務(wù)端。然而,正因為其原生性,使其需要用戶綁定Google帳號,同時由于該推送機(jī)制依賴于Google官方提供的C2DM服務(wù)器(服務(wù)器在國外),使得該服務(wù)在國內(nèi)不夠穩(wěn)定,常常無法提供服務(wù)。另外,國內(nèi)部分手機(jī)廠商,例如中興、華為等可能會去掉Google的這種原生服務(wù),樣推送功能將不能使用。
3.基于MQTT協(xié)議的推送機(jī)制
MQTT (Message Queuing Telemetry Transport)是由 IBM 在 2001 年發(fā)布的輕量級的消息傳輸協(xié)議,支持可發(fā)布/可訂閱的消息推送模式。協(xié)議的輕量級使它十分適合在用在資源受限的環(huán)境該協(xié)議最初是為物聯(lián)網(wǎng)設(shè)計的,現(xiàn)在也可用來實現(xiàn)消息推送。推送機(jī)制的實現(xiàn)主要依靠一個實現(xiàn)了MQTT協(xié)議的代理服務(wù)器,客戶端首先連接代理服務(wù)器,然后進(jìn)行消息訂閱,同時,客戶端也可向服務(wù)器發(fā)布消息,其他客戶端訂閱后也可接收這些消息,因此消息也可在客戶端之間傳輸。該推送機(jī)制中代理服務(wù)器一般是采用IBM的MQTT服務(wù)器RSMB(Really Small Message Broker),客戶端一般是采用 IBM 的提供的 wmqtt.jar 包。
MQTT協(xié)議是基于代理的“發(fā)布/訂閱”模式的消息傳輸協(xié)議。由于該協(xié)議簡潔、小巧、可擴(kuò)展性強(qiáng)的優(yōu)點(diǎn),使得基于該協(xié)議的推送機(jī)制較省流量和省電,目前已有C++語言編寫的服務(wù)端組件RSMB。然而由于基于MQTT協(xié)議的推送機(jī)制實現(xiàn)較復(fù)雜,目前這種機(jī)制還不夠成熟。另外,由于服務(wù)器端組件RSMB不開源,也使得在之上的二次開發(fā)很困難。
4.基于第三方的推送機(jī)制
第三方推送平臺有百度云推送、極光推送、_蝶推送、個推等。這些平臺是面向個人幵發(fā)者或者企業(yè)幵發(fā)者的,它們一般是按需收費(fèi)的,能提供多樣化的推送。以百度云推送為例,它支持推送文字和富媒體,支持向單用戶和群組用廣的推送等。開發(fā)者開發(fā)過程中需要在將第三方平臺的SDK集成到客戶端,這樣,服務(wù)器端推送消息吋調(diào)用第三方服務(wù)器的接口,就可以實現(xiàn)推送消息至客戶端。
第三方推送最大的優(yōu)點(diǎn)是支持多種格式數(shù)據(jù)的推送和超高并發(fā)連接數(shù),然而他們也存在缺陷,例如極光推送使用的自定義的二進(jìn)制協(xié)議,不支持推送信息的加密和身份認(rèn)證,百度云的加密推送需要額外付費(fèi)等。另外,采用第三方企業(yè)的SDK有程序嵌入的顧慮,存在風(fēng)險。
5.基于XMPP協(xié)議的推送機(jī)制
基于XMPP協(xié)議的消息推送機(jī)制繼承了 XMPP協(xié)議的優(yōu)點(diǎn),具備很強(qiáng)的靈活性和可擴(kuò)展性,并且將復(fù)雜性從客戶端轉(zhuǎn)移到服務(wù)器端。H前基于該協(xié)議己有比較成熟的推送框架,最著名的服務(wù)器端推送框架是Openfire,其采用Java開發(fā),安裝、配置和使用都十分容易,并利用Web平臺進(jìn)行管理,基于Openfire能夠輕松進(jìn)行二次開發(fā)并實現(xiàn)個性化的推送功能。而客戶端框架是Spark包,它完整的實現(xiàn)了 XMPP協(xié)議的幵源API庫,同時,為適應(yīng)Android運(yùn)行環(huán)境,該包還存在android平臺上的構(gòu)建版本Spark。另外,H前基于XMPP協(xié)議還存在另一個推送機(jī)制 Androidpn。它是一個整合方案,其客戶端基于Spark,服務(wù)器端的實現(xiàn)是基于Openfire,并精簡了 Openfire過于繁復(fù)龐大的功能,僅僅分離出了消息推送服務(wù)。
以O(shè)penfire和Spark包構(gòu)建的基于XMPP協(xié)議的推送機(jī)制為例,如下圖所示,客戶端首先和服務(wù)器端進(jìn)行連接,連接后消息可以在服務(wù)器端和客戶端、客戶端和客戶端間雙向傳輸。
基于XMPP協(xié)議的推送機(jī)制能夠?qū)崿F(xiàn)真正意義上的即時推送,不用像C2DM服務(wù)需要擔(dān)心由于服務(wù)器在國外帶來的推送服務(wù)的不穩(wěn)定性,也不存在使用第三方的SDK帶來的安全風(fēng)險。同時該機(jī)制繼承了 XML的優(yōu)點(diǎn),具備很強(qiáng)的可擴(kuò)展性,可以實現(xiàn)復(fù)雜的通信。雖然目前基于XMPP協(xié)議的推送只支持文字格式的推送,但己滿足大部分系統(tǒng)的推送需求,因為一般情況下,推送消息只是告訴客戶端服務(wù)器端有變化,而變化的具體內(nèi)容則由客戶端主動到服務(wù)器獲取。目前已有Java語言編寫的服務(wù)器端與客戶端開源程序,使開發(fā)者很容易進(jìn)行二次開發(fā),根據(jù)具體需求搭建自己的系統(tǒng)。
