Android推送實現方案探討

背景介紹

隨著蘋果產品的風靡，推送技術在國內也越來越熱門。推送最開始用於郵件系統。隨著iPhone 和 Android 手機的風靡，逐漸在手機上也越來越常見。不少手機用戶端也時常推送一些訊息。

 

推送技術的應用

推送技術在手機上的應用主要有兩塊：廣告推送、SNS資訊推送。

Ø 廣告推送：給目前有一定安裝量但沒有盈利模式的手機應用開發人員帶來了一定希望，但要注意推送的頻度和內容選中，不然會因為推送的東西使用者不感興趣造成打擾。

Ø SNS資訊推送：主要用於QQ空間、人人網、微博和天涯論壇等web2.0社區網站推送好友的留言等，可以用來提升使用者黏性。

 

用戶端/伺服器通訊的兩種方式：

服務端和用戶端推送有兩種方式，分別是Pull 和 Push。

Ø Pull ：由用戶端定時訪問伺服器，詢問是否有新資訊。而Push則在手機用戶端和伺服器之間建立持久串連通道，服務端一有訊息就通過通道發給手機。

Ø Push：相比Pull，Push推送的訊息是即時的，而且更節省手機的電量和流量，不需要定時訪問伺服器。Pull輪詢方式一般資訊會有1到10分鐘不等的延時，且耗電量也比Push方式消耗得多。

 

Android/iOS推送比較

相比Android，iOS的推送服務要穩定，因為Android作業系統使用者可以自己殺死服務，這樣就造成了手機接收不到通知訊息。蘋果APNs（Apple Push Notification Service）的流程如下：

1、應用程式註冊訊息推送。

2、iOS從蘋果推送伺服器（APNs）擷取device token（裝置令牌，用於標識裝置），應用程式接收device token。

3、應用程式將device token發送給第三方Push服務端程式。

4、服務端程式向APNS服務發送訊息。

5、APNS服務將訊息發送給iPhone應用程式。

 

推送解決方案

目前Android上主要的推送實現方案有以下幾種：

方案一、Google Cloud Messageing

Google在Android上標配了自己的推送GCM（Google Cloud Messageing），可以協助開發人員給他們的Android應用程式發送資料。它是一個輕量級的訊息，告訴Android應用程式有新的資料要擷取從伺服器，或者它可能是一個訊息，其中包含了4KB的payload data（像即時通訊這類應用程式可以直接使用該payload訊息）。GCM服務處理排隊的訊息，並把訊息傳遞到目標裝置上啟動並執行Android應用程式。

GCM的推送訊息的流程如：

 

GCM服務的步驟Google已經在http://developer.android.com/guide/google/gcm/gs.html給出了，只要參照著做就行了，我就不再贅述了。

GCM使用比較簡單，而且Google的伺服器來處理負載平衡、訊息佇列處理。但有下面三個缺陷也導致了GCM在國內基本不可用：

1)GCM要求Android系統必須是2.2以上的版本，所以對於不少2.2以前的系統沒法推送

2)國內服務不穩定。而且不少國內的終端廠商紛紛把Google的服務去掉，替換上自己的。

3)需要使用者綁定Google帳號，但不少國內使用者沒有Google帳號。

 

方案二、採用XMPP協議

XMPP是一種基於XML的協議，它繼承了在XML環境中靈活的發展性，有很強的可擴充性。包括上面講的GCM伺服器底層也是採用XMPP協議封裝的。

XMPP協議有如下優點：

1、 分布式：任何人都可以運行自己的XMPP伺服器，它沒有主伺服器

2、 安全性高：使用TLS等技術

3、 跨平台

4、分布式

而androidpn（Android Push Notification）就是基於 XMPP 開源組件的一套整合方案，服務端基於Openfire、用戶端基於Smack。到AndroidPN項目首頁( http://sourceforge.net/projects/androidpn/ ) 下載2個檔案： androidpn-server-0.5.0-bin.zip 和 androidpn-client-0.5.0.zip  分別是伺服器和用戶端的代碼。詳細的實現方式網上有不少文章。

androidpn是韓國人放在sourceforge.net 的項目，已經有兩年多沒有更新了，項目應該是個人維護的，不是很成熟。有意思的是，網站上這個項目有82%的下載者的ip是中國的。androidpn有如下一些不足，開發的時候需要權衡：

1、androidpn服務端重啟後用戶端不會重連，這個非常悲劇

2、由於伺服器不儲存訊息，造成了如果用戶端當前離線就收不到訊息。

3、androidpn發送完訊息就不管了，所以沒有訊息回執報表之類，造成沒法做應用後續的資料分析使用者體驗的改善，這對於企業級的應用是個致命傷。

XMPP協議比較費電費流量，這個對當前智能機的消耗太大，在窄帶網路和不穩定的（手機）網路都不是最優的選擇。但總體來說，XMPP協議還是比較成熟的。

 

方案三、採用MQTT協議

MQTT是個輕量級的、基於代理的“發布/訂閱”模式的訊息傳輸協議。範例程式碼可以從https://github.com/tokudu/AndroidPushNotificationsDemo下載。MQTT的架構如下：

 

wmqtt.jar 是IBM提供的MQTT協議的實現。你可以從如下網站下載它。你可以將該jar包加入你自己的Android應用程式中。

Really Small Message Broker (RSMB) ，他是一個簡單的MQTT代理，同樣由IBM提供。預設開啟1883連接埠，應用程式當中，它負責接收來自伺服器的訊息並將其轉寄給指定的行動裝置。

MQTT協議也有自己的缺點：

協議複雜，部署成本比較高，還不夠成熟。

 

方案四、採用第三方服務

目前有不少第三方提供了類似服務，用戶端只需要嵌入第三方提供的lib庫，由第三方建立長串連，負責訊息的接收/發送。同時對於訊息都有比較詳細的報表資料，可以用於做資料分析挖掘和使用者體驗的改善。目前比較成熟的有：parse、pubnub、蝴蝶、個推等。國外的parse、pubnub做的很不錯，基本版也是免費的，但是國外的服務在國內經常訪問不了。國內的靠譜的不多，蝴蝶做的比較早，以前和機鋒網合作過推送，但現在不做了。個推的接入比較簡單，新浪微博android上的推送也是他們做的，但和parse比起來使用者體驗上還有待提升。