從零開發(fā)移動端IM (建議收藏慢慢學(xué))

一、前言

IM發(fā)展至今，已是非常重要的互聯(lián)網(wǎng)應(yīng)用形態(tài)之一，尤其移動互聯(lián)網(wǎng)時代，它正以無與論比的優(yōu)勢降低了溝通成本和交流門檻，對各種應(yīng)用形態(tài)產(chǎn)生了深遠(yuǎn)影響。

做為IM開發(fā)者或即將成為IM開發(fā)者的技術(shù)人員，IM的價值和重要性不言自明。但從技術(shù)實現(xiàn)來說，IM系統(tǒng)的開發(fā)（尤其是移動端IM）還是存在許多技術(shù)難點和坑點的。也正因如此，優(yōu)質(zhì)的IM開發(fā)資料、實踐成果，對于沒有太多技術(shù)儲備的新手來說，尤其難以獲得。

本文將以新手的視角引導(dǎo)你閱讀相關(guān)文章，便于你從零開發(fā)一個移動端IM做好方方面面的知識準(zhǔn)備：包括但不限于網(wǎng)絡(luò)編程基礎(chǔ)、通信協(xié)議的選型、IM的架構(gòu)設(shè)計等等。文筆有限，如有不妥之處還請批評指正，希望對你有用。

二、讀完本文的收獲

1. 您將獲得

本文將假設(shè)你是毫無技術(shù)準(zhǔn)備的新手，引導(dǎo)你通過一篇篇精選的文章，了解如何從零開發(fā)一個移動端IM所需要的各種技術(shù)、資料和實踐性代碼。

2. 您無法獲得

鑒于IM技術(shù)的復(fù)雜性，IM開發(fā)相關(guān)的技術(shù)不是一篇文章所能展現(xiàn)的完整，限于篇幅原因本文將不包含任何實踐性代碼、也盡量不對某項技術(shù)作深入的展開，相關(guān)的實踐性代碼、資料、技術(shù)詳解等請依據(jù)本文作者準(zhǔn)備的文章逐個深入閱讀和學(xué)習(xí)，而這也恰恰是本文想達(dá)到的目的。

三、題外話

隨著近兩年IM云服務(wù)的發(fā)展，很多團(tuán)隊基于種種原因，直接選擇了短平快的云IM接入APP中。然而，考慮到云IM無論從商業(yè)模式還是運營模式上，還需經(jīng)過多年的沉淀，才可能真正實現(xiàn)客戶與服務(wù)商的運營和服務(wù)良性循環(huán)的雙贏局面。因則，如何選擇云IM服務(wù)商，這就是個頭疼的問題了，不過這不是本文將要討論的重點，如果需要，你也可以加入本文提到的討論交流群，與大家一起交流群：215891622

好了，以下是正文內(nèi)容。

四、網(wǎng)絡(luò)編程理論準(zhǔn)備

1. UDP、TCP理論基礎(chǔ)

我們都知道，IM系統(tǒng)的業(yè)務(wù)本質(zhì)就是客戶端與客戶端進(jìn)行消息的實時傳遞，而技術(shù)基礎(chǔ)就是基于Socket連接的實時數(shù)據(jù)讀寫，那么基本的網(wǎng)絡(luò)編程理論基礎(chǔ)是作為新手的你必須掌握的知識點。當(dāng)然，作為IM開發(fā)來說，基礎(chǔ)的網(wǎng)絡(luò)理論就夠用了，也沒有必要像網(wǎng)絡(luò)工程師一樣精通所謂的OSI七層參考模型。

如果你還不知道什么是UDP、TCP協(xié)議，請閱讀以下文章：

這幾篇文章有助于對UDP、TCP協(xié)議建立基本的認(rèn)識，當(dāng)然如果時間允許，能全書閱讀網(wǎng)絡(luò)編程理論經(jīng)典《TCP/IP詳解 卷1：協(xié)議》則再好不過了。另外，UDP、TCP作為基礎(chǔ)計算機數(shù)據(jù)傳輸協(xié)議，在其之上衍生了很多應(yīng)用層協(xié)議，相關(guān)的協(xié)議族關(guān)系圖可以在此文中找到：《計算機網(wǎng)絡(luò)通訊協(xié)議關(guān)系圖（中文珍藏版）》，可作為您日常的備查手冊使用。

2. 深入理解TCP傳輸協(xié)議

透徹理解TCP傳輸協(xié)議的連接和斷開過程非常有助于您日后IM算法的優(yōu)化和實現(xiàn)，這個過程被形象的總結(jié)為“3次握手與4次揮手”。

以下文章有助于您深入理解之：

3. 深入理解UDP傳輸協(xié)議

相比TCP協(xié)議，UDP數(shù)據(jù)傳輸協(xié)議就顯得非常輕量和易于理解，UDP通常被用于需要快速響應(yīng)的數(shù)據(jù)傳輸場景下，對應(yīng)于IM中的應(yīng)用形態(tài)有：P2P通信、實時音視頻等。另外，通常的IM都會被應(yīng)用于互聯(lián)網(wǎng)上（而非局域網(wǎng)），那么了解所謂的NAT路由技術(shù)原理等，也將有助于您對P2P打洞、UDP端口老化等概念有一個清楚的認(rèn)知。

以下文章有助于您在接下來開發(fā)IM的實際應(yīng)用中提供一定的實踐依據(jù)：

4. 深入理解基于廣域網(wǎng)的互聯(lián)網(wǎng)編程知識

未來您所編寫的網(wǎng)絡(luò)應(yīng)用程序或產(chǎn)品基本都要運行基于廣域網(wǎng)的互聯(lián)網(wǎng)中（而非單純而簡單的局域網(wǎng)），而廣域網(wǎng)因物理網(wǎng)絡(luò)的復(fù)雜性，要編寫能適應(yīng)各種網(wǎng)絡(luò)拓?fù)涞某绦虼a，需要過硬的廣域網(wǎng)絡(luò)基礎(chǔ)知識，比如NAT路由轉(zhuǎn)發(fā)、P2P打洞等等。

下面的文章，有助于您深入理解NAT原理、點對點通信等方面的知識：

《P2P技術(shù)詳解(一)：NAT詳解——詳細(xì)原理、P2P簡介》
《P2P技術(shù)詳解(二)：P2P中的NAT穿越(打洞)方案詳解》
《P2P技術(shù)詳解(三)：P2P技術(shù)之STUN、TURN、ICE詳解》

5. 有關(guān)高性能網(wǎng)絡(luò)編程的知識

實際上，大用戶量高并發(fā)生產(chǎn)環(huán)境下的網(wǎng)絡(luò)編程，你所開發(fā)的產(chǎn)品要想真正堪用并非易事，你很有必要了解高性能網(wǎng)絡(luò)編程領(lǐng)域所關(guān)注的熱點問題和努力的方向。

以下是即時通訊網(wǎng)整理的高性能網(wǎng)絡(luò)編程領(lǐng)域的系列文章：

《高性能網(wǎng)絡(luò)編程(一)：單臺服務(wù)器并發(fā)TCP連接數(shù)到底可以有多少》
《高性能網(wǎng)絡(luò)編程(二)：上一個10年，著名的C10K并發(fā)連接問題》
《高性能網(wǎng)絡(luò)編程(三)：下一個10年，是時候考慮C10M并發(fā)問題了》

好消息是，現(xiàn)時的網(wǎng)絡(luò)編程為了解決高性能問題，有很多成型的Socket應(yīng)用層模式存在，比如：NIO、AIO等，文章《Java新一代網(wǎng)絡(luò)編程模型AIO原理及Linux系統(tǒng)AIO介紹》簡單介紹了傳統(tǒng)的阻塞式IO、NIO，并著重介紹了最新的AIO技術(shù)，如有時間您很有必要予以了解。（更多同類文章：點此進(jìn)入…）

五、網(wǎng)絡(luò)編程基礎(chǔ)實踐

如果你認(rèn)真讀完了上一層的文章，是時候?qū)懶┐a，來理論聯(lián)系實際理解Socket通信的原理和實踐了。

有關(guān)TCP的Socket通信Demo文章和代碼：

當(dāng)然，以上只是隨手找的Demo代碼，網(wǎng)絡(luò)上有關(guān)TCP數(shù)據(jù)通信的演示性代碼很容易找到，在此就不過多舉例了。

本文作者專門編寫的有關(guān)跨移動端平臺的UDP Socket通信Demo：

六、IM到底該用UDP還是TCP協(xié)議？

好了，上面的網(wǎng)絡(luò)編程基礎(chǔ)掌握后，就要開始為你的IM進(jìn)行傳輸協(xié)議選型了。說到IM該用UDP還是TCP作為傳輸協(xié)議，這是個頗有爭議的話題，各大社區(qū)每當(dāng)此問題的出現(xiàn)必定是大片的不同聲音。

當(dāng)然，UDP和TCP各有各的應(yīng)用場景，作為IM來說，早期的IM因為服務(wù)端資源（服務(wù)器硬件、網(wǎng)絡(luò)帶寬等）比較昂貴且沒有更好的辦法來分擔(dān)性能負(fù)載，所以很多時候會考慮使用UDP，這其中主要是早期的QQ為代表。

時至今日，TCP的服務(wù)端負(fù)載已經(jīng)有了很好的解決方案，加之服務(wù)器資源成本的下降，目前很多IM、消息推送解決方案也都在使用TCP作為傳輸層協(xié)議。不過，UDP也并未排除在IM、消息推送的解決方案之外，比如：弱網(wǎng)絡(luò)通信（包括跨國的高延遲網(wǎng)絡(luò)環(huán)境）、物聯(lián)網(wǎng)通信、IM中的實時音視頻通信等等場景下，UDP依然是首選項。

以下文章或許有助于您對傳輸層協(xié)議的選型：

當(dāng)然，關(guān)于IM到底該選擇UDP還是TCP，這是個仁者見仁智者見智的問題，沒有必要過于糾結(jié)，請從您的IM整體應(yīng)用場景、開發(fā)代價、部署和運營成本等方面綜合考慮，相信能找到你要的答案。

七、IM的數(shù)據(jù)通信格式選型

IM應(yīng)用開發(fā)的前期技術(shù)選型時，關(guān)于數(shù)據(jù)通信格式的選擇，在同行的眼里，同樣是個極富爭議的話題。

精略分析一下，究其原因，大概在于以下幾點：

  • 可選擇的協(xié)議或封裝格式多種多樣：
    可選擇的余地大：XMPP、Protobuf、JSON、私有2進(jìn)制、MQTT、定格化XML、Plain text等等；
  • 同一種格式并不能適用于大多數(shù)的場景：
    不同的場景有同的考慮而協(xié)議的選擇往往跟這掛鉤在一起的，如：移動端IM或移動端消息推送的應(yīng)用場景下如果用XMPP協(xié)議，多數(shù)情況下都會被噴；
  • 開發(fā)者對所選格式有各自的偏好：
    有的人或團(tuán)隊對某種或某幾種格式有不一樣的經(jīng)驗和技術(shù)積累，也促成了他們對某種或某幾種協(xié)議的偏好。

該選什么樣的數(shù)據(jù)通信格式，同樣是跟你的應(yīng)用場景和使用的架構(gòu)方案相關(guān)聯(lián)。不過，目前以作者掌握的信息看來，作為需要運行在移動設(shè)備的IM，幾乎目前所有主流討論里都不建議使用XMPP協(xié)議，具體原因就不在此展開了，下面推薦的文章里會詳細(xì)為你解答原因。

以下文章會對你的IM的數(shù)據(jù)通信格式選型有所幫助：

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

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

1. 為什么需要心跳保活？

由于移動網(wǎng)絡(luò)的復(fù)雜性，心跳保活對于移動端IM來說顯的尤為重要，加之手機省電、省流量策略的設(shè)計，如何實現(xiàn)心跳保活則也非常重要，文章《基于TCP協(xié)議的移動端IM仍然需要心跳保活機制》或許可以解答你的疑問。

2. iOS端的后臺消息推送

因為iOS平臺的特殊性，iOS應(yīng)用一旦退到后臺，應(yīng)用本身是無法用代碼來實現(xiàn)網(wǎng)絡(luò)保活的，也就無法自行實現(xiàn)后臺消息推送了。

以下文章將有助于你理解iOS平臺的后臺消息推送原理：

3. Android端的心跳保活和后臺消息推送

鑒于Android平臺眾所周之的分化和互不兼容問題，Android端IM在處理心跳保活和后臺消息推送時，遇到了不少的麻煩。而且，由于Android應(yīng)用的生命周期管理是由系統(tǒng)控制，因而如何保證您的IM所在進(jìn)程或后臺服務(wù)不被系統(tǒng)殺死，是實現(xiàn)心跳保活和后臺消息推送的實現(xiàn)基礎(chǔ)。

以下文章可為你的Android端IM的心跳保活和后臺推送方案的設(shè)計提供參考：

（更多同類文章：此進(jìn)入…）

九、移動端IM系統(tǒng)的架構(gòu)設(shè)計

IM其本質(zhì)是一套消息發(fā)送與投遞系統(tǒng)，或者說是一套網(wǎng)絡(luò)通信系統(tǒng)，歸根結(jié)底就是兩個詞：存儲與轉(zhuǎn)發(fā)。但一個成熟的移動端IM系統(tǒng)要想正常運轉(zhuǎn)，涉及的內(nèi)容則遠(yuǎn)不止這些，而最考驗技術(shù)功底的就是服務(wù)端架構(gòu)的設(shè)計與實現(xiàn)。

沒有過IM系統(tǒng)開發(fā)經(jīng)驗的人，可能對以上觀點嗤之以鼻，在此借用TeamTalk的設(shè)計者的一段話：“IM服務(wù)器開發(fā)，從功能抽象的角度看可能非常簡單，可以認(rèn)為是管理大量的客戶端連接和在不同的客戶端之間傳遞消息，但具體到實現(xiàn)細(xì)節(jié)就比較復(fù)雜了。打個不恰當(dāng)?shù)谋扔鳎琌S的功能抽象也非常簡單，無非是進(jìn)程間的調(diào)度和硬件資源的管理，但要是自己去實現(xiàn)一個，一般人也就只能呵呵了。”

我們以一個典型方案為例，首先來提煉一下一個IM系統(tǒng)的主要需求：包括賬號、關(guān)系鏈、在線狀態(tài)顯示、消息交互（文本、圖片、語音）、實時視頻電話......。

要處理好上述需求，我們通常需要從以下方面進(jìn)行考量從而設(shè)計出合適的架構(gòu)：

  • 如果采用可靠傳輸協(xié)議TCP，需要考慮到負(fù)載問題：短連接實現(xiàn)賬號、關(guān)系鏈相關(guān)業(yè)務(wù)，長連接實現(xiàn)上線、信息推送；
  • 后臺架構(gòu)的靈活性、可擴(kuò)展性：支持分布式部署——把網(wǎng)絡(luò)層、業(yè)務(wù)邏輯層、數(shù)據(jù)層分離，網(wǎng)絡(luò)層和業(yè)務(wù)層支持負(fù)載均衡策略、數(shù)據(jù)層支持分布式存儲；
  • 客戶端SDK的易用性：把網(wǎng)絡(luò)層、數(shù)據(jù)層分離、業(yè)務(wù)邏輯層分離。

另外，一個典型的IM系統(tǒng)架構(gòu)設(shè)計，還有以下性能方面的熱點問題需要設(shè)計者重點關(guān)注：

  • 編碼角度：采用高效的網(wǎng)絡(luò)模型，線程模型，I/O處理模型，合理的數(shù)據(jù)庫設(shè)計和操作語句的優(yōu)化；
  • 垂直擴(kuò)展：通過提高單服務(wù)器的硬件資源或者網(wǎng)絡(luò)資源來提高性能；
  • 水平擴(kuò)展：通過合理的架構(gòu)設(shè)計和運維方面的負(fù)載均衡策略將負(fù)載分擔(dān)，有效提高性能；后期甚至可以考慮加入數(shù)據(jù)緩存層，突破IO瓶頸；
  • 系統(tǒng)的高可用性：防止單點故障；
  • 在架構(gòu)設(shè)計時做到業(yè)務(wù)處理和數(shù)據(jù)的分離，從而依賴分布式的部署使得在單點故障時能保證系統(tǒng)可用。
  • 對于關(guān)鍵獨立節(jié)點可以采用雙機熱備技術(shù)進(jìn)行切換。
  • 數(shù)據(jù)庫數(shù)據(jù)的安全性可以通過磁盤陣列的冗余配置和主備數(shù)據(jù)庫來解決。

鑒于篇幅有限，架構(gòu)設(shè)計方面的內(nèi)容本文就不深入展開了。

以下文章將為你的移動端IM的架構(gòu)設(shè)計帶來一定的參考意義：

（更多同類文章： 點此進(jìn)入…）

十、移動端IM的通信安全

IM（尤其移動端IM）的安全性一直是開發(fā)者需要優(yōu)先考慮的基礎(chǔ)問題，如何正確地理解和使用加密技術(shù)則顯的尤其重要。IM系統(tǒng)大都采用C/S、B/S、P2P等技術(shù)來實現(xiàn)即時通信的功能，軟件編制沒有統(tǒng)一的標(biāo)準(zhǔn)，使得IM系統(tǒng)本身存有多種安全漏洞，加上用戶缺乏安全意識，導(dǎo)致在使用即時通信系統(tǒng)時出現(xiàn)各種安全問題。

當(dāng)今的計算機密碼學(xué)的主要作用有：加密（ Encryption）、認(rèn)證（Authentication），鑒定（Identification） 。

加密：防止壞人獲取你的數(shù)據(jù)。
認(rèn)證：防止壞人修改了你的數(shù)據(jù)而你卻并沒有發(fā)現(xiàn)。
鑒權(quán)：防止壞人假冒你的身份。

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

以下文章或許有助于您設(shè)計出安全的移動端IM系統(tǒng)：

（更多同類文章：點此進(jìn)入…）

十一、有關(guān)IM中的實時音視頻技術(shù)

IM應(yīng)用中的實時音視頻技術(shù)，幾乎是IM開發(fā)中的最后一道高墻。原因在于：實時音視頻技術(shù) = 音視頻處理技術(shù) + 網(wǎng)絡(luò)傳輸技術(shù) 的橫向技術(shù)應(yīng)用集合體，而公共互聯(lián)網(wǎng)不是為了實時通信設(shè)計的。實時音視頻技術(shù)上的實現(xiàn)內(nèi)容主要包括：音視頻的采集、編碼、網(wǎng)絡(luò)傳輸、解碼、播放等環(huán)節(jié)。這么多項并不簡單的技術(shù)應(yīng)用，如果把握不當(dāng)，將會在在實際開發(fā)過程中遇到一個又一個的坑。

以下文章有助于您從零理解IM的實時音視頻開發(fā)的方方面面：

（更多同類文章： 點此進(jìn)入…）

另外，大家都喜歡開源免費的東西，WebRTC是為數(shù)不多的開源且質(zhì)量上乘的實時音視頻解決方案之一，資料如下：

十二、移動端IM開發(fā)的其它熱點問題

移動端IM開發(fā)中還會遇到上述內(nèi)容未提及的內(nèi)容，以下文章或許您用的上：
《移動端IM開發(fā)需要面對的技術(shù)問題》
《開發(fā)IM是自己設(shè)計協(xié)議用字節(jié)流好還是字符流好？》
《請問有人知道語音留言聊天的主流實現(xiàn)方式嗎？》
《IM消息送達(dá)保證機制實現(xiàn)(一)：保證在線實時消息的可靠投遞》
《IM消息送達(dá)保證機制實現(xiàn)(二)：保證離線消息的可靠投遞》
《如何保證IM實時消息的“時序性”與“一致性”？》
《IM單聊和群聊中的在線狀態(tài)同步應(yīng)該用“推”還是“拉”？》
《IM群聊消息如此復(fù)雜，如何保證不丟不重？》
《談?wù)勔苿佣?IM 開發(fā)中登錄請求的優(yōu)化》
《IM群聊消息如此復(fù)雜，如何保證不丟不重？》
《一種Android端IM智能心跳算法的設(shè)計與實現(xiàn)探討（含樣例代碼）》
《移動端IM登錄時拉取數(shù)據(jù)如何作到省流量？》
《通俗易懂：基于集群的移動端IM接入層負(fù)載均衡方案分享》
《完全自已開發(fā)的IM該如何設(shè)計“失敗重試”機制？》
《微信對網(wǎng)絡(luò)影響的技術(shù)試驗及分析（論文全文）》
《即時通訊系統(tǒng)的原理、技術(shù)和應(yīng)用（技術(shù)論文）》
《開源IM工程“蘑菇街TeamTalk”的現(xiàn)狀：一場有始無終的開源秀》

更多同類文章 ……

十三、參考技術(shù)方案

1. MobileIMSDK工程（已開源）↘

MobileIMSDK首版開發(fā)于2013年（截止2017年6月已更新至v3版），它主要使用原生代碼編寫，應(yīng)用于非Web網(wǎng)頁方式的移動端即時通訊場景下，詳細(xì)介紹請見：http://www.52im.net/thread-52-1-1.html。

2. MobileIMSDK-Web工程（捐助作者得精編源碼）↘

MobileIMSDK-Web首版開發(fā)于2016年（目前仍在不斷完善中），完全使用JavaScript編寫，主要應(yīng)用于Web網(wǎng)頁方式的即時通訊場景下（包括但不限于手機端、PC端的網(wǎng)頁聊天或消息推送等），詳細(xì)介紹請見：http://www.52im.net/thread-959-1-1.html。

3. RainbowAV工程（捐助作者得精編源碼）↘

RainbowAV是一套完整移動端實時音視頻框架(含服務(wù)端)，支持分布式，不依賴于第3方服務(wù)，可私有化部署，使用方便，部署簡單，輕量級、模塊化設(shè)計，開發(fā)者可方便修改、演進(jìn)甚至用于2次開發(fā)，詳細(xì)介紹請見：http://www.52im.net/thread-1027-1-1.html。

4. RainbowChat產(chǎn)品級IM系統(tǒng) ↘

RainbowChat是一套基于MobileIMSDK的產(chǎn)品級移動端IM系統(tǒng)。RainbowChat源于真實運營的產(chǎn)品，運營統(tǒng)計：點此進(jìn)入，不同于市面上開源或售賣的demo級代碼，RainbowChat的產(chǎn)品前身已被成千上萬真實的客戶使用過，解決了大量的屏幕適配、細(xì)節(jié)優(yōu)化、機器兼容問題（可自行下載體驗），詳細(xì)介紹請見：http://www.52im.net/thread-19-1-1.html。

附錄1：其它即時通訊文章

[1] 有關(guān)WEB端即時通訊開發(fā)：
《新手入門貼：史上最全Web端即時通訊技術(shù)原理詳解》
《Web端即時通訊技術(shù)盤點：短輪詢、Comet、Websocket、SSE》
《SSE技術(shù)詳解：一種全新的HTML5服務(wù)器推送事件技術(shù)》
《Comet技術(shù)詳解：基于HTTP長連接的Web端實時通信技術(shù)》
《新手快速入門：WebSocket簡明教程》
《WebSocket詳解（一）：初步認(rèn)識WebSocket技術(shù)》
《WebSocket詳解（二）：技術(shù)原理、代碼演示和應(yīng)用案例》
《WebSocket詳解（三）：深入WebSocket通信協(xié)議細(xì)節(jié)》
《WebSocket詳解（四）：刨根問底HTTP與WebSocket的關(guān)系(上篇)》
《WebSocket詳解（五）：刨根問底HTTP與WebSocket的關(guān)系(下篇)》
《WebSocket詳解（六）：刨根問底WebSocket與Socket的關(guān)系》
《socket.io實現(xiàn)消息推送的一點實踐及思路》
《LinkedIn的Web端即時通訊實踐：實現(xiàn)單機幾十萬條長連接》
《Web端即時通訊技術(shù)的發(fā)展與WebSocket、Socket.io的技術(shù)實踐》
《Web端即時通訊安全：跨站點WebSocket劫持漏洞詳解(含示例代碼)》
《開源框架Pomelo實踐：搭建Web端高性能分布式IM聊天服務(wù)器》
《使用WebSocket和SSE技術(shù)實現(xiàn)Web端消息推送》
《詳解Web端通信方式的演進(jìn)：從Ajax、JSONP 到 SSE、Websocket》
《MobileIMSDK-Web的網(wǎng)絡(luò)層框架為何使用的是Socket.io而不是Netty？》
《理論聯(lián)系實際：從零理解WebSocket的通信原理、協(xié)議格式、安全性》

更多同類文章 ……

[2] 有關(guān)推送技術(shù)的文章：
《iOS的推送服務(wù)APNs詳解：設(shè)計思路、技術(shù)原理及缺陷等》
《Android端消息推送總結(jié)：實現(xiàn)原理、心跳保活、遇到的問題等》
《掃盲貼：認(rèn)識MQTT通信協(xié)議》
《一個基于MQTT通信協(xié)議的完整Android推送Demo》
《求教android消息推送：GCM、XMPP、MQTT三種方案的優(yōu)劣》
《移動端實時消息推送技術(shù)淺析》
《掃盲貼：淺談iOS和Android后臺實時消息推送的原理和區(qū)別》
《絕對干貨：基于Netty實現(xiàn)海量接入的推送服務(wù)技術(shù)要點》
《移動端IM實踐：谷歌消息推送服務(wù)(GCM)研究（來自微信）》
《為何微信、QQ這樣的IM工具不使用GCM服務(wù)推送消息？》
《極光推送系統(tǒng)大規(guī)模高并發(fā)架構(gòu)的技術(shù)實踐分享》
《從HTTP到MQTT：一個基于位置服務(wù)的APP數(shù)據(jù)通信實踐概述》
《魅族2500萬長連接的實時消息推送架構(gòu)的技術(shù)實踐分享》
《專訪魅族架構(gòu)師：海量長連接的實時消息推送系統(tǒng)的心得體會》
《深入的聊聊Android消息推送這件小事》

更多同類文章 ……

[3] 更多即時通訊技術(shù)好文分類：
http://www.52im.net/forum.php?mod=collection&op=all

附錄2：來自IM大廠的精華文章匯總

[1] 有關(guān)QQ、微信的技術(shù)文章：
《微信團(tuán)隊分享：微信每日億次實時音視頻聊天背后的技術(shù)解密》
《QQ音樂團(tuán)隊分享：Android中的圖片壓縮技術(shù)詳解（上篇）》
《QQ音樂團(tuán)隊分享：Android中的圖片壓縮技術(shù)詳解（下篇）》
《騰訊團(tuán)隊分享：手機QQ中的人臉識別酷炫動畫效果實現(xiàn)詳解》
《騰訊團(tuán)隊分享 ：一次手Q聊天界面中圖片顯示bug的追蹤過程分享》
《微信團(tuán)隊分享：微信Android版小視頻編碼填過的那些坑》
《微信手機端的本地數(shù)據(jù)全文檢索優(yōu)化之路》
《企業(yè)微信客戶端中組織架構(gòu)數(shù)據(jù)的同步更新方案優(yōu)化實戰(zhàn)》
《微信團(tuán)隊披露：微信界面卡死超級bug“15。。。。”的來龍去脈》
《QQ 18年：解密8億月活的QQ后臺服務(wù)接口隔離技術(shù)》
《月活8.89億的超級IM微信是如何進(jìn)行Android端兼容測試的》
《以手機QQ為例探討移動端IM中的“輕應(yīng)用”》
《一篇文章get微信開源移動端數(shù)據(jù)庫組件WCDB的一切！》
《微信客戶端團(tuán)隊負(fù)責(zé)人技術(shù)訪談：如何著手客戶端性能監(jiān)控和優(yōu)化》
《微信后臺基于時間序的海量數(shù)據(jù)冷熱分級架構(gòu)設(shè)計實踐》
《微信團(tuán)隊原創(chuàng)分享：Android版微信的臃腫之困與模塊化實踐之路》
《微信后臺團(tuán)隊：微信后臺異步消息隊列的優(yōu)化升級實踐分享》
《微信團(tuán)隊原創(chuàng)分享：微信客戶端SQLite數(shù)據(jù)庫損壞修復(fù)實踐》
《騰訊原創(chuàng)分享(一)：如何大幅提升移動網(wǎng)絡(luò)下手機QQ的圖片傳輸速度和成功率》
《騰訊原創(chuàng)分享(二)：如何大幅壓縮移動網(wǎng)絡(luò)下APP的流量消耗（下篇）》
《騰訊原創(chuàng)分享(二)：如何大幅壓縮移動網(wǎng)絡(luò)下APP的流量消耗（上篇）》
《微信Mars：微信內(nèi)部正在使用的網(wǎng)絡(luò)層封裝庫，即將開源》
《如約而至：微信自用的移動端IM網(wǎng)絡(luò)層跨平臺組件庫Mars已正式開源》
《開源libco庫：單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《微信團(tuán)隊原創(chuàng)分享：Android版微信后臺保活實戰(zhàn)分享(進(jìn)程保活篇)》
《微信團(tuán)隊原創(chuàng)分享：Android版微信后臺保活實戰(zhàn)分享(網(wǎng)絡(luò)保活篇)》
《Android版微信從300KB到30MB的技術(shù)演進(jìn)(PPT講稿) [附件下載]》
《微信團(tuán)隊原創(chuàng)分享：Android版微信從300KB到30MB的技術(shù)演進(jìn)》
《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(演講全文)》
《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(PPT講稿) [附件下載]》
《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡》》
《微信海量用戶背后的后臺系統(tǒng)存儲架構(gòu)(視頻+PPT) [附件下載]》
《微信異步化改造實踐：8億月活、單機千萬連接背后的后臺解決方案》
《微信朋友圈海量技術(shù)之道PPT [附件下載]》
《微信對網(wǎng)絡(luò)影響的技術(shù)試驗及分析（論文全文）》
《一份微信后臺技術(shù)架構(gòu)的總結(jié)性筆記》
《架構(gòu)之道：3個程序員成就微信朋友圈日均10億發(fā)布量[有視頻]》
《快速裂變：見證微信強大后臺架構(gòu)從0到1的演進(jìn)歷程（一）》
《快速裂變：見證微信強大后臺架構(gòu)從0到1的演進(jìn)歷程（二）》
《微信團(tuán)隊原創(chuàng)分享：Android內(nèi)存泄漏監(jiān)控和優(yōu)化技巧總結(jié)》
《全面總結(jié)iOS版微信升級iOS9遇到的各種“坑”》
《微信團(tuán)隊原創(chuàng)資源混淆工具：讓你的APK立減1M》
《微信團(tuán)隊原創(chuàng)Android資源混淆工具：AndResGuard [有源碼]》
《Android版微信安裝包“減肥”實戰(zhàn)記錄》
《iOS版微信安裝包“減肥”實戰(zhàn)記錄》
《移動端IM實踐：iOS版微信界面卡頓監(jiān)測方案》
《微信“紅包照片”背后的技術(shù)難題》
《移動端IM實踐：iOS版微信小視頻功能技術(shù)方案實錄》
《移動端IM實踐：Android版微信如何大幅提升交互性能（一）》
《移動端IM實踐：Android版微信如何大幅提升交互性能（二）》
《移動端IM實踐：實現(xiàn)Android版微信的智能心跳機制》
《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》
《移動端IM實踐：谷歌消息推送服務(wù)(GCM)研究（來自微信）》
《移動端IM實踐：iOS版微信的多設(shè)備字體適配方案探討》
《信鴿團(tuán)隊原創(chuàng)：一起走過 iOS10 上消息推送(APNS)的坑》
《騰訊信鴿技術(shù)分享：百億級實時消息推送的實戰(zhàn)經(jīng)驗》

更多同類文章 ……

[2] 有關(guān)QQ、微信的技術(shù)故事：
《2017微信數(shù)據(jù)報告：日活躍用戶達(dá)9億、日發(fā)消息380億條》
《騰訊開發(fā)微信花了多少錢？技術(shù)難度真這么大？難在哪？》
《技術(shù)往事：創(chuàng)業(yè)初期的騰訊——16年前的冬天，誰動了馬化騰的代碼》
《技術(shù)往事：史上最全QQ圖標(biāo)變遷過程，追尋IM巨人的演進(jìn)歷史》
《技術(shù)往事：“QQ群”和“微信紅包”是怎么來的？》
《開發(fā)往事：深度講述2010到2015，微信一路風(fēng)雨的背后》
《開發(fā)往事：微信千年不變的那張閃屏圖片的由來》
《開發(fā)往事：記錄微信3.0版背后的故事（距微信1.0發(fā)布9個月時）》
《一個微信實習(xí)生自述：我眼中的微信開發(fā)團(tuán)隊》
《首次揭秘：QQ實時視頻聊天背后的神秘組織》

更多同類文章 …… |

轉(zhuǎn)自：http://www.52im.net/thread-464-1-1.html

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個濱河市，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌，老刑警劉巖，帶你破解...
    沈念sama閱讀 229,565評論 6贊 539
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場離奇詭異，居然都是意外死亡，警方通過查閱死者的電腦和手機，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 99,115評論 3贊 423
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人，你說我怎么就攤上這事。” “怎么了？”我有些...
    開封第一講書人閱讀 177,577評論 0贊 382
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長。 經(jīng)常有香客問我，道長，這世上最難降的妖魔是什么？ 我笑而不...
    開封第一講書人閱讀 63,514評論 1贊 316
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘。我一直安慰自己，他們只是感情好，可當(dāng)我...
    茶點故事閱讀 72,234評論 6贊 410
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布。 她就那樣靜靜地躺著，像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上，一...
    開封第一講書人閱讀 55,621評論 1贊 326
  • 城市分裂傳說
    那天，我揣著相機與錄音，去河邊找鬼。 笑死，一個胖子當(dāng)著我的面吹牛，可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播，決...
    沈念sama閱讀 43,641評論 3贊 444
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼！你這毒婦竟也來了？” 一聲冷哼從身側(cè)響起，我...
    開封第一講書人閱讀 42,822評論 0贊 289
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體，經(jīng)...
    沈念sama閱讀 49,380評論 1贊 335
  • ?護(hù)林員之死
    正文 獨居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 41,128評論 3贊 356
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,319評論 1贊 371
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情，我是刑警寧澤，帶...
    沈念sama閱讀 38,879評論 5贊 362
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布，位于F島的核電站，受9級特大地震影響，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜，卻給世界環(huán)境...
    茶點故事閱讀 44,548評論 3贊 348
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧，春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,970評論 0贊 28
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,229評論 1贊 291
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留，地道東北人。 一個月前我還...
    沈念sama閱讀 52,048評論 3贊 397
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像，于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 48,285評論 2贊 376