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的開發者纔有比較深刻的體會。（本文同步發佈於：http://www.52im.net/thread-289-1-1.html）

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

簡述移動端IM開發的那些坑：架構設計、通信協議和客戶端頂原

1、前言

2、學習交流

3、概述

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

5、移動端IM客戶端的坑

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

7、結語

附錄：更多IM技術文章

[轉帖]使用NMT和pmap解決JVM資源泄漏問題原創

Python實現大麥網搶票的四大關鍵技術點解析

Python 安裝庫指令大全

salesforce零基礎學習（一百三十八）零碎知識點小總結（十）

一款開源的.NET程序集反編譯、編輯和調試神器

關於接口協議，你必須要知道這些！

2020年上半年數據庫系統工程師考試

基於 Milvus + LlamaIndex 實現高級 RAG

【2024-05-21】以茶會友

微信團隊披露：微信界面卡死超級bug“15。。。。”的來龍去脈頂原

微信團隊分享：微信每日億次實時音視頻聊天背後的技術解密頂原

高性能網絡編程(二)：上一個10年，著名的C10K併發連接問題頂原

IM消息送達保證機制實現(二)：保證離線消息的可靠投遞頂原薦

技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）頂原薦

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結

簡述移動端IM開發的那些坑：架構設計、通信協議和客戶端 頂 原

1、前言

2、學習交流

3、概述

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

5、移動端IM客戶端的坑

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

7、結語

附錄：更多IM技術文章

簡述移動端IM開發的那些坑：架構設計、通信協議和客戶端頂原