Android用戶端訊息推送原理簡介

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

    分別介紹一下手機用戶端和伺服器端要進行的處理，請一邊看圖一邊理解。
手機用戶端要先詢問伺服器是否允許Socket串連，不允許處理很簡單，直接使用輪詢的方式擷取資料。如果伺服器端允許串連，那麼就嘗試串連，並且檢測Socket是否可用。如果長時間網路不穩定，則側向與輪詢，並且檢測網路環境是否穩定。等到網路穩定的時候再使用Socket進行資料推送。
    伺服器端，首先檢測是否啟用了Socket，如果啟用了。就等待手機串連用戶端，等到用戶端串連之後將資料推送給手機。
這樣資料就可以較為正常的推送給手機用戶端了。

第一次寫。寫的不好，歡迎板磚