首先簡單介紹一下Android消息推送的主要三種方式，如果你已經看過類似的文章，請直接忽略三種介紹。
1.使用SMS服務，即服務器端發送短信，然后手機客戶端監聽短信的廣播，然后對數據進行一定的處理，達到消息推送的目的。好處就是省電，省流量，但是運 營商會很費錢。畢竟發送短信都是需要金錢支持的，並且會有環境的限制。平板、或者用戶停機的情況下，就沒有辦法使用推送了。所以這種解決方案，僅僅是在某 些及其特殊的情況下(移動、聯通、電信這種公司)才會使用。
2.使用輪詢的方式來從網絡中主動獲取數據。費電、費流量。這種方式方便理解，實現也較為簡單（我們的近乎客戶端1.0就是這么實現推送的）。如果只是做 個Demo的情況下還是可以使用。但是作為正在運行的應用，不論你怎么優化，一般是會比較耗費流量的，畢竟一直在獲取網絡中的數據。
3.使用長連接的方式，一般來說，推送的主要數據，都是依賴於這種方式進行數據推送的。省流量、費電。簡單介紹一下原理，原理就是跟服務器端建立一條長時 間的數據流連接，手機客戶端一直在等待手機客戶端中的數據。因為連接是持續的，並且沒有數據流操作，所以網絡中的流量還是相對較為節省的。但是因為一直保 持網絡中的連接，所以這種消息推送，肯定是比較費電的。很多軟件就是這樣制作的。像蘋果、Android推薦使用的C2DM都是使用的這種模式（蘋果處理 的比較好的地方，是整個手機只是用一個連接，原本Android也想使用這種模式，無奈Google的服務器在美國，介於天朝防火牆的問題，這種推送會不 穩定）。但是這種模式下也會有一定的缺陷，在網絡不穩定的情況下（火車、公交車、開車都會造成網絡不穩定），Socket比較容易斷開。連接不穩定的情況 下。推送數據容易失敗。還是有不少推送的組件都是基於這種模式做的。
然后簡單介紹一下，近乎客戶端的消息推送的規划。在近乎客戶端中，應用到推送 的功能模塊並不是很多，有私信、通知、請求、即時聊天功能（正在規划中）。其中私信、通知、請求屬於非即時性需求，簡單的延遲個幾分鍾關系也不是很大（比 如說，你的同學在站點中AT了你，你在五分鍾之后才對他的這個動作處理，也沒有什么太大的問題），即時聊天屬於即時性功能（想想一下，你的老婆跟你說,想 你了，你過了二十分鍾之后才回一句，……）。這兩種是完全不同的兩種需求。本次我們只介紹前面那種。
分別介紹一下手機客戶端和服務器端要進行的處理，請一邊看圖一邊理解。
手 機客戶端要先詢問服務器是否允許Socket連接，不允許處理很簡單，直接使用輪詢的方式獲取數據。如果服務器端允許連接，那么就嘗試連接，並且檢測 Socket是否可用。如果長時間網絡不穩定，則側向與輪詢，並且檢測網絡環境是否穩定。等到網絡穩定的時候再使用Socket進行數據推送。
服務器端，首先檢測是否啟用了Socket，如果啟用了。就等待手機連接客戶端，等到客戶端連接之后將數據推送給手機。
這樣數據就可以較為正常的推送給手機客戶端了。
第一次寫。寫的不好，歡迎板磚