Android 心跳包心跳鏈接 如何實現android和服務器長鏈接呢？推送消息的原理

前言：如今的大多數移動端應用都有實時獲得消息的能力，簡單來講，有發送消息的主動權和接受消息的被動權。例如：微信，QQ，天氣預報等等，相信好處和用戶體驗相信你們都知道吧。

 

提出問題：這種功能必須涉及client（客戶端）和server（服務器），因此到底client如何和server實現實時鏈接通信？

 

分析問題：這種功能實際上就是數據同步，同時要考慮手機自己、電量、網絡流量等等限制因素，因此一般在移動端上有一下兩個解決方案:
1.一種是定時去server查詢數據，一般是使用HTTP協議來訪問web服務器，稱Polling（輪詢）；
2.還有一種是移動端和服務器創建長鏈接，使用XMPP長鏈接，稱Push（推送）。（按照本人理解：客戶端的實現時：

1 while(true) {
2 
3  request(timeout);
4 
5  request(timeout);
6 
7 }

 

客戶端發出一個「長」請求，若是服務器發送消息或者時間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映射表的負荷，因此若是發現鏈路中有一段時間沒有數據通信時，會刪除其對應表，形成鏈路中斷。（關於NAT的做用及其原理能夠查看個人另外一篇博文：關於使用UDP(TCP)跨局域網，NAT穿透的心得）
 
Push在Android平臺上長鏈接的實現：
既然咱們知道咱們移動端要和Internet進行通訊，必須經過運營商的網關，因此，爲了避免讓NAT映射表失效，咱們須要定時向Internet發送數據，由於只是爲了避免然NAT映射表失效，因此只需發送長度爲0的數據便可。

這時候就要用到定時器，在android系統上，定時器一般有一下兩種：
1.java.util.Timer
2.android.app.AlarmManager

分析：
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 問題。
C2000K


針對這個問題，他們專門成立了一個項目，命名爲C2000K，顧名思義，他們的目標是單機維持200萬個長鏈接。最終他們採用了多消息循環、異步非阻塞的模型，在一臺雙核、24G內存的服務器上，實現峯值維持超過300萬個長鏈接。




最後總結：
        由於我最近用java在作一個PC、服務器、android的即時通信系統（說白了就是模仿QQ，後面但願有不一樣的功能）。個人原則是用別人的原理，本身來實現，這樣才更好深刻了解一些框架。因此，估計難點是在通信開發和服務器上的開發，必須深入瞭解多消息循環、異步非阻塞的模型。以後我會發表關於這方面的實現。
       在如今的android平臺上，已經不是android單機的世界了（我不是說作單機遊戲沒有前途）。如今都是依靠發展蓬勃的互聯網來支撐整個IT體系，因此，要成爲一個android應用開發高手，必須朝着android、硬件、雲服務這一體系來發展。
參考文檔：http://blog.csdn.net/sunmenggmail/article/details/12008075