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