消息推送學習博文推薦 - （移動手機消息推送機制）

轉載自：http://blog.csdn.net/zphappy/article/details/6658504

因爲公司要作一個android的消息推送功能，讓我進行了一個調研，發現網上沒有一個集中說明的地方，本身在網上搜羅了一些資料而且本身總結了一下。

對於消息的提醒方式能夠分爲四種：固定窗口、彈出窗口、手機短信和Push信息。下面的針對於push信息的機制和技術實現向你們介紹一下。

     首先，咱們要知道什麼是Push信息？

     所謂信息推送，就是"web廣播"，是經過必定的技術標準或協議，在互聯網上經過按期傳送用戶須要的信息來減小信息過載的一項新技術。推送技術經過自動傳送信息給用戶，來減小用於網絡上搜索的時間。它根據用戶的興趣來搜索、過濾信息，並將其按期推給用戶，幫助用戶高效率地發掘有價值的信息。

簡單的來講，信息推送就是服務器端主動向客戶端發送信息，客戶端進行接收信息。以下圖：

使用推送信息的好處:

一、節省用戶的電池電量。 二、你能夠經過推送通知來告知你的用戶在程序中發生了一些有趣的事，即便程序沒有運行。

如今不少應用程序都是用的推送的機制：

包括新浪微博，推送最新的朋友消息；墨跡天氣推送最新的天氣情況；網易新聞，推送重要的新聞；同花順手機炒股推送最新的股票資訊；微信，推送最新的語音最新。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通知。

從上圖咱們能夠看到。

一、首先是應用程序註冊消息推送。

二、 IOS跟APNS Server要deviceToken。應用程序接受deviceToken。

三、應用程序將deviceToken發送給PUSH服務端程序。

四、 服務端程序向APNS服務發送消息。

五、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帳號，用於標示開發者的身份，好比hxzhoupeng@google.com

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機制存在如下缺點：

一、C2DM內置於Android的2.2系統上，沒法兼容老的1.6到2.1系統;

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

 

除了C2DM在實現Android消息推送機制的方案還有如下幾種：

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

二、長鏈接：這個方案能夠解決由輪詢帶來的性能問題，可是仍是會消耗手機的電池。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協議咱們還能夠進一步的對協議進行擴展，實現更爲完善的功能。

採用這個方案，目前只能發送文字消息，不過對於推送來講通常足夠了，由於咱們不能期望經過推送獲得全部的數據，通常狀況下，利用推送只是告訴手機端服務器發生了某些改變，當客戶端收到通知之後，應該主動到服務器獲取最新的數據，這樣纔是推送服務的完整實現。