一、前言
IM發展至今，已是非常重要的互聯網應用形態之一，尤其移動互聯網時代，它正以無與論比的優勢降低了溝通成本和溝通代價，對各種應用形態產生了深遠影響。
做爲IM開發者或即將成爲IM開發者的技術人員，IM的價值和重要性不言自明。但從技術實現來說，IM系統的開發（尤其是移動端IM）還是存在許多技術難點和坑點的。也正因如此，優質的IM開發相關的資料、實踐性成果，對於沒有太多技術儲備的新手來說，尤其難以獲得。
本文將以新手的視角引導你閱讀相關文章，以便爲從零開發一個移動端IM做好方方面面的知識準備：包括但不限於網絡編程基礎、通信協議的選型、IM的架構設計等等。文筆有限，如有不妥之處還請批評指正，希望對你有用。（本文同步發佈於：http://www.52im.net/thread-464-1-1.html）
即時通訊開發交流：
215891622 [推薦]
二、讀完本文的收穫
2.1 您將獲得
本文將假設你是毫無技術準備的新手，引導你通過一篇篇精選的文章，瞭解如何開始從零開發一個移動端IM所需要的各種技術、資料和實踐性代碼。
2.2 您無法獲得
鑑於IM技術的複雜性，IM開發相關的技術不是一篇文章所能展現的了，限於篇幅原因本文將不包含任何實踐性代碼、也儘量不對某項技術作深入的展開，相關的實踐性代碼、資料、技術詳解等請依據本文作者準備的文章逐個深入閱讀和學習，而這也恰恰是本文想達到的目的。
三、題外話
隨着近兩年IM雲服務的發展，很多團隊基於種種原因，直接選擇了短平快的雲IM接入APP中。然而，考慮到雲IM無論從商業模式還是運營模式上，還需經過多年的沉澱，纔可能真正實現客戶與服務商的運營和服務良性循環的雙贏局面。因則，如何選擇雲IM服務商，這就是個頭疼的問題了，不過這不是本文將要討論的重點，如果需要，你也可以加入本文提到的討論交流羣，與大家一起交流羣： 215891622。
好了，以下是正文內容。
四、網絡編程理論準備
4.1 UDP、TCP協議理論
我們都知道，IM系統的業務本質就是客戶端與客戶端進行消息的實時傳遞，而技術基礎就是基於Socket連接的實時數據讀寫，那麼基本的網絡編程理論基礎是作爲新手的你必須掌握的知識點。當然，作爲IM開發來說，基礎的網絡理論就夠用了，也沒有必要像網絡工程師一樣精通所謂的OSI七層參考模型。
如果你還不知道什麼是UDP、TCP協議，請閱讀以下文章：
- 《TCP/IP詳解 - 第11章·UDP：用戶數據報協議》
- 《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》
- 《TCP/IP詳解 - 第18章·TCP連接的建立與終止》
- 《TCP/IP詳解 - 第21章·TCP的超時與重傳》。
這幾篇文章有助於對UDP、TCP協議建立基本的認識，當然如果時間允許，能全書閱讀網絡編程理論經典《TCP/IP詳解 卷1：協議》則再好不過了。另外，UDP、TCP作爲基礎計算機數據傳輸協議，在其之上衍生了很多應用層協議，相關的協議族關係圖可以在此文中找到：《計算機網絡通訊協議關係圖（中文珍藏版）》，可作爲您日常的備查手冊使用。
4.2 深入理解TCP傳輸協議
透徹理解TCP傳輸協議的連接和斷開過程非常有助於您日後IM算法的優化和實現，這個過程被形象的總結爲“3次握手與4次揮手”。
以下文章有助於您深入理解之：
4.3 深入理解UDP傳輸協議
相比TCP協議，UDP數據傳輸協議就顯得非常輕量和易於理解，UDP通常被用於需要快速響應的數據傳輸場景下，對應於IM中的應用形態有：P2P通信、實時音視頻等。另外，通常的IM都會被應用於互聯網上（而非局域網），那麼瞭解所謂的NAT路由技術原理等，也將有助於您對P2P打洞、UDP端口老化等概念有一個清楚的認知。
以下文章有助於您在接下來開發IM的實際應用中提供一定的實踐依據：
當然，現時的網絡編程，爲了解決高性能問題，有很多成型的Socket應用層模式存在，比如：NIO、AIO等，文章《Java新一代網絡編程模型AIO原理及Linux系統AIO介紹》簡單介紹了傳統的阻塞式IO、NIO，並着重介紹了最新的AIO技術，如有時間您很有必要予以瞭解。（更多同類文章：點此進入…）
五、網絡編程基礎實踐
如果你認真讀完了上一層的文章，是時候寫些代碼，來理論聯繫實際理解Socket通信的原理和實踐了。
有關TCP的Socket通信Demo文章和代碼：
- 《Android端與服務端基於TCP協議的Socket通訊》
- iOS平臺的CocoaAsyncSocket託管代碼中有許多TCP的官方Demo代碼，值得一看。
當然，以是隻是隨手找的Demo代碼，網絡上有關TCP數據通信的演示性代碼很容易找到，在此就不過多舉例了。
本文作者專門編寫的有關跨移動端平臺的UDP Socket通信Demo：
- 《NIO框架入門(一)：服務端基於Netty4的UDP雙向通信Demo演示》
- 《NIO框架入門(二)：服務端基於MINA2的UDP雙向通信Demo演示》
- 《NIO框架入門(三)：iOS與MINA2、Netty4的跨平臺UDP雙向通信實戰》
- 《NIO框架入門(四)：Android與MINA2、Netty4的跨平臺UDP雙向通信實戰》。
六、IM到底該用UDP還是TCP協議？
好了，上面的網絡編程基礎掌握後，就要開始爲你的IM進行傳輸協議選型了。說到IM該用UDP還是TCP作爲傳輸協議，這是個頗有爭議的話題，各大社區每當此問題的出現必定是大片的不同聲音。
當然，UDP和TCP各有各的應用場景，作爲IM來說，早期的IM因爲服務端資源（服務器硬件、網絡帶寬等）比較昂貴且沒有更好的辦法來分擔性能負載，所以很多時候會考慮使用UDP，這其中主要是早期的QQ爲代表。
時至今日，TCP的服務端負載已經有了很好的解決方案，加之服務器資源成本的下降，目前很多IM、消息推送解決方案也都在使用TCP作爲傳輸層協議。不過，UDP也並未排除在IM、消息推送的解決方案之外，比如：弱網絡通信（包括跨國的高延遲網絡環境）、物聯網通信、IM中的實時音視頻通信等等場景下，UDP依然是首選項。
以下文章或許有助於您對傳輸層協議的選型：
- 《爲什麼QQ用的是UDP協議而不是TCP協議？》
- 《移動端即時通訊協議選擇：UDP還是TCP？》
- 《微信對網絡影響的技術試驗及分析（論文全文）》
- 《爲何基於TCP協議的移動端IM仍然需要心跳保活機制？》。
當然，關於IM到底該選擇UDP還是TCP，這是個仁者見仁智者見智的問題，沒有必要過於糾結，請從您的IM整體應用場景、開發代價、部署和運營成本等方面綜合考慮，相信能找到你要的答案。
七、IM的數據通信格式選型
IM應用開發的前期技術選型時，關於數據通信格式的選擇，在同行的眼裏，是同樣是個極富爭議話題。
精略分析一下，究其原因，大概在於以下幾點：
- 可選擇的協議或封裝格式多種多樣：
可選擇的餘地大：XMPP、Protobuf、JSON、私有2進制、MQTT、定格化XML、Plain text等等； - 同一種格式並不能適用於大多數的場景：
不同的場景有同的考慮而協議的選擇往往跟這掛鉤在一起的，如：移動端IM或推送用XMPP協議時，多數情況下都會被噴； - 開發者對所選格式有各自的偏好：
有的人或團隊對某種或某幾種格式有不一樣的經驗和技術積累，也促成了他們對某種或某幾種協議的偏好。
該選什麼樣的數據通信格式，同樣是跟你的應用場景和使用的架構方案相關聯。不過，目前以作者掌握的信息看來，作爲需要運行在移動設備的IM，幾乎目前所有主流討論裏都不建議使用XMPP協議，具體原因就不在此展開了，下面推薦的文章裏會詳細爲你解答原因。
以下文章會對你的IM的數據通信格式選型有所幫助：
- 《如何選擇即時通訊應用的數據傳輸格式》
- 《強列建議將Protobuf作爲你的即時通訊應用數據傳輸格式》
- 《移動端IM開發需要面對的技術問題（含通信協議選擇）》
- 《簡述移動端IM開發的那些坑：架構設計、通信協議和客戶端》
- 《理論聯繫實際：一套典型的IM通信協議設計詳解》
- 《58到家實時消息系統的協議設計等技術實踐分享》
- 《掃盲貼：認識MQTT通信協議》。
（更多同類文章：點此查看…）
八、移動端IM的心跳保活和後臺消息推送
8.1 爲什麼需要心跳保活？
由於移動網絡的複雜性，心跳保活對於移動端IM來說顯的尤爲重要，加之手機省電、省流量策略的設計，如何實現心跳保活則也非常重要，文章《基於TCP協議的移動端IM仍然需要心跳保活機制》或許可以解答你的疑問。
8.2 iOS端的後臺消息推送
因爲iOS平臺的特殊性，iOS應用一旦退到後臺，應用本身是無法用代碼來實現網絡保活的，也就無法自行實現後臺消息推送了。
以下文章將有助於你理解iOS平臺的後臺消息推送原理：
8.3 Android端的心跳保活和後臺消息推送
鑑於Android平臺衆所周之的分化和互不兼容問題，Android端IM在處理心跳保活和後臺消息推送時，遇到了不少的麻煩。而且，由於Android應用的生命週期管理是由系統控制，因而如何保證您的IM所在進程或後臺服務不被系統殺死，是實現心跳保活和後臺消息推送的實現基礎。
以下文章可爲你的Android端IM的心跳保活和後臺推送方案的設計提供參考：
- 《Android進程保活詳解：一篇文章解決你的所有疑問》
- 《Android端消息推送總結：實現原理、心跳保活、遇到的問題等》
- 《爲何基於TCP協議的移動端IM仍然需要心跳保活機制？》
- 《微信團隊原創分享：Android版微信後臺保活實戰分享(進程保活篇)》
- 《微信團隊原創分享：Android版微信後臺保活實戰分享(網絡保活篇)》
- 《移動端IM實踐：實現Android版微信的智能心跳機制》
- 《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》
（更多同類文章：此進入…）
九、移動端IM系統的架構設計
IM其本質是一套消息發送與投遞系統，或者說是一套網絡通信系統，歸根結底就是兩個詞：存儲與轉發。但一個成熟的移動端IM系統要想正常運轉，涉及的內容則遠不止這些，而最考驗技術功底的就是服務端架構的設計與實現。
沒有過IM系統開發經驗的人，可能對以上觀點嗤之以鼻，在此借用TeamTalk的設計者的一段話：“IM服務器開發，從功能抽象的角度看可能非常簡單，可以認爲是管理大量的客戶端連接和在不同的客戶端之間傳遞消息，但具體到實現細節就比較複雜了。打個不恰當的比喻，OS的功能抽象也非常簡單，無非是進程間的調度和硬件資源的管理，但要是自己去實現一個，一般人也就只能呵呵了。”
我們以一個典型方案爲例，首先來提煉一下一個IM系統的主要需求：包括賬號、關係鏈、在線狀態顯示、消息交互（文本、圖片、語音）、實時視頻電話......。
要處理好上述需求，我們通常需要從以下方面進行考量從而設計出合適的架構：
- 如果採用可靠傳輸協議TCP，需要考慮到負載問題：短連接實現賬號、關係鏈相關業務，長連接實現上線、信息推送；
- 後臺架構的靈活性、可擴展性：支持分佈式部署——把網絡層、業務邏輯層、數據層分離，網絡層和業務層支持負載均衡策略、數據層支持分佈式存儲；
- 客戶端SDK的易用性：把網絡層、數據層分離、業務邏輯層分離。
另外，一個典型的IM系統架構設計，還有以下性能方面的熱點問題需要設計者重點關注：
- 編碼角度：採用高效的網絡模型，線程模型，I/O處理模型，合理的數據庫設計和操作語句的優化；
- 垂直擴展：通過提高單服務器的硬件資源或者網絡資源來提高性能；
- 水平擴展：通過合理的架構設計和運維方面的負載均衡策略將負載分擔，有效提高性能；後期甚至可以考慮加入數據緩存層，突破IO瓶頸；
- 系統的高可用性：防止單點故障；
- 在架構設計時做到業務處理和數據的分離，從而依賴分佈式的部署使得在單點故障時能保證系統可用。
- 對於關鍵獨立節點可以採用雙機熱備技術進行切換。
- 數據庫數據的安全性可以通過磁盤陣列的冗餘配置和主備數據庫來解決。
鑑於篇幅有限，架構設計方面的內容本文就不深入展開了。
以下文章將爲你的移動端IM的架構設計帶來一定的參考意義：
- 《淺談IM系統的架構設計》
- 《簡述移動端IM開發的那些坑：架構設計、通信協議和客戶端》
- 《一套原創分佈式即時通訊(IM)系統理論架構方案》
- 《從零到卓越：京東客服即時通訊系統的技術架構演進歷程》
- 《蘑菇街即時通訊/IM服務器開發之架構選擇》
- 《騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT》
- 《微信技術總監談架構：微信之道——大道至簡(演講全文)》
- 《如何解讀《微信技術總監談架構：微信之道——大道至簡》》
- 《快速裂變：見證微信強大後臺架構從0到1的演進歷程（一）》
- 《17年的實踐：騰訊海量產品的技術方法論》。
（更多同類文章： 點此進入…）
十、移動端IM的通信安全
IM（尤其移動端IM）的安全性一直是開發者需要優先考慮的基礎問題，如何正確地理解和使用加密技術則顯的尤其重要。IM系統大都採用C/S、B/S、P2P等技術來實現即時通信的功能，軟件編制沒有統一的標準，使得IM系統本身存有多種安全漏洞，加上用戶缺乏安全意識，導致在使用即時通信系統時出現各種安全問題。
當今的計算機密碼學的主要作用有：加密（ Encryption）、認證（Authentication），鑑定（Identification） 。
加密：防止壞人獲取你的數據。
認證：防止壞人修改了你的數據而你卻並沒有發現。
鑑權：防止壞人假冒你的身份。
這些基本概念和加密算法原理就不在此展開敘述了。
以下文章或許有助於您設計出安全的移動端IM系統：
- 《即時通訊安全篇（一）：正確地理解和使用Android端加密算法》
- 《即時通訊安全篇（二）：探討組合加密算法在IM中的應用》
- 《即時通訊安全篇（三）：常用加解密算法與通訊安全講解》
- 《即時通訊安全篇（四）：實例分析Android中密鑰硬編碼的風險》
- 《傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示》
- 《理論聯繫實際：一套典型的IM通信協議設計詳解（含安全層設計）》
- 《微信新一代通信安全解決方案：基於TLS1.3的MMTLS詳解》
- 《來自阿里OpenIM：打造安全可靠即時通訊服務的技術實踐分享》。
（更多同類文章：點此進入…）
十一、有關IM中的實時音視頻技術
IM應用中的實時音視頻技術，幾乎是IM開發中的最後一道高牆。原因在於：實時音視頻技術 = 音視頻處理技術 + 網絡傳輸技術 的橫向技術應用集合體，而公共互聯網不是爲了實時通信設計的。實時音視頻技術上的實現內容主要包括：音視頻的採集、編碼、網絡傳輸、解碼、播放等環節。這麼多項並不簡單的技術應用，如果把握不當，將會在在實際開發過程中遇到一個又一個的坑。
以下文章有助於您從零理解IM的實時音視頻開發的方方面面：
- 《即時通訊音視頻開發（一）：視頻編解碼之理論概述》
- 《即時通訊音視頻開發（二）：視頻編解碼之數字視頻介紹》
- 《即時通訊音視頻開發（三）：視頻編解碼之編碼基礎》
- 《即時通訊音視頻開發（四）：視頻編解碼之預測技術介紹》
- 《即時通訊音視頻開發（五）：認識主流視頻編碼技術H.264》
- 《即時通訊音視頻開發（六）：如何開始音頻編解碼技術的學習》
- 《即時通訊音視頻開發（七）：音頻基礎及編碼原理入門》
- 《即時通訊音視頻開發（八）：常見的實時語音通訊編碼標準》
- 《即時通訊音視頻開發（九）：實時語音通訊的迴音及迴音消除概述》
- 《即時通訊音視頻開發（十）：實時語音通訊的迴音消除技術詳解》
- 《即時通訊音視頻開發（十一）：實時語音通訊丟包補償技術詳解》
- 《即時通訊音視頻開發（十二）：多人實時音視頻聊天架構探討》
- 《即時通訊音視頻開發（十三）：實時視頻編碼H.264的特點與優勢》
- 《即時通訊音視頻開發（十四）：實時音視頻數據傳輸協議介紹》
- 《即時通訊音視頻開發（十五）：聊聊P2P與實時音視頻的應用情況》
- 《即時通訊音視頻開發（十六）：移動端實時音視頻開發的幾個建議》
- 《即時通訊音視頻開發（十七）：視頻編碼H.264、V8的前世今生》
- 《簡述開源實時音視頻技術WebRTC的優缺點》
- 《良心分享：WebRTC 零基礎開發者教程（中文）》。
（更多同類文章： 點此進入…）
十二、移動端IM開發的其它熱點問題
移動端IM開發中還會遇到上述內容未提及的內容，以下文章或許您用的上：
《移動端IM開發需要面對的技術問題》
《開發IM是自己設計協議用字節流好還是字符流好？》
《請問有人知道語音留言聊天的主流實現方式嗎？》
《IM系統中如何保證消息的可靠投遞（即QoS機制）》
《談談移動端 IM 開發中登錄請求的優化》
《完全自已開發的IM該如何設計“失敗重試”機制？》
《微信對網絡影響的技術試驗及分析（論文全文）》
《即時通訊系統的原理、技術和應用（技術論文）》
《開源IM工程“蘑菇街TeamTalk”的現狀：一場有始無終的開源秀》
>> 更多同類文章 ……
附錄：其它即時通訊文章
[1] 有關WEB端即時通訊開發：
《新手入門貼：史上最全Web端即時通訊技術原理詳解》
《Web端即時通訊技術盤點：短輪詢、Comet、Websocket、SSE》
《SSE技術詳解：一種全新的HTML5服務器推送事件技術》
《Comet技術詳解：基於HTTP長連接的Web端實時通信技術》
《WebSocket詳解（一）：初步認識WebSocket技術》
《socket.io實現消息推送的一點實踐及思路》
>> 更多同類文章 ……
[2] 有關推送技術的文章：
《iOS的推送服務APNs詳解：設計思路、技術原理及缺陷等》
《Android端消息推送總結：實現原理、心跳保活、遇到的問題等》
《掃盲貼：認識MQTT通信協議》
《一個基於MQTT通信協議的完整Android推送Demo》
《求教android消息推送：GCM、XMPP、MQTT三種方案的優劣》
《移動端實時消息推送技術淺析》
《掃盲貼：淺談iOS和Android後臺實時消息推送的原理和區別》
《絕對乾貨：基於Netty實現海量接入的推送服務技術要點》
《移動端IM實踐：谷歌消息推送服務(GCM)研究（來自微信）》
《爲何微信、QQ這樣的IM工具不使用GCM服務推送消息？》
>> 更多同類文章 ……
[3] 更多即時通訊技術好文分類：
http://www.52im.net/forum.php?mod=collection&op=all
（本文同步發佈於：http://www.52im.net/thread-464-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】的作者，可前往下載交流。