Android 幾種訊息推送方案總結，android方案

Android 幾種訊息推送方案總結，android方案

轉載請註明出處：http://www.cnblogs.com/Joanna-Yan/p/6241354.html

首先看一張國內Top500 Android應用中它們用到的第三方推送以及所佔數量：

現在總結下Android平台下幾種推送方案的基本情況以及優缺點：

一、使用GCM(Google Cloude Messaging)

Android內建的推送GCM可以協助開發人員給他們的Android應用程式發送資料。它是一個輕量級的訊息，告訴Android應用程式有新的資料要從伺服器擷取，或者它可能是一個訊息，其中包含了4KB的payload data（像即時通訊這類應用程式可以直接使用該payload訊息）。GCM服務處理排隊的訊息，並把訊息傳遞到目標裝置上啟動並執行Android應用程式。

優點：Google提供的服務、原生、簡單，無需實現和部署服務端。

缺點：1.要求Android 2.2以上，對於不少2.2以前的系統沒法推送；

　　   2.國內服務不穩定。而且不少國內的終端廠商紛紛把Google的服務去掉，替換上自己的。

　　   3.需要使用者綁定Google帳號，但不少國內使用者沒有Google帳號。

二、使用XMPP協議（Openfire+Spark+Smark）

XMPP是一種基於XML的協議，它繼承了在XML環境中靈活的發展性，有很強的可擴充性。包括上面講的GCM伺服器底層也是採用XMPP協議封裝的。

優點：協議成熟、強大、可擴充性強、目前主要應用於許多聊天系統中，且已有開源的Java版的開發執行個體androidpn。

缺點：協議較複雜、冗餘（基於XML）、費流量、費電，部署硬體成本高。

而androidpn（Android Push Notification）就是基於 XMPP 開源組件的一套整合方案，服務端基於Openfire、用戶端基於Smack。到AndroidPN項目首頁( http://sourceforge.net/projects/androidpn/ ) 下載2個檔案： androidpn-server-0.5.0-bin.zip 和 androidpn-client-0.5.0.zip 分別是伺服器和用戶端的代碼。詳細的實現方式網上有不少文章。

　　1.androidpn服務端重啟後用戶端不會重連，這個非常悲劇

　　2.由於伺服器不儲存訊息，造成了如果用戶端當前離線就收不到訊息

　　3.androidpn發送完訊息就不管了，所以沒有訊息回執報表之類，造成沒法做應用後續的資料分析使用者體驗的改善，這對於企業級的應用是個致命傷。

XMPP協議比較費電費流量，這個對當前智能機的消耗太大，在窄帶網路和不穩定的（手機）網路都不是最優的選擇。但總體來說，XMPP協議還是比較成熟的。

三、使用MQTT協議（想瞭解更多可以看http://mqtt.org/）

輕量級的、基於代理的“發布/訂閱”模式的訊息傳輸協議。

優點：協議簡潔、小巧、可擴充性強、省流量、省電，目前已經應用到企業領域（參考： http://mqtt.org/software），且已有C++版的服務端組件rsmb。

缺點：不夠成熟、實現較複雜、服務端組件rsmb不開源，部署硬體成本較高。

四、HTTP輪循方式

定時向HTTP服務端介面（Web Service API）擷取最新訊息。

優點：實現簡單、可控性強，部署硬體成本低。

缺點：即時性差。

五、採用第三方服務

就是前面介紹的第三方推送，用戶端只需要匯入第三方提供的lib庫，有第三方監理長串連，負責訊息的接收/發送。同時對訊息都有比較詳細的報表資料，可以用於做資料分析、挖掘，改善使用者體驗。