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

學習交流

• 討論學習和資料區(qū)：點此進入 ^推薦
• 移動端即時通訊交流群： 215891622 ^推薦
• bug/建議發(fā)送至：jb2011@163.com
• 技術支持/合作/咨詢請聯(lián)系作者QQ：413980957

【問題1】：MobileIMSDK到底是什么？有何價值？解決了哪些問題？

① 到底是什么？
純技術角度講：它是一整套基于UDP協(xié)議的客戶端A、服務端、客戶端B的3方全向即時通訊算法實現(xiàn)，超輕量級、高度提煉。
應用層角度講：它是一組包含了Android客戶端庫、iOS客戶端庫、java跨平臺客戶端庫和服務端庫的即時通訊SDK框架集。
更通俗一點講：它是一個專為移動設備設計的跨設備、跨平臺、跨網(wǎng)絡的即時通訊開發(fā)框架，可用于（包含但不限于）開發(fā)聊天APP、企業(yè)OA、消息推送應用等。

②  有何價值？
有過即時通訊應用開發(fā)經(jīng)驗的人都有體會，即時通訊應用開發(fā)的難點不僅在于應用層的業(yè)務邏輯實現(xiàn)，更重的要是需要穩(wěn)定、可靠、對應用層友好的即時通訊核心層框架，否則應用層的復雜邏輯再摻雜進即時通訊通信技術本身的復雜性（在無線網(wǎng)絡普及的時代，問題更為突出），會讓經(jīng)驗不足的開發(fā)團隊陷入混亂。MobileIMSDK的價值在于：讓開發(fā)者專注于應用邏輯的開發(fā)，底層復雜的即時通訊算法交由SDK開發(fā)人員，從而解偶即時通訊應用開發(fā)的復雜性。

③  解決了哪些問題？

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

【問題2】：類似于MobileIMSDK的框架好開發(fā)嗎，有何難度？

老實講，想要開發(fā)出穩(wěn)定可靠且可用于生產(chǎn)環(huán)境的完整算法，并不容易（當然，這只是個人觀點，如果你不這么認為，至少說明你比本文作者強多了，呵呵），比較明顯的難點如下所述：

難點①：算法偶合性大、整合有難度
算法本身并無開創(chuàng)性，但雜合無線網(wǎng)絡的復雜性（不同制式、易受干擾等）、跨設備、跨平臺、跨網(wǎng)絡類型的混合通信， 這些要素和條件下，要實現(xiàn)的算法偶合性較大，加大了整合的難度。

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

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

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

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

• 討論學習和資料區(qū)：點擊進入；
• 移動端即時通訊學習交流群：215891622 （更多QQ群點此進入）；
• bug和建議請發(fā)送至：jack.jiang@openmob.net 或 jb2011@163.com；
• 技術支持、技術合作或咨詢請聯(lián)系作者QQ：413980957。

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

沒有。MobileIMSDK有明確的設計目標：即實現(xiàn)一個”專為移動端開發(fā)，可應用于跨設備的聊天APP、企業(yè)OA、消息推送等各種場景的高可重用即時通訊框架。“，所以為了提升MobileIMSDK的可重用性和靈活性，設計之初就特別回避了這一點。

這么設計帶來的好處是，比如當MobileIMSDK應用于企業(yè)OA時，因傳統(tǒng)企業(yè)應用系統(tǒng)中，通常都有自已的用戶關系管理模型和實現(xiàn)，因而只需要將MobileIMSDK作為即時通訊消息路由子系統(tǒng)來使用即可，這樣的場景下事情本來就該這么簡單。

當然，您可以自已定義您的聊天APP協(xié)議細節(jié)，這也意味著您在開發(fā)時能擁有更高的靈活性。一個典型的基于MobileIMSDK的全功能聊天應用APP案例：點此查看和試用。

【問題5】：MobileIMSDK為何是基于UDP協(xié)議實現(xiàn)？有何好處？

眾所周之，因為UDP協(xié)議的無連接特性，比較明顯的好處有以下兩點：

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

好處②：非常適合于網(wǎng)絡延遲較大、網(wǎng)絡環(huán)境復雜的場景
某款基于MobileIMSDK的應用（點此查看它的非敏感運營數(shù)據(jù)）曾運營于高延遲、復雜的跨國、跨洲際網(wǎng)絡環(huán)境下（統(tǒng)計表明，此應用的典型網(wǎng)絡環(huán)境里訪問一個http應用的單向網(wǎng)絡平均延遲高達300ms以上，而同時段訪問國內的主流門戶延遲約為30ms左右），應用仍能正常保持較好的用戶體驗。這也一定程度證明了MobileIMSDK在此場景下的穩(wěn)定性和可靠性。但假設此種情況下使用TCP協(xié)議，則協(xié)議層丟包和重傳情況會非常多，根據(jù)TCP協(xié)議的重傳算法指數(shù)退避原則，在某些情況下，因此而帶來的用戶體驗災難是無法控制的。

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

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

【問題7】：MobileIMSDK支持TCP協(xié)議嗎？

目前不支持。MobileIMSDK設計之初，充分考慮了移動互聯(lián)網(wǎng)的網(wǎng)絡復雜性和不可靠特性，最終選擇以UDP協(xié)議實現(xiàn)之，目前還沒有特別需要支持TCP協(xié)議的理由出現(xiàn)，當然如您有好的建議和想法，歡迎交流和討論。

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

理論上MobileIMSDK的通訊不依賴于用戶名（服務端會為每一個登陸的客戶端分配一個唯一ID），因而同一用戶名在不同客戶端登陸時，通訊不受影響，但具體實現(xiàn)還依賴于應用層是如果處理的。

【問題9】：客戶端后臺有心跳機制嗎？為何需要心跳機制？

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

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

目的②：告訴服務端您的客戶端還“活著”
因為UDP的無連接特性，心跳機制對于刷新服務端的在線列表是直接而有效的方案。

目的③：讓客戶端知道自已是否還處于“正常通信”狀態(tài)
導致客戶端與服務端無法通信的因素有很多，很難用有限且簡單的代碼來判斷之。舉個例子：當您的手機正常連接于您的家庭WiFi時，WiFi連接是正常的，但此時您的寬帶由于欠費或其它原因根本就無法上網(wǎng)，此時如果沒有心跳機制，您的APP會認為網(wǎng)絡正常，但卻無法完成數(shù)據(jù)的收發(fā)，因為根本就上不了網(wǎng)。