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