Android推送方案

一. 常見的推送原理：

　　1）輪詢(Pull)方式：應用程序應當階段性的與服務器進行鏈接並查詢是否有新的消息到達，你必須本身實現與服務器之間的通訊，例如消息排隊等。並且你還要考慮輪詢的頻率，若是太慢可能致使某些消息的延遲，若是太快，則會大量消耗網絡帶寬和電池。

　　2）SMS(Push)方式：在Android平臺上，你能夠經過攔截SMS消息而且解析消息內容來了解服務器的意圖，並獲取其顯示內容進行處理。這是一個不錯的想法，我就見過採用這個方案的應用程序。這個方案的好處是，能夠實現徹底的實時操做。可是問題是這個方案的成本相對比較高，咱們須要向移動公司繳納相應的費用。咱們目前很難找到免費的短消息發送網關來實現這種方案。

　　3）持久鏈接(Push)方式：這個方案能夠解決由輪詢帶來的性能問題，可是仍是會消耗手機的電池。IOS平臺的推送服務之因此工做的很好，是由於每一臺手機僅僅保持一個與服務器之間的鏈接，事實上C2DM也是這麼工做的。不過剛纔也講了，這個方案存在着不少的不足之處，就是咱們很難在手機上實現一個可靠的服務，目前也沒法與IOS平臺的推送功能相比。

Android操做系統容許在低內存狀況下殺死系統服務，因此咱們的推送通知服務頗有可能就被操做系統Kill掉了。 輪詢(Pull)方式和SMS(Push)方式這兩個方案也存在明顯的不足。至於持久鏈接(Push)方案也有不足，不過咱們能夠經過良好的設計來彌補，以便於讓該方案能夠有效的工做。畢竟，咱們要知道GMail，GTalk以及GoogleVoice均可以實現實時更新的，所以，確定有持久鏈接，而後就看如何去優化這個連接了。

原理上來講，最合適的是持久鏈接。

二．推送方案比較

　

　1. C2DM雲端推送功能。

　　Android Cloud to Device Messaging (C2DM)是一個用來幫助開發者從服務器向Android應用程序發送數據的服務。該服務提供了一個簡單的、輕量級的機制，容許服務器能夠通知移動應用程序直接與服務器進行通訊，以便於從服務器獲取應用程序更新和用戶數據。C2DM服務負責處理諸如消息排隊等事務並向運行於目標設備上的應用程序分發這些消息。關於C2DM具體使用過程，你們能夠去查閱相關的資料，在這裏先讓咱們瞭解下大體方案狀況。

    C2DM操做過程示例圖:

　　

 

　　可是通過一番研究發現，這個服務存在很大的問題：

　　1）C2DM內置於Android的2.2系統上，沒法兼容老的1.6到2.1系統，最新的谷歌版本分佈顯示已經能夠忽略1.6到2.1系統，該條能夠忽略；

　　2）C2DM須要依賴於Google官方提供的C2DM服務器，因爲國內的網絡環境，這個服務常常不可用，若是想要很好的使用，咱們的App Server必須也在國外，這個恐怕不是每一個開發者都可以實現的，這條關鍵;

　　3) 不像在iPhone中，他們把硬件系統集成在一塊了。因此對於咱們開發者來講，若是要在咱們的應用程序中使用C2DM的推送功能，由於對於不一樣的這種硬件廠商平臺，好比摩托羅拉、華爲、中興作一個手機，他們可能會把Google的這種服務去掉，尤爲像在國內就不少這種，把Google這種原生的服務去掉。買了一些像什麼山寨機或者是華爲這種國產機，可能Google的服務就沒有了。而像在國外出的那些可能會內置。

有了上述幾個方面的制約，只得放棄了這個方案，不過我想利用另一篇文章來詳細的介紹C2DM的框架以及客戶端和App Server的相應設置方法，能夠做爲學習資源讓咱們有個參考的資料。 即然C2DM沒法知足咱們的要求，那麼咱們就須要本身來實現Android手機客戶端與App Server之間的通訊協議，保證在App Server想向指定的Android設備發送消息時，Android設備可以及時的收到。

綜上，C2DM方案不可用。

　　

2. MQTT協議實現Android推送功能。

    採用MQTT協議實現Android推送功能也是一種解決方案。MQTT是一個輕量級的消息發佈/訂閱協議，它是實現基於手機客戶端的消息推送服務器的理想解決方案。

    wmqtt.jar 是IBM提供的MQTT協議的實現。咱們能夠從這裏（https://github.com/tokudu/AndroidPushNotificationsDemo）下載該項目的實例代碼，而且能夠找到一個採用PHP書寫的服務器端實現（https://github.com/tokudu/PhpMQTTClient）。

　　架構以下圖所示：

　　

 

　　wmqtt.jar 是IBM提供的MQTT協議的實現。咱們能夠從以下站點下載（http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg24006006）它。咱們能夠將該jar包加入本身的Android應用程序中。

 

　　

3. RSMB實現推送功能。

　　Really Small Message Broker (RSMB) ，他是一個簡單的MQTT代理，一樣由IBM提供，其查看地址是：http://www.alphaworks.ibm.com/tech/rsmb。缺省打開1883端口，應用程序當中，它負責接收來自服務器的消息並將其轉發給指定的移動設備。

　　SAM是一個針對MQTT寫的PHP庫。咱們能夠從這個http://pecl.php.net/package/sam/download/0.2.0地址下載它.

　　send_mqtt.php是一個經過POST接收消息而且經過SAM將消息發送給RSMB的PHP腳本。

 

　　

4. XMPP協議實現Android推送功能。

　　這是我但願在項目中採用的方案，由於目前它是開源的，對於其簡單的推送功能它仍是可以實現的。咱們能夠修改其源代碼來適應咱們的應用程序。

事實上Google官方的C2DM服務器底層也是採用XMPP協議進行的封裝。XMPP(可擴展通信和表示協議)是基於可擴展標記語言（XML）的協議，它用於即時消息（IM）以及在線探測。這個協議可能最終容許因特網用戶向因特網上的其餘任何人發送即時消息。關於XMPP協議的介紹能夠參考下文：

http://www.cnblogs.com/hanyonglu/archive/2012/03/04/2378956.html

　　androidpn是一個基於XMPP協議的java開源Android push notification實現，它包含了完整的客戶端和服務器端，是目前國內點擊量很高的一個開源引擎。通過源代碼研究我發現，該服務器端基本是在另一個開源工程openfire基礎上修改實現的，不過比較鬱悶的是androidpn的文檔是由韓語寫的，因此整個研究過程基本都是讀源碼。

　　這是androidpn的項目主頁：http://sourceforge.net/projects/androidpn/

　　androidpn實現意圖以下圖所示：

　　

 

　　androidpn 客戶端須要用到一個基於java的開源XMPP協議包asmack，這個包一樣也是基於openfire下的另一個開源項目smack，不過咱們不須要本身編譯，能夠直接把androidpn客戶端裏面的asmack.jar拿來使用。客戶端利用asmack中提供的XMPPConnection類與服 務器創建持久鏈接，並經過該鏈接進行用戶註冊和登陸認證，一樣也是經過這條鏈接，接收服務器發送的通知。

　　androidpn服務器端也是java語言實現的，基於openfire開源工程，不過它的Web部分採用的是spring框架，這一點與 openfire是不一樣的。Androidpn服務器包含兩個部分，一個是偵聽在5222端口上的XMPP服務，負責與客戶端的 XMPPConnection類進行通訊，做用是用戶註冊和身份認證，併發送推送通知消息。另一部分是Web服務器，採用一個輕量級的HTTP服務器， 負責接收用戶的Web請求。服務器架構以下：

 

　　最上層包含四個組成部分，分別是SessionManager，Auth Manager，PresenceManager以及Notification Manager。SessionManager負責管理客戶端與服務器之間的會話，Auth Manager負責客戶端用戶認證管理，Presence Manager負責管理客戶端用戶的登陸狀態，NotificationManager負責實現服務器向客戶端推送消息功能。

　　這個解決方案的最大優點就是簡單，咱們不須要象C2DM那樣依賴操做系統版本，也不會擔憂某一天Google服務器不可用。利用XMPP協議咱們還能夠進一步的對協議進行擴展，實現更爲完善的功能。 採用這個方案，咱們目前只能發送文字消息，不過對於推送來講通常足夠了，由於咱們不能期望經過推送獲得全部的數據，通常狀況下，利用推送只是告訴手機端服務器發生了某些改變，當客戶端收到通知之後，應該主動到服務器獲取最新的數據，這樣纔是推送服務的完整實現。 XMPP協議書相對來講仍是比較簡單的，值得咱們進一步研究。

　　

5. 使用第三方平臺。

　　使用第三方平臺就須要使用別人的服務器，若是該服務器出現問題，那相應的服務也就不可用了，關於國內的第三方平臺，目前我瞭解到的有極光推送（JPush），騰訊信鴿，百度雲推送，個推等。最專業的應該是極光推送，並且合做商家最多，百度和騰訊的後來出現的，貌似口碑還行。

國外的第三方平臺也有幾個，如：http://www.push-notification.org/，不是很完善，僅在此提一下，不考慮使用。

1. 總結

   MQTT、RSMB、XMPP中要使用的話，無論用何種方式都要本身搭建推送平臺，至於平臺要作到何種程度，不放先看一下目前已有的第三方平臺功能，以騰訊信鴿爲例（由於註冊簡單）：

   
   

    

    

   從圖中能夠看出的已具有的功能有消息或通知的定時發送、離線保存、分組發送、草稿箱，消息通知的抵達量，推送量，點擊量，點擊率，抵達率等，本身搭建平臺，要作到如此完整程度的系統，須要大量的工做。

   由《基於AndroidPn二次開發的可行性》和《Android第三方推送引擎比較》知，基於現狀最合適的是使用百度雲推送平臺。