如何在Android中實(shí)現(xiàn)推送

A罩杯 · 發(fā)表于 2013-8-28 16:28

7       當(dāng)我們開發(fā)需要和服務(wù)器交互的應(yīng)用程序時(shí)，基本上都需要獲取服務(wù)器端的數(shù)據(jù)，比如《地震應(yīng)急通》就需要及時(shí)獲取服務(wù)器上最新的地震信息。要獲取服務(wù)器上不定時(shí)更新的信息一般來說有兩種方法，第一種是客戶端使用Pull（拉）的方式，隔一段時(shí)間就去服務(wù)器上獲取信息，看是否有更新的信息出現(xiàn)。第二種就是服務(wù)器使用Push（推送）的方式，當(dāng)服務(wù)器端有新信息了，則把最新的信息Push到客戶端上。?

      雖然Pull和Push兩種方式都能實(shí)現(xiàn)獲取服務(wù)器端更新信息的功能，但是明顯來說Push is better than pull。因?yàn)镻ull方式更費(fèi)客戶端的網(wǎng)絡(luò)流量，更主要的是費(fèi)電量。??

      在開發(fā)Android和iPhone應(yīng)用程序時(shí)，我們往往需要從服務(wù)器不定的向手機(jī)客戶端即時(shí)推送各種通知消息，iPhone上已經(jīng)有了比較簡(jiǎn)單的和完美的推送通知解決方案，我會(huì)在以后詳細(xì)介紹IPhone中的解決方案，可是Android平臺(tái)上實(shí)現(xiàn)起來卻相對(duì)比較麻煩，最近利用幾天的時(shí)間對(duì)Android的推送通知服務(wù)進(jìn)行初步的研究。在Android手機(jī)平臺(tái)上，Google提供了C2DM（Cloudto Device Messaging）服務(wù)，起初我就是準(zhǔn)備采用這個(gè)服務(wù)來實(shí)現(xiàn)自己手機(jī)上的推送功能。??

      Android Cloud to Device Messaging (C2DM)是一個(gè)用來幫助開發(fā)者從服務(wù)器向Android應(yīng)用程序發(fā)送數(shù)據(jù)的服務(wù)。該服務(wù)提供了一個(gè)簡(jiǎn)單的、輕量級(jí)的機(jī)制，允許服務(wù)器可以通知移動(dòng)應(yīng)用程序直接與服務(wù)器進(jìn)行通信，以便于從服務(wù)器獲取應(yīng)用程序更新和用戶數(shù)據(jù)。C2DM服務(wù)負(fù)責(zé)處理諸如消息排隊(duì)等事務(wù)并向運(yùn)行于目標(biāo)設(shè)備上的應(yīng)用程序分發(fā)這些消息。關(guān)于C2DM具體使用過程，這里大家先了解下大致方案情況。


但是經(jīng)過一番研究發(fā)現(xiàn)，這個(gè)服務(wù)存在很大的問題：
      1）C2DM內(nèi)置于Android的2.2系統(tǒng)上，無法兼容老的1.6到2.1系統(tǒng);

      2）C2DM需要依賴于Google官方提供的C2DM服務(wù)器，由于國(guó)內(nèi)的網(wǎng)絡(luò)環(huán)境，這個(gè)服務(wù)經(jīng)常不可用，如果想要很好的使用，我們的App Server必須也在國(guó)外，這個(gè)恐怕不是每個(gè)開發(fā)者都能夠?qū)崿F(xiàn)的; 有了上述兩個(gè)使用上的制約，導(dǎo)致我最終放棄了這個(gè)方案，不過我想利用另外一篇文章來詳細(xì)的介紹C2DM的框架以及客戶端和App Server的相應(yīng)設(shè)置方法，可以作為學(xué)習(xí)與參考之用。即然C2DM無法滿足我們的要求，那么我們就需要自己來實(shí)現(xiàn)Android手機(jī)客戶端與App Server之間的通信協(xié)議，保證在App Server想向指定的Android設(shè)備發(fā)送消息時(shí)，Android設(shè)備能夠及時(shí)的收到。


      1）輪詢(Pull)：應(yīng)用程序應(yīng)當(dāng)階段性的與服務(wù)器進(jìn)行連接并查詢是否有新的消息到達(dá)，你必須自己實(shí)現(xiàn)與服務(wù)器之間的通信，例如消息排隊(duì)等。而且你還要考慮輪詢的頻率，如果太慢可能導(dǎo)致某些消息的延遲，如果太快，則會(huì)大量消耗網(wǎng)絡(luò)帶寬和電池。

      2）SMS(Push)：在Android平臺(tái)上，你可以通過攔截SMS消息并且解析消息內(nèi)容來了解服務(wù)器的意圖。這是一個(gè)不錯(cuò)的想法，我就見過采用這個(gè)方案的應(yīng)用程序。這個(gè)方案的好處是，可以實(shí)現(xiàn)完全的實(shí)時(shí)操作。但是問題是這個(gè)方案的成本相對(duì)比較高，你很難找到免費(fèi)的短消息發(fā)送網(wǎng)關(guān)，關(guān)于這個(gè)方案的實(shí)現(xiàn)。

      3）持久連接(Push)：這個(gè)方案可以解決由輪詢帶來的性能問題，但是還是會(huì)消耗手機(jī)的電池。Apple的推送服務(wù)之所以工作的很好，是因?yàn)槊恳?臺(tái)手機(jī)僅僅保持一個(gè)與服務(wù)器之間的連接，事實(shí)上C2DM也是這么工作的。不過這個(gè)方案也存在不足，就是我們很難在手機(jī)上實(shí)現(xiàn)一個(gè)可靠的服務(wù)。


      Android操作系統(tǒng)允許在低內(nèi)存情況下殺死系統(tǒng)服務(wù)，所以你的通知服務(wù)很可能被操作系統(tǒng)Kill掉了。前兩個(gè)方案存在明顯的不足，第三個(gè)方案也有不足，不過我們可以通過良好的設(shè)計(jì)來彌補(bǔ)，以便于讓該方案可以有效的工作。畢竟，我們要知道GMail，GTalk以及GoogleVoice都可以實(shí)現(xiàn)實(shí)時(shí)更新的。


      采用MQTT協(xié)議實(shí)現(xiàn)Android推送 MQTT是一個(gè)輕量級(jí)的消息發(fā)布/訂閱協(xié)議，它是實(shí)現(xiàn)基于手機(jī)客戶端的消息推送服務(wù)器的理想解決方案。 wmqtt.jar 是IBM提供的MQTT協(xié)議的實(shí)現(xiàn)。我們可以從這里下載該項(xiàng)目的實(shí)例代碼，并且可以找到一個(gè)采用PHP書寫的是IBM提供的MQTT協(xié)議的實(shí)現(xiàn)。我們可以從如下站點(diǎn)下載它。你可以將該jar包加入你自己的Android應(yīng)用程序中。


      Really Small Message Broker (RSMB) ，他是一個(gè)簡(jiǎn)單的MQTT代理，同樣由IBM提供。缺省打開1883端口，應(yīng)用程序當(dāng)中，它負(fù)責(zé)接收來自服務(wù)器的消息并將其轉(zhuǎn)發(fā)給指定的移動(dòng)設(shè)備。

      SAM是一個(gè)針對(duì)MQTT寫的PHP庫。我們可以從這個(gè)下載它.

      send_mqtt.php是一個(gè)通過POST接收消息并且通過SAM將消息發(fā)送給RSMB的PHP腳本。

      Really Small Message Broker (RSMB) ，他是一個(gè)簡(jiǎn)單的MQTT代理，同樣由IBM提供。缺省打開1883端口，應(yīng)用程序當(dāng)中，它負(fù)責(zé)接收來自服務(wù)器的消息并將其轉(zhuǎn)發(fā)給指定的移動(dòng)設(shè)備。

› 智能家居 / NAS / 路由 / 開發(fā) / 音響 › TV應(yīng)用開發(fā)交流

如何在Android中實(shí)現(xiàn)推送

如何在Android中實(shí)現(xiàn)推送