轉自：http://blog.csdn.net/zphappy/article/details/6658504
由於公司要做一個android的消息推送功能，讓我進行了一個調研，發現網上沒有一個集中說明的地方，自己在網上搜羅了一些資料並且自己總結了一下。
對於消息的提醒方式可以分爲四種：固定窗口、彈出窗口、手機短信和Push信息。下面的針對於push信息的機制和技術實現向大家介紹一下。
首先，我們要知道什麼是Push信息？
所謂信息推送，就是"web廣播"，是通過一定的技術標準或協議，在互聯網上通過定期傳送用戶需要的信息來減少信息過載的一項新技術。推送技術通過自動傳送信息給用戶，來減少用於網絡上搜索的時間。它根據用戶的興趣來搜索、過濾信息，並將其定期推給用戶，幫助用戶高效率地發掘有價值的信息。
簡單的來說，信息推送就是服務器端主動向客戶端發送信息，客戶端進行接收信息。如下圖：
使用推送信息的好處:
1、節省用戶的電池電量。
2、你可以通過推送通知來告知你的用戶在程序中發生了一些有趣的事，即使程序沒有運行。
現在很多應用程序都是用的推送的機制：
包括新浪微博，推送最新的朋友消息；墨跡天氣推送最新的天氣狀況；網易新聞，推送重要的新聞；同花順手機炒股推送最新的股票資訊；微信，推送最新的語音最新。Gmail、Gtalk推送最新的Mail信息和IM信息。
下面，我們瞭解一下現在主流手機的push機制。
IPhone（APPLE）的工作機制可以簡單的概括爲下圖：
iPhone自3.0之後推出消息推送機制，原理是消息由服務器統一處理。
圖中，Provider是指某個iPhone軟件的Push服務器，這篇文章我將使用Java作爲Provider。
APNS 是Apple Push Notification Service（Apple Push服務器）的縮寫，是蘋果的服務器。
上圖可以分爲三個階段。
第一階段：Java應用程序把要發送的消息、目的iPhone的標識打包，發給APNS。
第二階段：APNS在自身的已註冊Push服務的iPhone列表中，查找有相應標識的iPhone，並把消息發到iPhone。
第三階段：iPhone把發來的消息傳遞給相應的應用程序， 並且按照設定彈出Push通知。
從上圖我們可以看到。
1、首先是應用程序註冊消息推送。
2、 IOS跟APNS Server要deviceToken。應用程序接受deviceToken。
3、應用程序將deviceToken發送給PUSH服務端程序。
4、 服務端程序向APNS服務發送消息。
5、APNS服務將消息發送給iPhone應用程序。
APNs和iPhone保持15分鐘的心跳式長連接，維護手機和服務器的聯繫正常，否則手機會不停發起連接，直到連接到服務器爲止。程序不必實時開啓和主動檢查更新，當收到APNs消息時，iPhone會彈出對話框Push消息並伴隨着聲音，用戶可以選擇“view”或者“close”。即使用戶當前處在離線狀態，用戶收到消息之後激活程序，再通過程序鏈接應用服務器下載郵件或者錄音。
WP7（Microsoft）的Push機制如下圖：
WP7的也有相應的推送服務，無論程序是否開啓都可以界面頂部推送Toast Notification，並顯示10秒。WP7的Push Client負責於服務器交互，接受到消息時再傳送給相應的應用程序，而不需要應用程序各自維護一個進程。如果程序被釘在首頁，服務器推送瓦片通知（Tile Notification），改變瓦片的背景圖片、數字和標題屬性。而彈出框式的原生推送（Raw Notification）只能應用在程序開啓時，容許實時更新界面
WebOS (BlackBerry)的推送機制如下如所示：
從示意圖中可以看到在BlackBerry應用平臺上的數據推送從整體上可以分爲六步，按時間順序分別爲：
第一步：應用服務器向MDS/BES服務器發送推送請求，所發送的請求爲HTTP格式的請求。
第二步：MDS/BES服務器查詢相關配置數據庫，確定應用服務器所發送的請求是否爲合法的請求。此外，MDS/BES服務器還會根據資源情況確定是否接收該請求。對於是否接收請求的判斷在下一節內容中也有詳細討論
第三步：MDS/BES服務器嚮應用服務器返回消息，通知應用服務器是否接受該請求。返回消息以HTTP答覆的方式返回給應用服務器
第四步：MDS/BES服務器將數據推送到手持設備端
第五步：手持設備端對數據進行處理後向MDS/BES服務器返回確認消息
第六步：MDS/BES根據手持設備端返回的消息決定向應用服務器返回什麼異步消息，這一步並不是必然發生的，根據推送請求的不同有可能不發生。
黑莓的推送是最早的，最早應用在郵件上，而且黑莓的推送機制也是加密最好的，最安全的機制。
下面我們來詳細的介紹一下android的推送機制：
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協議我們還可以進一步的對協議進行擴展，實現更爲完善的功能。
採用這個方案，目前只能發送文字消息，不過對於推送來說一般足夠了，因爲我們不能指望通過推送得到所有的數據，一般情況下，利用推送只是告訴手機端服務器發生了某些改變，當客戶端收到通知以後，應該主動到服務器獲取最新的數據，這樣纔是推送服務的完整實現。