android 即時通訊 心跳
前言:現在的大多數移動端應用都有實時得到訊息的能力,簡單來說,有傳送訊息的主動權和接受訊息的被動權。例如:微信,QQ,天氣預報等等,相信好處和使用者體驗相信大家都知道吧。
提出問題:這種功能必須涉及client(客戶端)和server(伺服器),所以到底client如何和server實現實時連線通訊?
分析問題:這種功能實際上就是資料同步,同時要考慮手機本身、電量、網路流量等等限制因素,所以通常在移動端上有一下兩個解決方案:
1.一種是定時去server查詢資料,通常是使用HTTP協議來訪問web伺服器,稱Polling(輪詢);
2.還有一種是移動端和伺服器建立長連線,使用XMPP長連線,稱Push(推送)。
從耗費的電量、流量和資料延遲性各方面來說,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對映表的負荷,所以如果發現鏈路中有一段時間沒有資料通訊時,會刪除其對應表,造成鏈路中斷。(關於NAT的作用及其原理可以檢視我的另一篇博文:關於使用UDP(TCP)跨區域網,NAT穿透的心得)
Push在Android平臺上長連線的實現:
既然我們知道我們移動端要和Internet進行通訊,必須通過運營商的閘道器,所以,為了不讓NAT對映表失效,我們需要定時向Internet傳送資料,因為只是為了不然NAT對映表失效,所以只需傳送長度為0的資料即可。
這時候就要用到定時器,在android系統上,定時器通常有一下兩種:
1.java.util.Timer
2.android.app.AlarmManager
分析:
Timer:
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 問題。
C2000K
針對這個問題,他們專門成立了一個專案,命名為C2000K,顧名思義,他們的目標是單機維持200萬個長連線。最終他們採用了多訊息迴圈、非同步非阻塞的模型,在一臺雙核、24G記憶體的伺服器上,實現峰值維持超過300萬個長連線。
最後總結:
因為我最近用java在做一個PC、伺服器、android的即時通訊系統(說白了就是模仿QQ,後面希望有不同的功能)。我的原則是用別人的原理,自己來實現,這樣才更好深入瞭解一些框架。所以,估計難點是在通訊開發和伺服器上的開發,必須深刻了解多訊息迴圈、非同步非阻塞的模型。之後我會發表關於這方面的實現。
在現在的android平臺上,已經不是android單機的世界了(我不是說做單機遊戲沒有前途)。現在都是依靠發展蓬勃的網際網路來支撐整個IT體系,所以,要成為一個android應用開發高手,必須朝著android、硬體、雲服務這一體系來發展。