1.推送方式基礎知識：

　　在移動網際網路時代以前的手機，如果有事情發生需要通知使用者，則會有一個視窗彈出，將告訴使用者正在發生什麼事情。可能是未接電話的提示，日曆的提醒，或是一封新的彩信。推送功能最早是被用於Email中，用來提示我們新的資訊。由於時代的發展和移動網際網路的熱潮，推送功能更加地普及，已經不再僅僅用在推送郵件了，更多地用在我們的APP中了。

　　當我們開發需要和伺服器互動的應用程式時，基本上都需要獲取伺服器端的資料，比如《地震應急通》就需要及時獲取伺服器上最新的地震資訊。要獲取伺服器上不定時更新的資訊，一般來說有兩種方法：第一種是客戶端使用Pull（拉）的方式，就是隔一段時間就去伺服器上獲取一下資訊，看是否有更新的資訊出現。第二種就是伺服器使用Push

　　雖然Pull和Push兩種方式都能實現獲取伺服器端更新資訊的功能，但是明顯來說Push方式比Pull方式更優越。因為Pull方式更費客戶端的網路流量，更主要的是費電量，還需要我們的程式不停地去監測服務端的變化。

　　在開發Android和iPhone應用程式時，我們往往需要從伺服器不定的向手機客戶端即時推送各種通知訊息。我們只需要在Android或IPhone的通知欄處向下一拉，就展開了Notification Panel，可以集中一覽各種各樣通知訊息。目前IOS平臺上已經有了比較簡單的和完美的推送通知解決方案，我會在以後詳細介紹IPhone

　　最近利用幾天的時間對Android的推送通知服務進行初步的研究，也希望能和大家共同探討一下。

2.幾種常見的解決方案實現原理：

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

　　2）SMS(Push)方式：在Android平臺上，你可以通過攔截SMS訊息並且解析訊息內容來了解伺服器的意圖，並獲取其顯示內容進行處理。這是一個不錯的想法，我就見過採用這個方案的應用程式。這個方案的好處是，可以實現完全的實時操作。但是問題是這個方案的成本相對比較高，我們需要向移動公司繳納相應的費用。我們目前很難找到免費的短訊息傳送閘道器來實現這種方案。

　　3）持久連線(Push)方式：這個方案可以解決由輪詢帶來的效能問題，但是還是會消耗手機的電池。IOS平臺的推送服務之所以工作的很好，是因為每一臺手機僅僅保持一個與伺服器之間的連線，事實上C2DM也是這麼工作的。不過剛才也講了，這個方案存在著很多的不足之處，就是我們很難在手機上實現一個可靠的服務，目前也無法與IOS平臺的推送功能相比。

　　Android作業系統允許在低記憶體情況下殺死系統服務，所以我們的推送通知服務很有可能就被作業系統Kill掉了。輪詢(Pull)方式和SMS(Push)方式這兩個方案也存在明顯的不足。至於持久連線(Push)方案也有不足，不過我們可以通過良好的設計來彌補，以便於讓該方案可以有效的工作。畢竟，我們要知道GMail，GTalk以及GoogleVoice都可以實現實時更新的。

3.第一種解決方案：C2DM雲端推送功能

　　在Android手機平臺上，Google提供了C2DM（Cloudto Device Messaging）服務，起初我就是準備採用這個服務來實現自己手機上的推送功能，並將其帶入自己的專案中。

　　Android Cloud to Device Messaging (C2DM)是一個用來幫助開發者從伺服器向Android應用程式傳送資料的服務。該服務提供了一個簡單的、輕量級的機制，允許伺服器可以通知移動應用程式直接與伺服器進行通訊，以便於從伺服器獲取應用程式更新和使用者資料。C2DM服務負責處理諸如訊息排隊等事務並向運行於目標裝置上的應用程式分發這些訊息。關於C2DM具體使用過程，大家可以去查閱相關的資料，在這裡先讓我們瞭解下大致方案情況。

　　下面是C2DM操作過程示例圖:

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

　　1）C2DM內置於Android的2.2系統上，無法相容老的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裝置能夠及時的收到。

4.第二種解決方案：MQTT協議實現Android推送功能

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

　　wmqtt.jar 是IBM提供的MQTT協議的實現。我們可以從這裡（https://github.com/tokudu/AndroidPushNotificationsDemo）下載該專案的例項程式碼，並且可以找到一個採用PHP書寫的伺服器端實現（）。

　　架構如下圖所示：

5.第三種解決方案：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指令碼。

6.第四種解決方案：XMPP協議實現Android推送功能

　　這是我希望在專案中採用的方案，因為目前它是開源的，對於其簡單的推送功能它還是能夠實現的。我們可以修改其原始碼來適應我們的應用程式。

　　事實上Google官方的C2DM伺服器底層也是採用XMPP協議進行的封裝。XMPP(可擴充套件通訊和表示協議)是基於可擴充套件標記語言（XML）的協議，它用於即時訊息（IM）以及線上探測。這個協議可能最終允許因特網使用者向因特網上的其他任何人傳送即時訊息。關於XMPP協議我在上篇博文中已經介紹，大家可以參考下文章：

　　androidpn是一個基於XMPP協議的java開源Android push notification實現，我會在以後的博文中詳細介紹androidpn。它包含了完整的客戶端和伺服器端。經過原始碼研究我發現，該伺服器端基本是在另外一個開源工程openfire基礎上修改實現的，不過比較鬱悶的是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協議書相對來說還是比較簡單的，值得我們進一步研究。

但是在經過一段時間的測試，我發現關於androidpn也存在一些不足之處：

　　1. 比如時間過長時，就再也收不到推送的資訊了。

　　2. 效能上也不夠穩定。

　   3.如果將訊息從伺服器上推送出去，就不再管理了，不管訊息是否成功到達客戶端手機上。

　　等等，總之，androidpn也有很多的缺點。如果我們要使用androidpn，則還需要做大量的工作。

　　至於詳細使用過程，我們會在下個博文中再給大家介紹。

7.第五種解決方案：使用第三方平臺

　　第三方平臺有商用的也有免費的，我們可以根據實現情況使用。關於國內的第三方平臺，我感覺目前比較不錯的就是極光推送。關於極光推送目前是免費的，我們可以直接使用。關於詳細情況，大家可以檢視它的主頁：，這裡不再詳細描述。

　　關於MQTT的方案，國內最近出現基於 mqtt的第三方解決方案雲巴 (http://yunba.io)，據瞭解是原極光推送 CTO創辦的，有興趣的朋友可以研究下。

　　關於國外的第三方平臺我也見過幾個：。有興趣的朋友可以查閱相關資訊。使用第三方平臺就需要使用別人的伺服器，關於這點，你懂的。

8.第六種解決方案：自己搭建一個推送平臺

　　這不是一件輕鬆的工作，當然可以根據各自的需要採取合適的方案。

　　好了，以上是關於在Android中實現推送方式的基礎知識及相關解決方案。

關於訊息推送比較好的博文還可以參考：