前言：現(xiàn)在的大多數(shù)移動(dòng)端應(yīng)用都有實(shí)時(shí)得到消息的能力，簡(jiǎn)單來(lái)說(shuō)，有發(fā)送消息的主動(dòng)權(quán)和接受消息的被動(dòng)權(quán)。例如：微信，QQ，天氣預(yù)報(bào)等等，相信好處和用戶(hù)體驗(yàn)相信大家都知道吧。


提出問(wèn)題：這種功能必須涉及client（客戶(hù)端）和server（服務(wù)器），所以到底client如何和server實(shí)現(xiàn)實(shí)時(shí)連接通訊？


分析問(wèn)題：這種功能實(shí)際上就是數(shù)據(jù)同步，同時(shí)要考慮手機(jī)本身、電量、網(wǎng)絡(luò)流量等等限制因素，所以通常在移動(dòng)端上有一下兩個(gè)解決方案:
1.一種是定時(shí)去server查詢(xún)數(shù)據(jù)，通常是使用HTTP協(xié)議來(lái)訪問(wèn)web服務(wù)器，稱(chēng)Polling（輪詢(xún)）；
2.還有一種是移動(dòng)端和服務(wù)器建立長(zhǎng)連接，使用XMPP長(zhǎng)連接，稱(chēng)Push（推送）。

從耗費(fèi)的電量、流量和數(shù)據(jù)延遲性各方面來(lái)說(shuō)，Push有明顯的優(yōu)勢(shì)。但是使用Push的缺點(diǎn)是：
對(duì)于客戶(hù)端：實(shí)現(xiàn)和維護(hù)相對(duì)成本高，在移動(dòng)無(wú)線網(wǎng)絡(luò)下維護(hù)長(zhǎng)連接，相對(duì)有一些技術(shù)上的開(kāi)發(fā)難度。
對(duì)于服務(wù)器：如何實(shí)現(xiàn)多核并發(fā)，cpu作業(yè)調(diào)度，數(shù)量龐大的長(zhǎng)連接并發(fā)維護(hù)等技術(shù)，仍存在開(kāi)發(fā)難點(diǎn)。

在講述Push方案的原理前，我們先了解一下移動(dòng)無(wú)線網(wǎng)絡(luò)的特點(diǎn)。
移動(dòng)無(wú)線網(wǎng)絡(luò)的特點(diǎn)：
因?yàn)?IP v4 的 IP 量有限，運(yùn)營(yíng)商分配給手機(jī)終端的 IP 是運(yùn)營(yíng)商內(nèi)網(wǎng)的 IP，手機(jī)要連接 Internet，就需要通過(guò)運(yùn)營(yíng)商的網(wǎng)關(guān)做一個(gè)網(wǎng)絡(luò)地址轉(zhuǎn)換（Network Address Translation，NAT）。簡(jiǎn)單的說(shuō)運(yùn)營(yíng)商的網(wǎng)關(guān)需要維護(hù)一個(gè)外網(wǎng) IP、端口到內(nèi)網(wǎng) IP、端口的對(duì)應(yīng)關(guān)系，以確保內(nèi)網(wǎng)的手機(jī)可以跟 Internet 的服務(wù)器通訊
?
原理圖如下：

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

GGSN（Gateway GPRS Support Node 網(wǎng)關(guān)GPRS支持結(jié)點(diǎn)）模塊就實(shí)現(xiàn)了NAT功能。
因?yàn)榇蟛糠忠苿?dòng)無(wú)線網(wǎng)絡(luò)運(yùn)營(yíng)商都是為了減少網(wǎng)關(guān)的NAT映射表的負(fù)荷，所以如果發(fā)現(xiàn)鏈路中有一段時(shí)間沒(méi)有數(shù)據(jù)通訊時(shí)，會(huì)刪除其對(duì)應(yīng)表，造成鏈路中斷。（關(guān)于NAT的作用及其原理可以查看我的另一篇博文：關(guān)于使用UDP(TCP)跨局域網(wǎng)，NAT穿透的心得）
?
Push在Android平臺(tái)上長(zhǎng)連接的實(shí)現(xiàn)：
既然我們知道我們移動(dòng)端要和Internet進(jìn)行通信，必須通過(guò)運(yùn)營(yíng)商的網(wǎng)關(guān)，所以，為了不讓NAT映射表失效，我們需要定時(shí)向Internet發(fā)送數(shù)據(jù)，因?yàn)橹皇菫榱瞬蝗籒AT映射表失效，所以只需發(fā)送長(zhǎng)度為0的數(shù)據(jù)即可。

這時(shí)候就要用到定時(shí)器，在android系統(tǒng)上，定時(shí)器通常有一下兩種：
1.java.util.Timer
2.android.app.AlarmManager

分析：
Timer:可以按照計(jì)劃或者時(shí)間周期來(lái)執(zhí)行相關(guān)的任務(wù)。但是Timer需要用WakeLock來(lái)讓CPU保持喚醒狀態(tài)，才能保證任務(wù)的執(zhí)行，這樣子會(huì)消耗大量流量；當(dāng)CPU處于休眠的時(shí)候，就不能喚醒執(zhí)行任務(wù)，所以應(yīng)用于移動(dòng)端明顯是不合適。

AlarmManager：AlarmManager類(lèi)是屬于android系統(tǒng)封裝好來(lái)管理RTC模塊的管理類(lèi)。這里就涉及到RTC模塊，要更好地了解兩者的區(qū)別，就要明白兩者真正的區(qū)別。
RTC（Real- Time Clock）實(shí)時(shí)鬧鐘在一個(gè)嵌入式系統(tǒng)中，通常采用RTC 來(lái)提供可靠的系統(tǒng)時(shí)間，包括時(shí)分秒和年月日等;而且要求在系統(tǒng)處于關(guān)機(jī)狀態(tài)下它也能夠正常工作（通常采用后備電池供電），它的外圍也不需要太多的輔助電路，典型的就是只需要一個(gè)高精度的32.768KHz 晶體和電阻電容等。（如果對(duì)這方面感興趣，可以自己查閱相關(guān)資料，這里就說(shuō)個(gè)大概）
好了，回來(lái)正題。所以，AlarmManager又稱(chēng)全局定時(shí)鬧鐘。這意味著，當(dāng)我用使用AlarmManager來(lái)定時(shí)執(zhí)行任務(wù)，CPU可以正常地休眠，只有在執(zhí)行任務(wù)是，才喚醒CPU，這個(gè)過(guò)程是很短時(shí)間的。
下面簡(jiǎn)單來(lái)說(shuō)明其使用：
1.類(lèi)似于Timer功能：
//獲得鬧鐘管理器
AlarmManager am = (AlarmManager)getSystemService(ALARM_SERVICE);
//設(shè)置任務(wù)執(zhí)行計(jì)劃
am.setRepeating(AlarmManager.ELAPSED_REALTIME, firstTime, 5*1000, sender);//從firstTime才開(kāi)始執(zhí)行，每隔5秒再執(zhí)行

2.實(shí)現(xiàn)全局定時(shí)功能：
//獲得鬧鐘管理器
AlarmManager am = (AlarmManager)getSystemService(ALARM_SERVICE);
//設(shè)置任務(wù)執(zhí)行計(jì)劃
am.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, firstTime, 5*1000, sender);//從firstTime才開(kāi)始執(zhí)行，每隔5秒再執(zhí)行

總結(jié)：在android客戶(hù)端使用Push推送時(shí)，應(yīng)該使用AlarmManager來(lái)實(shí)現(xiàn)心跳功能，使其真正實(shí)現(xiàn)長(zhǎng)連接。


在服務(wù)器端的實(shí)現(xiàn)：
在服務(wù)器端，可以使用很多語(yǔ)言來(lái)實(shí)現(xiàn)，如C/C++,java,Erlang等等，如我們國(guó)內(nèi)比較好的極光推送（C開(kāi)發(fā)）,openfire(java開(kāi)發(fā))等等。
最近我看了極光推送的介紹和原理，下面我就說(shuō)說(shuō)他們是遇到什么難題，然后使用什么技術(shù)或者方案來(lái)解決呢。

當(dāng)有大量的手機(jī)終端需要與服務(wù)器維持長(zhǎng)連接時(shí)，對(duì)服務(wù)器的設(shè)計(jì)會(huì)是一個(gè)很大的挑戰(zhàn)。


假設(shè)一臺(tái)服務(wù)器維護(hù)10萬(wàn)個(gè)長(zhǎng)連接，當(dāng)有1000萬(wàn)用戶(hù)量時(shí)，需要有多達(dá)100臺(tái)的服務(wù)器來(lái)維護(hù)這些用戶(hù)的長(zhǎng)連接，這里還不算用于做備份的服務(wù)器，這將會(huì)是一個(gè)巨大的成本問(wèn)題。那就需要我們盡可能提高單臺(tái)服務(wù)器接入用戶(hù)的量，也就是業(yè)界已經(jīng)討論很久了的 C10K 問(wèn)題。
C2000K


針對(duì)這個(gè)問(wèn)題，他們專(zhuān)門(mén)成立了一個(gè)項(xiàng)目，命名為C2000K，顧名思義，他們的目標(biāo)是單機(jī)維持200萬(wàn)個(gè)長(zhǎng)連接。最終他們采用了多消息循環(huán)、異步非阻塞的模型，在一臺(tái)雙核、24G內(nèi)存的服務(wù)器上，實(shí)現(xiàn)峰值維持超過(guò)300萬(wàn)個(gè)長(zhǎng)連接。




最后總結(jié)：
? ? ? ? 因?yàn)槲易罱胘ava在做一個(gè)PC、服務(wù)器、android的即時(shí)通訊系統(tǒng)（說(shuō)白了就是模仿QQ，后面希望有不同的功能）。我的原則是用別人的原理，自己來(lái)實(shí)現(xiàn)，這樣才更好深入了解一些框架。所以，估計(jì)難點(diǎn)是在通訊開(kāi)發(fā)和服務(wù)器上的開(kāi)發(fā)，必須深刻了解多消息循環(huán)、異步非阻塞的模型。之后我會(huì)發(fā)表關(guān)于這方面的實(shí)現(xiàn)。
? ? ? ?在現(xiàn)在的android平臺(tái)上，已經(jīng)不是android單機(jī)的世界了（我不是說(shuō)做單機(jī)游戲沒(méi)有前途）。現(xiàn)在都是依靠發(fā)展蓬勃的互聯(lián)網(wǎng)來(lái)支撐整個(gè)IT體系，所以，要成為一個(gè)android應(yīng)用開(kāi)發(fā)高手，必須朝著android、硬件、云服務(wù)這一體系來(lái)發(fā)展。

總結(jié)

以上是生活随笔為你收集整理的如何实现android和服务器长连接呢？推送消息的原理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。