?cpu多核利用能夠實現Android推送的吞吐量。
講明白這點,我們需要了解Android推送的基本原理了。如果實現C(客戶端)與server(客戶端)實時通訊了。這里有兩種思路了:
1.一種是定時去server查詢數據,通常是使用HTTP協議來訪問web服務器,稱Polling(輪詢);
2.還有一種是移動端和服務器建立長連接,使用XMPP長連接,稱Push(推送)。(按照本人理解:客戶端的實現時:
while(true) {
? request(timeout);
? request(timeout);
}
客戶端發出一個“長”請求,如果服務器發送消息或者時間out了,客戶端就斷開這個請求,再建立一個長請求從耗費的電量、流量和數據延遲性各方面來說,Push有明顯的優勢。但是使用Push的缺點是:對于客戶端:實現和維護相對成本高,在移動無線網絡下維護長連接,相對有一些技術上的開發難度。對于服務器:如何實現多核并發,cpu作業調度,數量龐大的長連接并發維護等技術,仍存在開發難點。在講述Push方案的原理前,我們先了解一下移動無線網絡的特點。
移動無線網絡的特點:
因為 IP v4 的 IP 量有限,運營商分配給手機終端的 IP 是運營商內網的 IP,手機要連接 Internet,就需要通過運營商的網關做一個網絡地址轉換(Network Address Translation,NAT)。簡單的說運營商的網關需要維護一個外網 IP、端口到內網 IP、端口的對應關系,以確保內網的手機可以跟 Internet 的服務器通訊.如圖所示:
GGSN(Gateway GPRS Support Node 網關GPRS支持結點)模塊就實現了NAT功能。因為大部分移動無線網絡運營商都是為了減少網關的NAT映射表的負荷,所以如果發現鏈路中有一段時間沒有數據通訊時,會刪除其對應表,造成鏈路中斷。
Push在Android平臺上長連接的實現:
既然我們知道我們移動端要和Internet進行通信,必須通過運營商的網關,所以,為了不讓NAT映射表失效,我們需要定時向Internet發送數據,因為只是為了不然NAT映射表失效,所以只需發送長度為0的數據即可。注意這種定時發送的時間又叫心跳時間。 分析:
Timer:可以按照計劃或者時間周期來執行相關的任務。但是Timer需要用WakeLock來讓CPU保持喚醒狀態,才能保證任務的執行,這樣子會消耗大量流量;當CPU處于休眠的時候,就不能喚醒執行任務,所以應用于移動端明顯是不合適。
AlarmManager:AlarmManager類是屬于android系統封裝好來管理RTC模塊的管理類。這里就涉及到RTC模塊,要更好地了解兩者的區別,就要明白兩者真正的區別。
RTC(Real- Time Clock)實時鬧鐘在一個嵌入式系統中,通常采用RTC 來提供可靠的系統時間,包括時分秒和年月日等;而且要求在系統處于關機狀態下它也能夠正常工作(通常采用后備電池供電),它的外圍也不需要太多的輔助電路,典型的就是只需要一個高精度的32.768KHz 晶體和電阻電容等。(如果對這方面感興趣,可以自己查閱相關資料,這里就說個大概)
好了,回來正題。所以,AlarmManager又稱全局定時鬧鐘。這意味著,當我用使用AlarmManager來定時執行任務,CPU可以正常地休眠,只有在執行任務是,才喚醒CPU,這個過程是很短時間的。
下面簡單來說明其使用:
1.類似于Timer功能:
//獲得鬧鐘管理器
AlarmManager am = (AlarmManager)getSystemService(ALARM_SERVICE);
//設置任務執行計劃
am.setRepeating(AlarmManager.ELAPSED_REALTIME, firstTime, 5*1000, sender);//從firstTime才開始執行,每隔5秒再執行
2.實現全局定時功能:
//獲得鬧鐘管理器
AlarmManager am = (AlarmManager)getSystemService(ALARM_SERVICE);
//設置任務執行計劃
am.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, firstTime, 5*1000, sender);//從firstTime才開始執行,每隔5秒再執行
總結:在android客戶端使用Push推送時,應該使用AlarmManager來實現心跳功能,使其真正實現長連接。
在服務器端的實現:
在服務器端,可以使用很多語言來實現,如C/C++,java,Erlang等等,如我們國內比較好的極光推送(C開發),openfire(java開發)等等。
最近我看了極光推送的介紹和原理,下面我就說說他們是遇到什么難題,然后使用什么技術或者方案來解決呢。
當有大量的手機終端需要與服務器維持長連接時,對服務器的設計會是一個很大的挑戰。
假設一臺服務器維護10萬個長連接,當有1000萬用戶量時,需要有多達100臺的服務器來維護這些用戶的長連接,這里還不算用于做備份的服務器,這將會是一個巨大的成本問題。那就需要我們盡可能提高單臺服務器接入用戶的量,也就是業界已經討論很久了的 C10K 問題。
? ? ? 這是他們怎么做的了,他們是非常巧妙的利用cpu中多核的原理,利用多核來喚起了相應核數個線程了,并且利用非阻塞的消息隊列的機制,大大提高了服務器的吞吐量了,這樣能夠是一個服務器維持200個左右的長連接了,這樣有效突破了業界一個瓶頸了。可見多核實現了android消息推送重要性。相應的思維導圖如下:
?
?
這就是對android推送的分析。
?
?