android消息推送

 原創作品，允許轉載，轉載時請務必以超連結形式标明文章 原始出處 、作者資訊和本聲明。否則将追究法律責任。http://rzmars.blog.51cto.com/4356405/838705

    對于消息的提醒方式可以分為四種：固定視窗、彈出視窗、手機短信和push資訊。

    所謂資訊推送，就是"web廣播"，是通過一定的技術标準或協定，

    在網際網路上通過定期傳送使用者需要的資訊來減少資訊過載的一項新技術。

    推送技術通過自動傳送資訊給使用者，來減少用于網絡上搜尋的時間。

    它根據使用者的興趣來搜尋、過濾資訊，并将其定期推給使用者，

    幫助使用者高效率地發掘有價值的資訊。

  簡單的來說，資訊推送就是伺服器端主動向用戶端發送資訊，用戶端進行接收資訊。

  android（google）：

首先介紹一下google官方應用的push：

1）如果你有新的gmail郵件，手機可以馬上收到郵件通知，這個中間可能有2，3秒的延遲，一般感覺還是很及時的；

2）如果你的聯系人和google contanct是關聯的話，你用桌面浏覽器通路gmail，修改聯系人資訊，很快新的聯系人資訊就會同步到你手機上。

在google i/o 2010 介紹了 android 2.2 導入的 android cloud to device messaging (c2dm) 服務，

 c2dm)作為 android 2.2 的一部分已經釋出了。c2dm 允許第三方開發者開發相關的應用來推送少量資料消息到使用者的手機上，其機制如下圖：

 android cloud to device messaging (c2dm)是一個用來幫助開發者從伺服器向android應用程式發送資料的服務。該服務提供了一個簡單的、輕量級的機制，允許伺服器可以通知移動應用程式直接與伺服器進行通信，以便于從伺服器擷取應用程式更新和使用者資料。c2dm服務負責處理諸如消息排隊等事務并向運作于目标裝置上的應用程式分發這些消息。

啟用c2dm的過程：

     1，移動裝置：必須運作android，并且安裝market，至少有一個登入的google賬号。

      2，伺服器：自己的伺服器

      3，c2dm伺服器：google的伺服器

         授權機制：

1，  sender id：一個google賬号，用于标示開發者的身份，比如[email protected]

2，application id：manifest.xml裡面的pacakage name。用于标示應用程式

3，registration id：當應用程式向c2dm伺服器注冊時，c2dm伺服器會傳回這個id，當應用程式獲得這個id之後，應該告訴自己的伺服器，自己的伺服器把這個id存在資料庫裡面，用于告訴c2dm伺服器标示用戶端。

4，google user account：要使用c2dm服務，必須有一個google賬号。

5，sender auth token：自己的伺服器與c2dm伺服器通信的認證。

           應用程式發送intent，com.google.android.c2dm.intent.register，附上自己的senderid和appid，就可以向c2dm伺服器進行注冊，注冊成功之後，可以收到registration intent，獲得registration id，這個registration id是會被c2dm改變的，是以這個registration intent可能會收到多次，要記得存儲和發送給自己的伺服器

通過對比研究發現c2dm機制存在以下缺點：

1、c2dm内置于android的2.2系統上，無法相容老的1.6到2.1系統;

2、c2dm需要依賴于google官方提供的c2dm伺服器，由于國内的網絡環境，這個服務經常不可用，如果想要很好的使用，我們的app server必須也在國外，這個恐怕不是每個開發者都能夠實作的;。

 除了c2dm在實作android消息推送機制的方案還有以下幾種：

1、輪詢（polling）：應用程式應當階段性的與伺服器進行連接配接并查詢是否有新的消息到達，你必須自己實作與伺服器之間的通信，例如消息排隊等。而且你還要考慮輪詢的頻率，如果太慢可能導緻某些消息的延遲，如果太快，則會大量消耗網絡帶寬和電池。

2、長連接配接：這個方案可以解決由輪詢帶來的性能問題，但是還是會消耗手機的電池。apple的推送服務之是以工作的很好，是因為每一台手機僅僅保持一個與伺服器之間的連接配接，事實上c2dm也是這麼工作的。不過這個方案也存在不足，就是我們很難在手機上實作一個可靠的服務。android作業系統允許在低記憶體情況下殺死系統服務，是以你的通知服務很可能被作業系統kill掉了。

這種方法通過come（基于 http 長連接配接的“伺服器推”技術）長連接配接也可以實作。詳細可以參照http://www.ibm.com/developerworks/cn/web/wa-lo-comet/，但是這并不是最有的一種方式，

在android下最有的方式應該采取xmpp協定推送android資訊：

首先介紹一下xmpp基于可擴充标記語言（xml）的協定，它用于即時消息（im）以及線上探測。這個協定可能最終允許網際網路使用者向網際網路上的其他任何人發送即時消息。詳細參考：

http://zh.wikipedia.org/zh-cn/xmpp

google官方的c2dm伺服器底層也是采用xmpp協定進行的封裝。

androidpn是一個基于xmpp協定的java開源android push notification實作。它包含了完整的用戶端和伺服器端。該伺服器端基本是在另外一個開源工程openfire基礎上修改實作的。它的實作示意圖如下：

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協定我們還可以進一步的對協定進行擴充，實作更為完善的功能。

采用這個方案，目前隻能發送文字消息，不過對于推送來說一般足夠了，因為我們不能指望通過推送得到所有的資料，一般情況下，利用推送隻是告訴手機端伺服器發生了某些改變，當用戶端收到通知以後，應該主動到伺服器擷取最新的資料，這樣才是推送服務的完整實作。

本文出自 “rzmars” 部落格，請務必保留此出處http://rzmars.blog.51cto.com/4356405/838705