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

時間 2019-11-11

標籤原創新手入門一篇開發移動欄目無線简体版

原文原文鏈接

1、前言

IM發展至今，已經是很是重要的互聯網應用形態之一，尤爲移動互聯網時代，它正以無與論比的優點下降了溝通成本和溝通代價，對各類應用形態產生了深遠影響。

作爲IM開發者或即將成爲IM開發者的技術人員，IM的價值和重要性不言自明。但從技術實現來講，IM系統的開發（尤爲是移動端IM）仍是存在許多技術難點和坑點的。也正因如此，優質的IM開發相關的資料、實踐性成果，對於沒有太多技術儲備的新手來講，尤爲難以得到。

本文將以新手的視角引導你閱讀相關文章，以便爲從零開發一個移動端IM作好方方面面的知識準備：包括但不限於網絡編程基礎、通訊協議的選型、IM的架構設計等等。文筆有限，若有不妥之處還請批評指正，但願對你有用。（本文同步發佈於：http://www.52im.net/thread-464-1-1.html）
php

即時通信開發交流： 215891622 [推薦]html

2、讀完本文的收穫

2.1 您將得到

本文將假設你是毫無技術準備的新手，引導你經過一篇篇精選的文章，瞭解如何開始從零開發一個移動端IM所須要的各類技術、資料和實踐性代碼。

android

2.2 您沒法得到

鑑於IM技術的複雜性，IM開發相關的技術不是一篇文章所能展示的了，限於篇幅緣由本文將不包含任何實踐性代碼、也儘可能不對某項技術做深刻的展開，相關的實踐性代碼、資料、技術詳解等請依據本文做者準備的文章逐個深刻閱讀和學習，而這也偏偏是本文想達到的目的。git

3、題外話

隨着近兩年IM雲服務的發展，不少團隊基於種種緣由，直接選擇了短平快的雲IM接入APP中。然而，考慮到雲IM不管從商業模式仍是運營模式上，還需通過多年的沉澱，纔可能真正實現客戶與服務商的運營和服務良性循環的共贏局面。因則，如何選擇雲IM服務商，這就是個頭疼的問題了，不過這不是本文將要討論的重點，若是須要，你也能夠加入本文提到的討論交流羣，與你們一塊兒交流羣： 215891622。

好了，如下是正文內容。github

4、網絡編程理論準備

4.1 UDP、TCP協議理論

咱們都知道，IM系統的業務本質就是客戶端與客戶端進行消息的實時傳遞，而技術基礎就是基於Socket鏈接的實時數據讀寫，那麼基本的網絡編程理論基礎是做爲新手的你必須掌握的知識點。固然，做爲IM開發來講，基礎的網絡理論就夠用了，也沒有必要像網絡工程師同樣精通所謂的OSI七層參考模型。

若是你還不知道什麼是UDP、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技術，若有時間您頗有必要予以瞭解。（更多同類文章：點此進入…）安全

5、網絡編程基礎實踐

若是你認真讀完了上一層的文章，是時候寫些代碼，來理論聯繫實際理解Socket通訊的原理和實踐了。

有關TCP的Socket通訊Demo文章和代碼：

《Android端與服務端基於TCP協議的Socket通信》
iOS平臺的CocoaAsyncSocket託管代碼中有許多TCP的官方Demo代碼，值得一看。

固然，以是隻是隨手找的Demo代碼，網絡上有關TCP數據通訊的演示性代碼很容易找到，在此就不過多舉例了。

本文做者專門編寫的有關跨移動端平臺的UDP Socket通訊Demo：

6、IM到底該用UDP仍是TCP協議？

好了，上面的網絡編程基礎掌握後，就要開始爲你的IM進行傳輸協議選型了。說到IM該用UDP仍是TCP做爲傳輸協議，這是個很有爭議的話題，各大社區每當此問題的出現一定是大片的不一樣聲音。

固然，UDP和TCP各有各的應用場景，做爲IM來講，早期的IM由於服務端資源（服務器硬件、網絡帶寬等）比較昂貴且沒有更好的辦法來分擔性能負載，因此不少時候會考慮使用UDP，這其中主要是早期的QQ爲表明。

時至今日，TCP的服務端負載已經有了很好的解決方案，加之服務器資源成本的降低，目前不少IM、消息推送解決方案也都在使用TCP做爲傳輸層協議。不過，UDP也並未排除在IM、消息推送的解決方案以外，好比：弱網絡通訊（包括跨國的高延遲網絡環境）、物聯網通訊、IM中的實時音視頻通訊等等場景下，UDP依然是首選項。

如下文章或許有助於您對傳輸層協議的選型：

固然，關於IM到底該選擇UDP仍是TCP，這是個仁者見仁智者見智的問題，沒有必要過於糾結，請從您的IM總體應用場景、開發代價、部署和運營成本等方面綜合考慮，相信能找到你要的答案。

7、IM的數據通訊格式選型

IM應用開發的前期技術選型時，關於數據通訊格式的選擇，在同行的眼裏，是一樣是個極富爭議話題。

精略分析一下，究其緣由，大概在於如下幾點：

可選擇的協議或封裝格式多種多樣：
可選擇的餘地大：XMPP、Protobuf、JSON、私有2進制、MQTT、定格化XML、Plain text等等；
同一種格式並不能適用於大多數的場景：
不一樣的場景有同的考慮而協議的選擇每每跟這掛鉤在一塊兒的，如：移動端IM或推送用XMPP協議時，多數狀況下都會被噴；
開發者對所選格式有各自的偏好：
有的人或團隊對某種或某幾種格式有不同的經驗和技術積累，也促成了他們對某種或某幾種協議的偏好。

該選什麼樣的數據通訊格式，一樣是跟你的應用場景和使用的架構方案相關聯。不過，目前以做者掌握的信息看來，做爲須要運行在移動設備的IM，幾乎目前全部主流討論裏都不建議使用XMPP協議，具體緣由就不在此展開了，下面推薦的文章裏會詳細爲你解答緣由。

如下文章會對你的IM的數據通訊格式選型有所幫助：

（更多同類文章：點此查看…）

8、移動端IM的心跳保活和後臺消息推送

8.1 爲何須要心跳保活？

因爲移動網絡的複雜性，心跳保活對於移動端IM來講顯的尤其重要，加之手機省電、省流量策略的設計，如何實現心跳保活則也很是重要，文章《基於TCP協議的移動端IM仍然須要心跳保活機制》或許能夠解答你的疑問。

8.2 iOS端的後臺消息推送

由於iOS平臺的特殊性，iOS應用一旦退到後臺，應用自己是沒法用代碼來實現網絡保活的，也就沒法自行實現後臺消息推送了。

如下文章將有助於你理解iOS平臺的後臺消息推送原理：

8.3 Android端的心跳保活和後臺消息推送

鑑於Android平臺衆所周之的分化和互不兼容問題，Android端IM在處理心跳保活和後臺消息推送時，遇到了很多的麻煩。並且，因爲Android應用的生命週期管理是由系統控制，於是如何保證您的IM所在進程或後臺服務不被系統殺死，是實現心跳保活和後臺消息推送的實現基礎。

如下文章可爲你的Android端IM的心跳保活和後臺推送方案的設計提供參考：

（更多同類文章：此進入…）

9、移動端IM系統的架構設計

IM其本質是一套消息發送與投遞系統，或者說是一套網絡通訊系統，歸根結底就是兩個詞：存儲與轉發。但一個成熟的移動端IM系統要想正常運轉，涉及的內容則遠不止這些，而最考驗技術功底的就是服務端架構的設計與實現。

沒有過IM系統開發經驗的人，可能對以上觀點嗤之以鼻，在此借用TeamTalk的設計者的一段話：「IM服務器開發，從功能抽象的角度看可能很是簡單，能夠認爲是管理大量的客戶端鏈接和在不一樣的客戶端之間傳遞消息，但具體到實現細節就比較複雜了。打個不恰當的比喻，OS的功能抽象也很是簡單，無非是進程間的調度和硬件資源的管理，但要是本身去實現一個，通常人也就只能呵呵了。」

咱們以一個典型方案爲例，首先來提煉一下一個IM系統的主要需求：包括帳號、關係鏈、在線狀態顯示、消息交互（文本、圖片、語音）、實時視頻電話......。

要處理好上述需求，咱們一般須要從如下方面進行考量從而設計出合適的架構：

若是採用可靠傳輸協議TCP，須要考慮到負載問題：短鏈接實現帳號、關係鏈相關業務，長鏈接實現上線、信息推送；
後臺架構的靈活性、可擴展性：支持分佈式部署——把網絡層、業務邏輯層、數據層分離，網絡層和業務層支持負載均衡策略、數據層支持分佈式存儲；
客戶端SDK的易用性：把網絡層、數據層分離、業務邏輯層分離。

另外，一個典型的IM系統架構設計，還有如下性能方面的熱點問題須要設計者重點關注：

編碼角度：採用高效的網絡模型，線程模型，I/O處理模型，合理的數據庫設計和操做語句的優化；
垂直擴展：經過提升單服務器的硬件資源或者網絡資源來提升性能；
水平擴展：經過合理的架構設計和運維方面的負載均衡策略將負載分擔，有效提升性能；後期甚至能夠考慮加入數據緩存層，突破IO瓶頸；
系統的高可用性：防止單點故障；
在架構設計時作到業務處理和數據的分離，從而依賴分佈式的部署使得在單點故障時能保證系統可用。
對於關鍵獨立節點能夠採用雙機熱備技術進行切換。
數據庫數據的安全性能夠經過磁盤陣列的冗餘配置和主備數據庫來解決。

鑑於篇幅有限，架構設計方面的內容本文就不深刻展開了。

如下文章將爲你的移動端IM的架構設計帶來必定的參考意義：

（更多同類文章：點此進入…）

10、移動端IM的通訊安全

IM（尤爲移動端IM）的安全性一直是開發者須要優先考慮的基礎問題，如何正確地理解和使用加密技術則顯的尤爲重要。IM系統大都採用C/S、B/S、P2P等技術來實現即時通訊的功能，軟件編制沒有統一的標準，使得IM系統自己存有多種安全漏洞，加上用戶缺少安全意識，致使在使用即時通訊系統時出現各類安全問題。

當今的計算機密碼學的主要做用有：加密（ Encryption）、認證（Authentication），鑑定（Identification）。

加密：防止壞人獲取你的數據。
認證：防止壞人修改了你的數據而你卻並無發現。
鑑權：防止壞人假冒你的身份。

這些基本概念和加密算法原理就不在此展開敘述了。

如下文章或許有助於您設計出安全的移動端IM系統：

（更多同類文章：點此進入…）

11、有關IM中的實時音視頻技術

IM應用中的實時音視頻技術，幾乎是IM開發中的最後一道高牆。緣由在於：實時音視頻技術 = 音視頻處理技術 + 網絡傳輸技術的橫向技術應用集合體，而公共互聯網不是爲了實時通訊設計的。實時音視頻技術上的實現內容主要包括：音視頻的採集、編碼、網絡傳輸、解碼、播放等環節。這麼多項並不簡單的技術應用，若是把握不當，將會在在實際開發過程當中遇到一個又一個的坑。

如下文章有助於您從零理解IM的實時音視頻開發的方方面面：