申明：MobileIMSDK 目前為個(gè)人原創(chuàng)開源工程且已發(fā)布，現(xiàn)整理了一些有關(guān)MobileIMSDK的常見的問題，希望對(duì)需要的人有用，謝謝。如需與作者交流，見文章底部個(gè)人簽名處，互相學(xué)習(xí)。
MobileIMSDK工程的代碼托管地址請(qǐng)進(jìn)入 Git@OSC：點(diǎn)擊進(jìn)入
學(xué)習(xí)交流
- 討論學(xué)習(xí)和資料區(qū)：點(diǎn)此進(jìn)入 推薦
- 移動(dòng)端即時(shí)通訊交流群：
215891622 推薦 - bug/建議發(fā)送至：jb2011@163.com
- 技術(shù)支持/合作/咨詢請(qǐng)聯(lián)系作者QQ：413980957
【問題1】：MobileIMSDK到底是什么？有何價(jià)值？解決了哪些問題？
① 到底是什么？
純技術(shù)角度講：它是一整套基于UDP協(xié)議的客戶端A、服務(wù)端、客戶端B的3方全向即時(shí)通訊算法實(shí)現(xiàn)，超輕量級(jí)、高度提煉。
應(yīng)用層角度講：它是一組包含了Android客戶端庫、iOS客戶端庫、Java跨平臺(tái)客戶端庫和服務(wù)端庫的即時(shí)通訊SDK框架集。
更通俗一點(diǎn)講：它是一個(gè)專為移動(dòng)設(shè)備設(shè)計(jì)的跨設(shè)備、跨平臺(tái)、跨網(wǎng)絡(luò)的即時(shí)通訊開發(fā)框架，可用于（包含但不限于）開發(fā)聊天APP、企業(yè)OA、消息推送應(yīng)用等。
② 有何價(jià)值？
有過即時(shí)通訊應(yīng)用開發(fā)經(jīng)驗(yàn)的人都有體會(huì)，即時(shí)通訊應(yīng)用開發(fā)的難點(diǎn)不僅在于應(yīng)用層的業(yè)務(wù)邏輯實(shí)現(xiàn)，更重的要是需要穩(wěn)定、可靠、對(duì)應(yīng)用層友好的即時(shí)通訊核心層框架，否則應(yīng)用層的復(fù)雜邏輯再摻雜進(jìn)即時(shí)通訊通信技術(shù)本身的復(fù)雜性（在無線網(wǎng)絡(luò)普及的時(shí)代，問題更為突出），會(huì)讓經(jīng)驗(yàn)不足的開發(fā)團(tuán)隊(duì)陷入混亂。MobileIMSDK的價(jià)值在于：讓開發(fā)者專注于應(yīng)用邏輯的開發(fā)，底層復(fù)雜的即時(shí)通訊算法交由SDK開發(fā)人員，從而解偶即時(shí)通訊應(yīng)用開發(fā)的復(fù)雜性。
③ 解決了哪些問題？
- UDP協(xié)議實(shí)現(xiàn)，更符合現(xiàn)今的復(fù)雜移動(dòng)端網(wǎng)絡(luò)通信環(huán)境；
- 完善的QoS消息送達(dá)保證機(jī)制，解決了UDP通信時(shí)的消息黑洞問題；
- 解決了高延遲網(wǎng)絡(luò)環(huán)境下的2G、3G、4G、WiFi以及傳統(tǒng)寬帶的多端、多網(wǎng)混合通信可靠性和穩(wěn)定性問題；
- 擁有通信自動(dòng)治愈算法，無論無線信號(hào)多么惡劣，只要恢復(fù)通信，將自動(dòng)實(shí)現(xiàn)連接自我修復(fù)；
- 預(yù)定義多種耗電模式，在應(yīng)對(duì)不同通信場(chǎng)景的情況下，自主決定電量、網(wǎng)絡(luò)流量的消耗等；
- 易拆裝的協(xié)議封裝，可針對(duì)不同應(yīng)用場(chǎng)景，選擇適合的協(xié)議壓縮方案；
- 歷經(jīng)多個(gè)版本的錘煉，API高度封裝，在解決應(yīng)用層與即時(shí)通訊層代碼偶合的同時(shí)，能適應(yīng)更多應(yīng)用場(chǎng)景。
【問題2】：類似于MobileIMSDK的框架好開發(fā)嗎，有何難度？
老實(shí)講，想要開發(fā)出穩(wěn)定可靠且可用于生產(chǎn)環(huán)境的完整算法，并不容易（當(dāng)然，這只是個(gè)人觀點(diǎn)，如果你不這么認(rèn)為，至少說明你比本文作者強(qiáng)多了，呵呵），比較明顯的難點(diǎn)如下所述：
難點(diǎn)①：算法偶合性大、整合有難度
算法本身并無開創(chuàng)性，但雜合無線網(wǎng)絡(luò)的復(fù)雜性（不同制式、易受干擾等）、跨設(shè)備、跨平臺(tái)、跨網(wǎng)絡(luò)類型的混合通信， 這些要素和條件下，要實(shí)現(xiàn)的算法偶合性較大，加大了整合的難度。
難點(diǎn)②：算法需多平臺(tái)無差別精確實(shí)現(xiàn)、人員配備省不了
因需要支持不同平臺(tái)、多種要素和條件，要實(shí)現(xiàn)的算法不可謂不吹毛求疵，要求不算太高，但顯然沒有些許功底是不太容易搞定的，所以人員配備是個(gè)問題。
難點(diǎn)③：框架的提煉和把握需精準(zhǔn)、對(duì)上層友好是關(guān)鍵
能較高質(zhì)量地實(shí)現(xiàn)所謂“框架”的價(jià)值已然超越了算法本身，否則再牛逼的東西也只能孤芳自賞，所以對(duì)上層友好也很關(guān)鍵，簡(jiǎn)單的代碼堆砌顯然不可能達(dá)到目的。
難點(diǎn)④：時(shí)間上很難一蹴而就
在眾多要素和條件存在的前提下，未經(jīng)長(zhǎng)期的測(cè)試和針對(duì)性調(diào)優(yōu)，很難滿足實(shí)際應(yīng)用的品質(zhì)要求，時(shí)間上也是省不了的。
【問題3】：使用MobileIMSDK時(shí)如何獲得幫助？
【問題4】：MobileIMSDK定義了具體的聊天APP協(xié)議嗎？
沒有。MobileIMSDK有明確的設(shè)計(jì)目標(biāo)：即實(shí)現(xiàn)一個(gè)”專為移動(dòng)端開發(fā)，可應(yīng)用于跨設(shè)備的聊天APP、企業(yè)OA、消息推送等各種場(chǎng)景的高可重用即時(shí)通訊框架。“，所以為了提升MobileIMSDK的可重用性和靈活性，設(shè)計(jì)之初就特別回避了這一點(diǎn)。
這么設(shè)計(jì)帶來的好處是，比如當(dāng)MobileIMSDK應(yīng)用于企業(yè)OA時(shí)，因傳統(tǒng)企業(yè)應(yīng)用系統(tǒng)中，通常都有自已的用戶關(guān)系管理模型和實(shí)現(xiàn)，因而只需要將MobileIMSDK作為即時(shí)通訊消息路由子系統(tǒng)來使用即可，這樣的場(chǎng)景下事情本來就該這么簡(jiǎn)單。
當(dāng)然，您可以自已定義您的聊天APP協(xié)議細(xì)節(jié)，這也意味著您在開發(fā)時(shí)能擁有更高的靈活性。一個(gè)典型的基于MobileIMSDK的全功能聊天應(yīng)用APP案例：點(diǎn)此查看和試用。
【問題5】：MobileIMSDK為何是基于UDP協(xié)議實(shí)現(xiàn)？有何好處？
眾所周之，因?yàn)閁DP協(xié)議的無連接特性，比較明顯的好處有以下兩點(diǎn)：
好處①：同等服務(wù)器軟硬件條件下的更高效費(fèi)比
相比TCP協(xié)議，因UDP協(xié)議的無連接特性，可靈活調(diào)整即時(shí)通訊算法，從而達(dá)成在有限的軟硬件條件下能支持更多的同時(shí)在線數(shù)。
好處②：非常適合于網(wǎng)絡(luò)延遲較大、網(wǎng)絡(luò)環(huán)境復(fù)雜的場(chǎng)景
某款基于MobileIMSDK的應(yīng)用（點(diǎn)此查看它的非敏感運(yùn)營(yíng)數(shù)據(jù)）曾運(yùn)營(yíng)于高延遲、復(fù)雜的跨國(guó)、跨洲際網(wǎng)絡(luò)環(huán)境下（統(tǒng)計(jì)表明，此應(yīng)用的典型網(wǎng)絡(luò)環(huán)境里訪問一個(gè)http應(yīng)用的單向網(wǎng)絡(luò)平均延遲高達(dá)300ms以上，而同時(shí)段訪問國(guó)內(nèi)的主流門戶延遲約為30ms左右），應(yīng)用仍能正常保持較好的用戶體驗(yàn)。這也一定程度證明了MobileIMSDK在此場(chǎng)景下的穩(wěn)定性和可靠性。但假設(shè)此種情況下使用TCP協(xié)議，則協(xié)議層丟包和重傳情況會(huì)非常多，根據(jù)TCP協(xié)議的重傳算法指數(shù)退避原則，在某些情況下，因此而帶來的用戶體驗(yàn)災(zāi)難是無法控制的。
【問題6】：MobileIMSDK支持集群?jiǎn)幔?/span>
MobileIMSDK暫不支持集群（后緒版本有支持集群的計(jì)劃）。理論上，MobileIMSDK應(yīng)用于聊天APP時(shí)單機(jī)可負(fù)載的同時(shí)在線數(shù)可數(shù)十萬，應(yīng)用于推送場(chǎng)景下可達(dá)千萬級(jí)別，如果您的應(yīng)用能達(dá)到這樣的負(fù)載極限，總用戶數(shù)至少是百萬甚至千萬級(jí)別，相信一切技術(shù)問題都不再會(huì)是問題了。無論如何，任何同類技術(shù)的單機(jī)容量都會(huì)有頸，為了更高的負(fù)載和更好的伸縮性，大型應(yīng)用里集群當(dāng)然是必須的選擇。MobileIMSDK的壓力測(cè)試報(bào)告：點(diǎn)此查看。
【問題7】：MobileIMSDK支持TCP協(xié)議嗎？
目前不支持。MobileIMSDK設(shè)計(jì)之初，充分考慮了移動(dòng)互聯(lián)網(wǎng)的網(wǎng)絡(luò)復(fù)雜性和不可靠特性，最終選擇以UDP協(xié)議實(shí)現(xiàn)之，目前還沒有特別需要支持TCP協(xié)議的理由出現(xiàn)，當(dāng)然如您有好的建議和想法，歡迎交流和討論。
【問題8】：MobileIMSDK支持同一用戶名的多設(shè)備登陸嗎？
理論上MobileIMSDK的通訊不依賴于用戶名（服務(wù)端會(huì)為每一個(gè)登陸的客戶端分配一個(gè)唯一ID），因而同一用戶名在不同客戶端登陸時(shí)，通訊不受影響，但具體實(shí)現(xiàn)還依賴于應(yīng)用層是如果處理的。
【問題9】：客戶端后臺(tái)有心跳機(jī)制嗎？為何需要心跳機(jī)制？
MobileIMSDK的客戶端后臺(tái)有健壯的心跳機(jī)制，使用心跳機(jī)制的主要目的有3個(gè)：
目的①：刷新NAT路由的UDP端口老化時(shí)間
典型情況下廠商的NAT路由算法中UDP的端口老化時(shí)間約為300秒（當(dāng)然，具體數(shù)值由無線ISP或您的家用路由器廠商定義，很多情況下此時(shí)間可能會(huì)更短），如果沒有心跳機(jī)制，則您的客戶端將會(huì)因UDP端口老化而再也收不到消息。這顯然不是MobileIMSDK的問題，它是由網(wǎng)關(guān)設(shè)備的NAT路由算法所決定。
目的②：告訴服務(wù)端您的客戶端還“活著”
因?yàn)閁DP的無連接特性，心跳機(jī)制對(duì)于刷新服務(wù)端的在線列表是直接而有效的方案。
目的③：讓客戶端知道自已是否還處于“正常通信”狀態(tài)
導(dǎo)致客戶端與服務(wù)端無法通信的因素有很多，很難用有限且簡(jiǎn)單的代碼來判斷之。舉個(gè)例子：當(dāng)您的手機(jī)正常連接于您的家庭WiFi時(shí)，WiFi連接是正常的，但此時(shí)您的寬帶由于欠費(fèi)或其它原因根本就無法上網(wǎng)，此時(shí)如果沒有心跳機(jī)制，您的APP會(huì)認(rèn)為網(wǎng)絡(luò)正常，但卻無法完成數(shù)據(jù)的收發(fā)，因?yàn)楦揪蜕喜涣司W(wǎng)。