【原創】輕量級移動設備即時通信技術MobileIMSDK的常見問題解答

 

---

申明：MobileIMSDK 目前爲我的原創開源工程且已發佈，現整理了一些有關MobileIMSDK的常見的問題，但願對須要的人有用，謝謝。如需與做者交流，見文章底部我的簽名處，互相學習。 

---

MobileIMSDK工程的代碼託管地址請進入 Git@OSC：點擊進入 

學習交流

• 討論學習和資料區：點此進入 ^推薦
• 移動端即時通信交流羣： 215891622 ^推薦
• bug/建議發送至：jb2011@163.com
• 技術支持/合做/諮詢請聯繫做者QQ：413980957

 

【問題1】：MobileIMSDK究竟是什麼？有何價值？解決了哪些問題？

① 究竟是什麼？
純技術角度講：它是一整套基於UDP協議的客戶端A、服務端、客戶端B的3方全向即時通信算法實現，超輕量級、高度提煉。
應用層角度講：它是一組包含了Android客戶端庫、iOS客戶端庫、Java跨平臺客戶端庫和服務端庫的即時通信SDK框架集。
更通俗一點講：它是一個專爲移動設備設計的跨設備、跨平臺、跨網絡的即時通信開發框架，可用於（包含但不限於）開發聊天APP、企業OA、消息推送應用等。

②  有何價值？
有過即時通信應用開發經驗的人都有體會，即時通信應用開發的難點不只在於應用層的業務邏輯實現，更重的要是須要穩定、可靠、對應用層友好的即時通信核心層框架，不然應用層的複雜邏輯再摻雜進即時通信通訊技術自己的複雜性（在無線網絡普及的時代，問題更爲突出），會讓經驗不足的開發團隊陷入混亂。MobileIMSDK的價值在於：讓開發者專一於應用邏輯的開發，底層複雜的即時通信算法交由SDK開發人員，從而解偶即時通信應用開發的複雜性。

③  解決了哪些問題？

• UDP協議實現，更符合現今的複雜移動端網絡通訊環境；
• 完善的QoS消息送達保證機制，解決了UDP通訊時的消息黑洞問題；
• 解決了高延遲網絡環境下的2G、3G、4G、WiFi以及傳統寬帶的多端、多網混合通訊可靠性和穩定性問題；
• 擁有通訊自動治癒算法，不管無線信號多麼惡劣，只要恢復通訊，將自動實現鏈接自我修復；
• 預約義多種耗電模式，在應對不一樣通訊場景的狀況下，自主決定電量、網絡流量的消耗等；
• 易拆裝的協議封裝，可針對不一樣應用場景，選擇適合的協議壓縮方案；
• 歷經多個版本的錘鍊，API高度封裝，在解決應用層與即時通信層代碼偶合的同時，能適應更多應用場景。

 

【問題2】：相似於MobileIMSDK的框架好開發嗎，有何難度？

老實講，想要開發出穩定可靠且可用於生產環境的完整算法，並不容易（固然，這只是我的觀點，若是你不這麼認爲，至少說明你比本文做者強多了，呵呵），比較明顯的難點以下所述：

難點①：算法偶合性大、整合有難度
算法自己並沒有開創性，但雜合無線網絡的複雜性（不一樣制式、易受干擾等）、跨設備、跨平臺、跨網絡類型的混合通訊， 這些要素和條件下，要實現的算法偶合性較大，加大了整合的難度。

難點②：算法需多平臺無差異精確實現、人員配備省不了
因須要支持不一樣平臺、多種要素和條件，要實現的算法不可謂不吹毛求疵，要求不算過高，但顯然沒有些許功底是不太容易搞定的，因此人員配備是個問題。

難點③：框架的提煉和把握需精準、對上層友好是關鍵
能較高質量地實現所謂「框架」的價值已然超越了算法自己，不然再牛逼的東西也只能孤芳自賞，因此對上層友好也很關鍵，簡單的代碼堆砌顯然不可能達到目的。

難點④：時間上很難一蹴而就
在衆多要素和條件存在的前提下，未經長期的測試和針對性調優，很難知足實際應用的品質要求，時間上也是省不了的。

 

【問題3】：使用MobileIMSDK時如何得到幫助？

• 討論學習和資料區：點擊進入；
• 移動端即時通信學習交流羣：215891622 （更多QQ羣點此進入）；
• bug和建議請發送至：jack.jiang@openmob.net 或 jb2011@163.com；
• 技術支持、技術合做或諮詢請聯繫做者QQ：413980957。

 

【問題4】：MobileIMSDK定義了具體的聊天APP協議嗎？

沒有。MobileIMSDK有明確的設計目標：即實現一個」專爲移動端開發，可應用於跨設備的聊天APP、企業OA、消息推送等各類場景的高可重用即時通信框架。「，因此爲了提高MobileIMSDK的可重用性和靈活性，設計之初就特別迴避了這一點。

這麼設計帶來的好處是，好比當MobileIMSDK應用於企業OA時，因傳統企業應用系統中，一般都有自已的用戶關係管理模型和實現，於是只須要將MobileIMSDK做爲即時通信消息路由子系統來使用便可，這樣的場景下事情原本就該這麼簡單。

固然，您能夠自已定義您的聊天APP協議細節，這也意味着您在開發時能擁有更高的靈活性。一個典型的基於MobileIMSDK的全功能聊天應用APP案例：點此查看和試用。

 

【問題5】：MobileIMSDK爲什麼是基於UDP協議實現？有何好處？

衆所周之，由於UDP協議的無鏈接特性，比較明顯的好處有如下兩點：

好處①：同等服務器軟硬件條件下的更高效費比
相比TCP協議，因UDP協議的無鏈接特性，可靈活調整即時通信算法，從而達成在有限的軟硬件條件下能支持更多的同時在線數。

好處②：很是適合於網絡延遲較大、網絡環境複雜的場景
某款基於MobileIMSDK的應用（點此查看它的非敏感運營數據）曾運營於高延遲、複雜的跨國、跨洲際網絡環境下（統計代表，此應用的典型網絡環境裏訪問一個http應用的單向網絡平均延遲高達300ms以上，而同時段訪問國內的主流門戶延遲約爲30ms左右），應用仍能正常保持較好的用戶體驗。這也必定程度證實了MobileIMSDK在此場景下的穩定性和可靠性。但假設此種狀況下使用TCP協議，則協議層丟包和重傳狀況會很是多，根據TCP協議的重傳算法指數退避原則，在某些狀況下，所以而帶來的用戶體驗災難是沒法控制的。

 

【問題6】：MobileIMSDK支持集羣嗎？

MobileIMSDK暫不支持集羣（後緒版本有支持集羣的計劃）。理論上，MobileIMSDK應用於聊天APP時單機可負載的同時在線數可數十萬，應用於推送場景下可達千萬級別，若是您的應用能達到這樣的負載極限，總用戶數至少是百萬甚至千萬級別，相信一切技術問題都再也不會是問題了。不管如何，任何同類技術的單機容量都會有頸，爲了更高的負載和更好的伸縮性，大型應用裏集羣固然是必須的選擇。MobileIMSDK的壓力測試報告：點此查看。

 

【問題7】：MobileIMSDK支持TCP協議嗎？

目前不支持。MobileIMSDK設計之初，充分考慮了移動互聯網的網絡複雜性和不可靠特性，最終選擇以UDP協議實現之，目前尚未特別須要支持TCP協議的理由出現，固然如您有好的建議和想法，歡迎交流和討論。

 

【問題8】：MobileIMSDK支持同一用戶名的多設備登錄嗎？

理論上MobileIMSDK的通信不依賴於用戶名（服務端會爲每個登錄的客戶端分配一個惟一ID），於是同一用戶名在不一樣客戶端登錄時，通信不受影響，但具體實現還依賴於應用層是若是處理的。

 

【問題9】：客戶端後臺有心跳機制嗎？爲什麼須要心跳機制？

MobileIMSDK的客戶端後臺有健壯的心跳機制，使用心跳機制的主要目的有3個：

目的①：刷新NAT路由的UDP端口老化時間
典型狀況下廠商的NAT路由算法中UDP的端口老化時間約爲300秒（固然，具體數值由無線ISP或您的家用路由器廠商定義，不少狀況下此時間可能會更短），若是沒有心跳機制，則您的客戶端將會因UDP端口老化而再也收不到消息。這顯然不是MobileIMSDK的問題，它是由網關設備的NAT路由算法所決定。

目的②：告訴服務端您的客戶端還「活着」
由於UDP的無鏈接特性，心跳機制對於刷新服務端的在線列表是直接而有效的方案。

目的③：讓客戶端知道自已經是否還處於「正常通訊」狀態致使客戶端與服務端沒法通訊的因素有不少，很難用有限且簡單的代碼來判斷之。舉個例子：當您的手機正常鏈接於您的家庭WiFi時，WiFi鏈接是正常的，但此時您的寬帶因爲欠費或其它緣由根本就沒法上網，此時若是沒有心跳機制，您的APP會認爲網絡正常，但卻沒法完成數據的收發，由於根本就上不了網。