一、使用GCM(Google Cloude Messaging)
Android自帶的推送GCM可以幫助開發人員給他們的Android應用程序發送數據。它是一個輕量級的消息，告訴Android應用程序有新的數據要從服務器獲取，或者它可能是一個消息，其中包含了4KB的payload data（像即時通訊這類應用程序可以直接使用該payload消息）。GCM服務處理排隊的消息，並把消息傳遞到目標設備上運行的Android應用程序。
優點：Google提供的服務、原生、簡單，無需實現和部署服務端。
缺點：1.要求Android 2.2以上，對於不少2.2以前的系統沒法推送；
2.國內服務不穩定。而且不少國內的終端廠商紛紛把Google的服務去掉，替換上自己的。
3.需要用戶綁定Google賬號，但不少國內用戶沒有Google賬號。
二、使用XMPP協議（Openfire+Spark+Smark）
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 分別是服務器和客戶端的代碼。詳細的實現方式網上有不少文章。
1.androidpn服務端重啓後客戶端不會重連，這個非常悲劇
2.由於服務器不保存消息，造成了如果客戶端當前離線就收不到消息
3.androidpn發送完消息就不管了，所以沒有消息回執報表之類，造成沒法做應用後續的數據分析用戶體驗的改善，這對於企業級的應用是個致命傷。
XMPP協議比較費電費流量，這個對當前智能機的消耗太大，在窄帶網絡和不穩定的（手機）網絡都不是最優的選擇。但總體來說，XMPP協議還是比較成熟的。
三、使用MQTT協議（想了解更多可以看http://mqtt.org/）
輕量級的、基於代理的“發佈/訂閱”模式的消息傳輸協議。
優點：協議簡潔、小巧、可擴展性強、省流量、省電，目前已經應用到企業領域（參考： http://mqtt.org/software），且已有C++版的服務端組件rsmb。
缺點：不夠成熟、實現較複雜、服務端組件rsmb不開源，部署硬件成本較高。
四、HTTP輪循方式
定時向HTTP服務端接口（Web Service API）獲取最新消息。
優點：實現簡單、可控性強，部署硬件成本低。
缺點：實時性差。
五、採用第三方服務
就是前面介紹的第三方推送，客戶端只需要導入第三方提供的lib庫，有第三方管理長連接，負責消息的接收/發送。同時對消息都有比較詳細的報表數據，可以用於做數據分析、挖掘，改善用戶體驗。
定義
在用戶未打開App時，App主動向用戶推送服務器最新消息。如下圖：
消息推送的本質是：App將服務器更新的信息推送給用戶
作用
- 產品的角度：功能需要，比如說資訊類產品的新聞推送、工具類產品的公告推送等等
- 運營的角度：活動運營需要，比如說電商類產品的促銷活動；召回用戶 / 提高活躍度等等
技術的角度：作爲開發者，不要有需求就接，應該多思考、多理解用戶 / 功能的使用場景，有助於我們更好地去選擇合適的開發方式
儲備知識
3.1 操作系統有自身的消息推送功能（系統級別）
- 系統級別：任何時候都可以推送給用戶，且不會被系統殺死
- Android的消息推送服務稱爲：C2DM（Cloudto Device Messaging）
將在下面詳細描述
3.2 推送的本質與原理
- 消息推送的本質是：App將服務器更新的信息推送給用戶，即App獲取服務器信息，再推送給用戶
- App從服務器獲取最新消息的基本方式（原理）有3種：Push、Pull 和 SMS
- 具體如下
