申明：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時如何獲得幫助？
【問題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會認為網絡正常，但卻無法完成數據的收發，因為根本就上不了網。