簡述移動端IM開發的那些坑：架構設計、通信協定和用戶端

1、前言

有過移動端開發經曆的開發者都深有體會：移動端IM的開發，與傳統PC端IM有很大的不同，尤其無線網絡的不可靠性、移動端硬體裝置資源的有限性等問題，導緻一個完整的移動端IM架構設計和實作都充滿着大量的挑戰。本文将簡述移動端IM最重要的架構設計和通信協定選擇方面的坑點，希望為IM開發者同行帶來些許啟發。（本文同步釋出于：

http://www.52im.net/thread-289-1-1.html

）

2、學習交流

- 即時通訊開發交流群：

215891622

[推薦]

- 移動端IM開發推薦文章：《

新手入門一篇就夠：從零開發移動端IM

》

3、概述

移動網際網路時代的來臨促使我們所有的開發者都要從使用者視角出發，基于某一特定場景來建立應用，滿足使用者需求。通常，在這些應用中，溝通環節都是必不可少的。這就要求創業者不僅要花時間和精力來琢磨使用者在某一特定場景下有何痛點需求，琢磨如何解決這一需求，并且可能還要花費更多的精力和時間來解決産品中“溝通”這一技術節點。

而要解決溝通問題，就需要一套IM系統（而且肯定要支援移動端）。做為IM開發者或即将成為IM開發者的技術人員，IM的價值和重要性不言自明。但從技術實作來說，這并不容易。當然，假設你有100個使用者，什麼都是容易的，但是假設你有了100萬、1000萬甚至1億的使用者，再簡單的技術節點解決不好，都會成為災難，何況IM系統（尤其是移動端的IM系統）還是存在許多技術難點和坑點的。

4、有關移動端IM通信協定的坑

其次，我們再看一下IM 協定如何選型。通常IM采取的協定有xmpp、mqtt、protobuf等資料通信私有協定，我們來逐一分析他們的優缺點。

1.  XMPP協定：

優點：基于xml協定，容易了解，使用廣泛，易于擴充。

缺點：流量大，在移動終端也耗電。互動過程複雜。多被pc時代的産品使用，不适合移動時代的IM産品，即使我們基于xmpp進行改進，簡化握手過程，改進檔案傳輸機制，但是它的基因決定了如何改進，他都不适合移動網際網路時代的IM産品。就像鳳姐無論怎麼整容，也變成不了高圓圓一樣。

2.  MQTT協定：

優點：适配多平台。

缺點：協定簡單，但是需要自己擴充好友，群組等功能。

3.  私有協定：

優點：随心所欲，自己定義，流量小。

缺點：工作量巨大，擴充性差，需要考慮全面。

4. Protobuf協定：

優點：非常小、非常快、非常簡單，一條消息資料用Protobuf序列化後的大小是JSON的1/10、XML格式的1/20、是二進制序列化的1/10。

缺點：不能表示複雜的資料結構，但是對于IM來講，已經足夠。強烈推薦此協定。

補充1：強列建議使用Protobuf，理由如下

靈活、高效：靈活（友善接口更新）、高效（效率經過google的優化，傳輸效率比普通的XML等高很多）；

易于使用：開發人員通過按照一定的文法定義結構化的消息格式，然後送給指令行工具，工具将自動生成相關的類，可以支援java、c++、python等語言環境。通過将這些類包含在項目中，可以很輕松的調用相關方法來完成業務消息的序列化與反序列化工作。

語言支援：原生支援c++、java、python等多達10餘種語言。

補充2：Protobuf主要适用于

需要和其它系統做消息交換的，對消息大小很敏感的。那麼protobuf适合了，它語言無關，消息空間相對xml和json等節省很多。

小資料的場合。如果你是大資料，用它并不适合。

項目語言是c++、java、python等，因為它們可以使用google的源生類庫，序列化和反序列化的效率非常高。其它的語言需要第三方或者自己寫，序列化和反序列化的效率不保證。

總體而言，Protobuf還是非常好用的，被很多開源系統用于資料通信的工具，在google也是核心的基礎庫。

（更多文章：《

強列建議将Protobuf作為你的即時通訊應用資料傳輸格式

》、《

如何選擇即時通訊應用的資料傳輸格式 理論聯系實際：一套典型的IM通信協定設計詳解

》）

5、移動端IM用戶端的坑

最後，我們再來了解一下移動端有哪些難點需要解決。

1.  流量：

采取哪種協定、圖檔縮略圖、附件的壓縮三點決定了流量的大小。

2. 耗電：

(1)流量越小，耗電越低。(2)心跳政策，減少心跳次數，耗電量就會降低。

3. 心跳時長：

wifi，2G，3G，4G，移動、電信、聯通,不同網絡，不同運作商，NAT失效時間不一樣，是以心跳的時間也就不一樣。

4. 網絡連接配接：

cmnet和cmwap下連接配接處理機制。

5. 網絡不穩定：

移動端最大的特點就是網絡不穩定，在不穩定的網絡狀态下，如何保證消息以最快的速度到達？如何避免重聯風暴？這些既需要從整體架構考慮，也需要在移動端采取巧妙的政策加以避免。

（更多文章：

移動端IM開發需要面對的技術問題

6、移動端IM架構設計的坑

首先，來看移動端IM架構設計需要考慮的問題。

1. 連接配接器的設計：

連接配接器主要用來管理用戶端的長連接配接。目前最好的連接配接器單台8G8核的伺服器可以做到70萬—100萬的連接配接，而某些開發者隻能做到4000左右的連接配接，相差好幾個數量級。這裡的奧妙在哪裡呢？

2. 中間件的設計：

是否采用通訊中間件？通訊中間件的好處有哪些？如果不采用中間件，連接配接器和邏輯伺服器的連接配接關系如何管理呢？

3. 邏輯伺服器：

邏輯伺服器通常簡單一點，主要是根據業務邏輯進行最小粒度的劃分即可。但是即便如此，還是有很多的開發者把看似相關實則不相關的邏輯放在一起，如把鑒權和message伺服器放在一起。

4. 狀态伺服器：

狀态伺服器主要管理使用者線上、離線的相關狀态，需要采取中心節點的方案，否則狀态就會不同步。這裡主要需要考慮狀态伺服器所對應的資料存儲機制，如何進行寫操作，如何進行讀操作？以便最大的提高狀态伺服器的處理能力和響應速度。

5. 資料庫的設計：

資料庫的設計是最難的，也是做大的瓶頸。因為無論對于sql（關系型）資料庫還是nosql（非關系型）資料庫，都有讀寫處理的極限，那就需要考慮資料庫如何分區（根據什麼原則、什麼操作、哪些使用者通路哪個節點上的資料庫）。同時又需要考慮每個原子操作（如登陸）需要讀哪些庫，寫哪些庫。隻有這些名額明确了，你才能在假設有100萬并發使用者，100萬條并發消息的情況下，準确評估服務端需要多少台伺服器，如何部署。

6. 其他：

還有裝置推送的處理，何種機制能夠保證不丢消息，離線消息如何處理，等等。這些都是必備而又非常複雜的功能點和技術要求，都需要采取正确的架構和政策才能實作。

http://www.52im.net/forum.php?mod=collection&action=view&ctid=7

7、結語

以上難點和坑點草草記錄下來也不過千把字，但是真正要解決這些問題并達到生産應用标準，卻要不知道花費多少日日夜夜、敲下多少行代碼，恐怕也隻有真正做過IM的開發者才有比較深刻的體會。（本文同步釋出于：

附錄：更多IM技術文章

[1] 網絡程式設計基礎資料：

《

TCP/IP詳解

-

第11章·UDP：使用者資料報協定 第17章·TCP：傳輸控制協定 第18章·TCP連接配接的建立與終止 第21章·TCP的逾時與重傳 理論經典：TCP協定的3次握手與4次揮手過程詳解 理論聯系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程 計算機網絡通訊協定關系圖（中文珍藏版） NAT詳解：基本原理、穿越技術(P2P打洞)、端口老化等 UDP中一個包的大小最大能多大？ Java新一代網絡程式設計模型AIO原理及Linux系統AIO介紹 NIO架構入門(三)：iOS與MINA2、Netty4的跨平台UDP雙向通信實戰 NIO架構入門(四)：Android與MINA2、Netty4的跨平台UDP雙向通信實戰

>>

更多同類文章 …… [2] 有關IM/推送的通信格式、協定的選擇： 為什麼QQ用的是UDP協定而不是TCP協定？ 移動端即時通訊協定選擇：UDP還是TCP？ 移動端IM開發需要面對的技術問題（含通信協定選擇） 簡述移動端IM開發的那些坑：架構設計、通信協定和用戶端 58到家實時消息系統的協定設計等技術實踐分享 [3] 有關IM/推送的心跳保活處理： Android程序保活詳解：一篇文章解決你的所有疑問 Android端消息推送總結：實作原理、心跳保活、遇到的問題等 為何基于TCP協定的移動端IM仍然需要心跳保活機制？ 微信團隊原創分享：Android版微信背景保活實戰分享(程序保活篇) 微信團隊原創分享：Android版微信背景保活實戰分享(網絡保活篇) 移動端IM實踐：實作Android版微信的智能心跳機制 移動端IM實踐：WhatsApp、Line、微信的心跳政策分析 [4] 有關WEB端即時通訊開發： 新手入門貼：史上最全Web端即時通訊技術原理詳解 Web端即時通訊技術盤點：短輪詢、Comet、Websocket、SSE SSE技術詳解：一種全新的HTML5伺服器推送事件技術 Comet技術詳解：基于HTTP長連接配接的Web端實時通信技術 WebSocket詳解（一）：初步認識WebSocket技術 socket.io實作消息推送的一點實踐及思路 [5] 有關IM架構設計： 淺談IM系統的架構設計 一套原創分布式即時通訊(IM)系統理論架構方案 從零到卓越：京東客服即時通訊系統的技術架構演進曆程 蘑菇街即時通訊/IM伺服器開發之架構選擇 騰訊QQ1.4億線上使用者的技術挑戰和架構演進之路PPT 微信技術總監談架構：微信之道——大道至簡(演講全文) 如何解讀《微信技術總監談架構：微信之道——大道至簡》 快速裂變：見證微信強大背景架構從0到1的演進曆程（一） 17年的實踐：騰訊海量産品的技術方法論 [6] 有關IM安全的文章： 即時通訊安全篇（一）：正确地了解和使用Android端加密算法 即時通訊安全篇（二）：探讨組合加密算法在IM中的應用 即時通訊安全篇（三）：常用加解密算法與通訊安全講解 即時通訊安全篇（四）：執行個體分析Android中密鑰寫死的風險 傳輸層安全協定SSL/TLS的Java平台實作簡介和Demo示範 理論聯系實際：一套典型的IM通信協定設計詳解（含安全層設計） 微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解 來自阿裡OpenIM：打造安全可靠即時通訊服務的技術實踐分享 [7] 有關實時音視訊開發： 即時通訊音視訊開發（一）：視訊編解碼之理論概述 即時通訊音視訊開發（二）：視訊編解碼之數字視訊介紹 即時通訊音視訊開發（三）：視訊編解碼之編碼基礎 即時通訊音視訊開發（四）：視訊編解碼之預測技術介紹 即時通訊音視訊開發（五）：認識主流視訊編碼技術H.264 即時通訊音視訊開發（六）：如何開始音頻編解碼技術的學習 即時通訊音視訊開發（七）：音頻基礎及編碼原理入門 即時通訊音視訊開發（八）：常見的實時語音通訊編碼标準 即時通訊音視訊開發（九）：實時語音通訊的回音及回音消除�概述 即時通訊音視訊開發（十）：實時語音通訊的回音消除�技術詳解 即時通訊音視訊開發（十一）：實時語音通訊丢包補償技術詳解 即時通訊音視訊開發（十二）：多人實時音視訊聊天架構探讨 即時通訊音視訊開發（十三）：實時視訊編碼H.264的特點與優勢 即時通訊音視訊開發（十四）：實時音視訊資料傳輸協定介紹 即時通訊音視訊開發（十五）：聊聊P2P與實時音視訊的應用情況 即時通訊音視訊開發（十六）：移動端實時音視訊開發的幾個建議 即時通訊音視訊開發（十七）：視訊編碼H.264、V8的前世今生 簡述開源實時音視訊技術WebRTC的優缺點 良心分享：WebRTC 零基礎開發者教程（中文） [8] IM開發綜合文章： 開發IM是自己設計協定用位元組流好還是字元流好？ 請問有人知道語音留言聊天的主流實作方式嗎？ IM系統中如何保證消息的可靠投遞（即QoS機制） 談談移動端 IM 開發中登入請求的優化 完全自已開發的IM該如何設計“失敗重試”機制？ 微信對網絡影響的技術試驗及分析（論文全文） 即時通訊系統的原理、技術和應用（技術論文） 開源IM工程“蘑菇街TeamTalk”的現狀：一場有始無終的開源秀 [9] 開源移動端IM技術架構資料： 開源移動端IM技術架構MobileIMSDK：快速入門 開源移動端IM技術架構MobileIMSDK：常見問題解答 開源移動端IM技術架構MobileIMSDK：壓力測試報告 [10] 有關推送技術的文章： iOS的推送服務APNs詳解：設計思路、技術原理及缺陷等 掃盲貼：認識MQTT通信協定 一個基于MQTT通信協定的完整Android推送Demo 求教android消息推送：GCM、XMPP、MQTT三種方案的優劣 移動端實時消息推送技術淺析 掃盲貼：淺談iOS和Android背景實時消息推送的原理和差別 絕對幹貨：基于Netty實作海量接入的推送服務技術要點 移動端IM實踐：谷歌消息推送服務(GCM)研究（來自微信） 為何微信、QQ這樣的IM工具不使用GCM服務推送消息？ [11] 更多即時通訊技術好文分類： http://www.52im.net/forum.php?mod=collection&op=all

作者： Jack Jiang (點選作者姓名進入Github) 出處： http://www.52im.net/space-uid-1.html 交流： �歡迎加入即時通訊開發交流群 讨論： � http://www.52im.net/ Jack Jiang同時是 【原創Java Swing外觀工程BeautyEye】 和 【輕量級移動端即時通訊架構MobileIMSDK】 的作者，可前往下載下傳交流。