之前一直困擾着的android端推送服務這次終於解決了，這裏總結下android平臺下幾種消息推送方案以及這次所採用的策略。
方案一：使用GCM服務（Google Cloud Messaging）
簡介：Google在Android上標配了自己的推送GCM（Google Cloud Messageing），可以幫助開發人員給他們的Android應用程序發送數據。它是一個輕量級的消息，告訴Android應用程序有新的數據要獲取從服務器，或者它可能是一個消息，其中包含了4KB的payload data（像即時通訊這類應用程序可以直接使用該payload消息）。GCM服務處理排隊的消息，並把消息傳遞到目標設備上運行的Android應用程序。
優點：Google提供的服務、原生、簡單，無需實現和部署服務端。
缺點：
1.GCM要求Android系統必須是2.2以上的版本，所以對於不少2.2以前的系統沒法推送
2.國內服務不穩定。而且不少國內的終端廠商紛紛把Google的服務去掉，替換上自己的。
3.需要用戶綁定Google賬號，但不少國內用戶沒有Google賬號。
方案二：使用XMPP協議（Openfire + Spark + Smack）
簡介：XMPP是一種基於XML的協議，它繼承了在XML環境中靈活的發展性，有很強的可擴展性。包括上面講的GCM服務器底層也是採用XMPP協議封裝的。
優點：協議成熟、強大、可擴展性強、目前主要應用於許多聊天系統中，且已有開源的Java版的開發實例androidpn。
缺點：協議較複雜、冗餘（基於XML）、費流量、費電，部署硬件成本高。
而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協議（更多信息見： http://mqtt.org/）
簡介：輕量級的、基於代理的“發佈/訂閱”模式的消息傳輸協議。
優點：協議簡潔、小巧、可擴展性強、省流量、省電，目前已經應用到企業領域（參考： http://mqtt.org/software），且已有C++版的服務端組件rsmb。
缺點：不夠成熟、實現較複雜、服務端組件rsmb不開源，部署硬件成本較高。
方案四：使用HTTP輪循方式
簡介：定時向HTTP服務端接口（Web Service API）獲取最新消息。
優點：實現簡單、可控性強，部署硬件成本低。
缺點：實時性差。
方案五：採用第三方服務
目前有不少第三方提供了類似服務，客戶端只需要嵌入第三方提供的lib庫，由第三方建立長連接，負責消息的接收/發送。同時對於消息都有比較詳細的報表數據，可以用於做數據分析挖掘和用戶體驗的改善。目前國內提供推送服務的有好幾家，比較成熟的主要有百度雲推送, 極光推送, 個推服務。
還是出於對大公司的信任吧，所以這次選擇了百度的雲推送，總的來說官方文檔使用說明還是蠻詳細的。百度的雲推送共提供三種形式的推送：
1.頂部通知欄消息提醒，當然也是提供自定義；
2.消息，可以是無界面的，也可以是用戶自己定義的消息處理方式；
3.富媒體推送，如圖片，聲音等。
值得說明的是第一種提醒方式是比較常見的，這次的app中也是這種方式，但是SDK提供的這種頂部通知欄消息點擊事件每次都會重新打開一次app，哪怕之前你的app是打開過的。這種交互方法非常不友好，爲了解決這個問題試了很久也沒能找到相應的方法。
於是在第二種消息提醒方式時，才發現這種定製性更強，只是處理的時候有些麻煩。這裏客戶端拿到推送消息時手動處理使在頂部通知欄顯示，並把這些提醒信息保存進客戶端Sqlite文件裏，從而使交互更加友好。
當然基於以後的推送新的需求可能會涉及到富媒體推送之類的，以後用到時再看下實現方式。當然以後有機會也會了解下其他的推送服務，來了解各自推送服務的優劣，從而能確定一個最優的服務。
