1、前言

本文的上篇《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(一)：保證在線實(shí)時(shí)消息的可靠投遞》中，我們討論了在線實(shí)時(shí)消息的投遞可以通過(guò)應(yīng)用層的確認(rèn)、發(fā)送方的超時(shí)重傳、接收方的去重等手段來(lái)保證業(yè)務(wù)層面消息的不丟不重。

但實(shí)時(shí)在線投遞針對(duì)的是消息收發(fā)雙方都在線的情況（如當(dāng)發(fā)送方用戶A發(fā)送消息給接收方用戶B時(shí)，用戶B是在線的），那如果消息的接收方用戶B不在線，系統(tǒng)是如何保證消息的可達(dá)性的呢？這就是本文要討論的問(wèn)題。（本文同步發(fā)布于：http://www.52im.net/thread-594-1-1.html）

2、學(xué)習(xí)交流 

- 即時(shí)通訊開發(fā)交流群： 215891622 [推薦]

- 移動(dòng)端IM開發(fā)推薦文章：《新手入門一篇就夠：從零開發(fā)移動(dòng)端IM》

3、IM消息送達(dá)保證系列文章

本文是討論IM消息送達(dá)保證系列文章中的第2篇，總目錄如下：

• 《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(一)：保證在線實(shí)時(shí)消息的可靠投遞》
• 《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(二)：保證離線消息的可靠投遞》（本文）

另外，如果您正在查閱移動(dòng)端IM開發(fā)資料，推薦閱讀《新手入門一篇就夠：從零開發(fā)移動(dòng)端IM》。

4、消息接收方不在線時(shí)的典型消息發(fā)送流程

 

如上圖所述，通常此類情況下消息的發(fā)送流程如下：

• Step 1：用戶A發(fā)送一條消息給用戶B；
• Step 2：服務(wù)器查看用戶B的狀態(tài)，發(fā)現(xiàn)B的狀態(tài)為“offline”（即B當(dāng)前不在線）；
• Step 3：服務(wù)器將此條消息以離線消息的形式持久化存儲(chǔ)到DB中（當(dāng)然，具體的持久化方案可由您IM的具體技術(shù)實(shí)現(xiàn)為準(zhǔn)）；
• Step 4：服務(wù)器返回用戶A“發(fā)送成功”ACK確認(rèn)包（注：對(duì)于消息發(fā)送方而言，消息一旦落地存儲(chǔ)至DB就認(rèn)為是發(fā)送成功了）。

關(guān)于 “Step 4” 的補(bǔ)充說(shuō)明：

請(qǐng)一定要理解“Step 4”，因?yàn)楝F(xiàn)在無(wú)論是傳統(tǒng)的PC端IM（類似QQ這樣的——可以在UI上看到好友的在線、離線狀態(tài)）還是目前主流的移動(dòng)端IM（強(qiáng)調(diào)的是用戶全時(shí)在線——即你看不到好友到底在線還是離線，反正給你的假像就是這個(gè)好友“應(yīng)該”是在線的），消息發(fā)送出去后，無(wú)論是對(duì)方實(shí)時(shí)在線收到還是對(duì)方不在線而被服務(wù)端離線存儲(chǔ)了，對(duì)于發(fā)送方而言只要消息沒有因?yàn)榫W(wǎng)絡(luò)等原因莫名消失，就應(yīng)該認(rèn)為是“被收到了”。

從技術(shù)的角度講，消息接收方收到的消息應(yīng)答ACK包的真正發(fā)起者，實(shí)際上有兩種可能性：一種是由接收方發(fā)出、而另一種是由服務(wù)端代為發(fā)送（這在MobileIMSDK開源工程里被稱作“偽應(yīng)答”）。

5、典型離線消息表的設(shè)計(jì)以及拉取離線消息的過(guò)程

① 存儲(chǔ)離線消看書的表主要字段大致如下：

② 離線消息拉取模式：
接收方B要拉取發(fā)送方A給ta發(fā)送的離線消息，只需在receiver_uid（即接收方B的用戶ID), sender_uid（即發(fā)送方A的用戶ID）上查詢，然后把離線消息刪除，再把消息返回B即可。

③ 離線消息的拉取，如果用SQL語(yǔ)句來(lái)描述的話，它可以是：

④ 離線拉取的整體流程如下圖所示：

• Stelp 1：用戶B開始拉取用戶A發(fā)送給ta的離線消息；
• Stelp 2：服務(wù)器從DB（或?qū)?yīng)的持久化容器）中拉取離線消息；
• Stelp 3：服務(wù)器從DB（或?qū)?yīng)的持久化容器）中把離線消息刪除；
• Stelp 4：服務(wù)器返回給用戶B想要的離線消息。

6、上述流程存在的問(wèn)題以及優(yōu)化方案

如果用戶B有很多好友，登陸時(shí)客戶端需要對(duì)所有好友進(jìn)行離線消息拉取，客戶端與服務(wù)器交互次數(shù)就會(huì)比較多。

① 拉取好友離線消息的客戶端偽代碼：

② 優(yōu)化方案1：
先拉取各個(gè)好友的離線消息數(shù)量，真正用戶B進(jìn)去看離線消息時(shí)，才往服務(wù)器發(fā)送拉取請(qǐng)求（手機(jī)端為了節(jié)省流量，經(jīng)常會(huì)使用這個(gè)按需拉取的優(yōu)化）。

③ 優(yōu)化方案2：
如下圖所示，一次性拉取所有好友發(fā)送給用戶B的離線消息，到客戶端本地再根據(jù)sender_uid進(jìn)行計(jì)算，這樣的話，離校消息表的訪問(wèn)模式就變?yōu)?>只需要按照receiver_uid來(lái)查詢了。登錄時(shí)與服務(wù)器的交互次數(shù)降低為了1次。

 

④ 方案小結(jié)：
通常情況下，主流的的移動(dòng)端IM（比如微信、手Q等）通常都是以“優(yōu)化方案2”為主，因?yàn)橐苿?dòng)網(wǎng)絡(luò)的不可靠性加上電量、流量等資源的昂貴性，能盡量一次性干完的事，就盡可能一次搞定，從而提供整個(gè)APP的用戶體驗(yàn)（對(duì)于移動(dòng)端應(yīng)用而言，省電、省流量同樣是用戶體驗(yàn)的一部分）。這方面的文章，可以進(jìn)一步參閱《談?wù)勔苿?dòng)端 IM 開發(fā)中登錄請(qǐng)求的優(yōu)化》、《移動(dòng)端IM實(shí)踐：iOS版微信界面卡頓監(jiān)測(cè)方案》、《移動(dòng)端IM實(shí)踐：Android版微信如何大幅提升交互性能（二）》。

7、消息接收方一次拉取大量離線消息導(dǎo)致速度慢、卡頓的解決方法

用戶B一次性拉取所有好友發(fā)給ta的離線消息，消息量很大時(shí)，一個(gè)請(qǐng)求包很大、速度慢，容易卡頓怎么辦？

 

正如上圖所示，我們可以分頁(yè)拉?。焊鶕?jù)業(yè)務(wù)需求，先拉取最新（或者最舊）的一頁(yè)消息，再按需一頁(yè)頁(yè)拉取，這樣便能很好地解決用戶體驗(yàn)問(wèn)題。

8、優(yōu)化離線消息的拉取過(guò)程，保證離線消息不會(huì)丟失

如何保證可達(dá)性，上述步驟第三步執(zhí)行完畢之后，第四個(gè)步驟離線消息返回給客戶端過(guò)程中，服務(wù)器掛點(diǎn)，路由器丟消息，或者客戶端crash了，那離線消息豈不是丟了么（數(shù)據(jù)庫(kù)已刪除，用戶還沒收到）？

確實(shí)，如果按照上述的1、2、3、4步流程，的確是的，那如何保證離線消息的絕對(duì)可靠性、可達(dá)性？

 

如同在線消息的應(yīng)用層ACK機(jī)制一樣，離線消息拉時(shí)，不能夠直接刪除數(shù)據(jù)庫(kù)中的離線消息，而必須等應(yīng)用層的離線消息ACK（說(shuō)明用戶B真的收到離線消息了），才能刪除數(shù)據(jù)庫(kù)中的離線消息。這個(gè)應(yīng)用層的ACK可以通過(guò)實(shí)時(shí)消息通道告之服務(wù)端，也可以通過(guò)服務(wù)端提供的REST接口，以更通用、簡(jiǎn)單的方式通知服務(wù)端。

9、進(jìn)一步優(yōu)化，解決重復(fù)拉取離線消息的問(wèn)題

如果用戶B拉取了一頁(yè)離線消息，卻在ACK之前crash了，下次登錄時(shí)會(huì)拉取到重復(fù)的離線消息么？

確實(shí)，拉取了離線消息卻沒有ACK，服務(wù)器不會(huì)刪除之前的離線消息，故下次登錄時(shí)系統(tǒng)層面還會(huì)拉取到。但在業(yè)務(wù)層面，可以根據(jù)msg_id去重。SMC理論：系統(tǒng)層面無(wú)法做到消息不丟不重，業(yè)務(wù)層面可以做到，對(duì)用戶無(wú)感知。

優(yōu)化后的拉取過(guò)程，如下圖所示：
 

10、進(jìn)一步優(yōu)化，降低離線拉取ACK帶來(lái)的額外與服務(wù)器的交互次數(shù)

假設(shè)有N頁(yè)離線消息，現(xiàn)在每個(gè)離線消息需要一個(gè)ACK，那么豈不是客戶端與服務(wù)器的交互次數(shù)又加倍了？有沒有優(yōu)化空間？

 

如上圖所示，不用每一頁(yè)消息都ACK，在拉取第二頁(yè)消息時(shí)相當(dāng)于第一頁(yè)消息的ACK，此時(shí)服務(wù)器再刪除第一頁(yè)的離線消息即可，最后一頁(yè)消息再ACK一次（實(shí)際上：最后一頁(yè)拉取的肯定是空返回，這樣可以極大地簡(jiǎn)化這個(gè)分頁(yè)過(guò)程，否則客戶端得知道當(dāng)前離線消息的總頁(yè)數(shù)，而由于消息讀取延遲的存在，這個(gè)總頁(yè)數(shù)理論上并非絕對(duì)不變，從而加大了數(shù)據(jù)讀取不一致的可能性）。這樣的效果是，不管拉取多少頁(yè)離線消息，只會(huì)多一個(gè)ACK請(qǐng)求，與服務(wù)器多一次交互。

11、本文小結(jié)

正如本文中所列舉的問(wèn)題所描述的那樣，保證“離線消息”的可達(dá)性比大家想象的要復(fù)雜一些，常見優(yōu)化總結(jié)如下：

• 1）對(duì)于同一個(gè)用戶B，一次性拉取所有用戶發(fā)給ta的離線消息，再在客戶端本地進(jìn)行發(fā)送方分析，相比按照發(fā)送方一個(gè)個(gè)進(jìn)行消息拉取，能大大減少服務(wù)器交互次數(shù)；
• 2）分頁(yè)拉取，先拉取計(jì)數(shù)再按需拉取，是無(wú)線端的常見優(yōu)化；
• 3）應(yīng)用層的ACK，應(yīng)用層的去重，才能保證離線消息的不丟不重；
• 4）下一頁(yè)的拉取，同時(shí)作為上一頁(yè)的ACK，能夠極大減少與服務(wù)器的交互次數(shù)。

（本文同步發(fā)布于：http://www.52im.net/thread-594-1-1.html，本文內(nèi)容參考了：微信為啥不丟“離線消息”）

12、IM技術(shù)資料分類

[1] 網(wǎng)絡(luò)編程基礎(chǔ)資料：
《TCP/IP詳解 - 第11章·UDP：用戶數(shù)據(jù)報(bào)協(xié)議》
《TCP/IP詳解 - 第17章·TCP：傳輸控制協(xié)議》
《TCP/IP詳解 - 第18章·TCP連接的建立與終止》
《TCP/IP詳解 - 第21章·TCP的超時(shí)與重傳》
《技術(shù)往事：改變世界的TCP/IP協(xié)議（珍貴多圖、手機(jī)慎點(diǎn)）》
《通俗易懂-深入理解TCP協(xié)議（上）：理論基礎(chǔ)》
《通俗易懂-深入理解TCP協(xié)議（下）：RTT、滑動(dòng)窗口、擁塞處理》
《理論經(jīng)典：TCP協(xié)議的3次握手與4次揮手過(guò)程詳解》
《理論聯(lián)系實(shí)際：Wireshark抓包分析TCP 3次握手、4次揮手過(guò)程》
《計(jì)算機(jī)網(wǎng)絡(luò)通訊協(xié)議關(guān)系圖（中文珍藏版）》
《UDP中一個(gè)包的大小最大能多大？》
《Java新一代網(wǎng)絡(luò)編程模型AIO原理及Linux系統(tǒng)AIO介紹》
《NIO框架入門(一)：服務(wù)端基于Netty4的UDP雙向通信Demo演示》
《NIO框架入門(二)：服務(wù)端基于MINA2的UDP雙向通信Demo演示》
《NIO框架入門(三)：iOS與MINA2、Netty4的跨平臺(tái)UDP雙向通信實(shí)戰(zhàn)》
《NIO框架入門(四)：Android與MINA2、Netty4的跨平臺(tái)UDP雙向通信實(shí)戰(zhàn)》
《P2P技術(shù)詳解(一)：NAT詳解——詳細(xì)原理、P2P簡(jiǎn)介》
《P2P技術(shù)詳解(二)：P2P中的NAT穿越(打洞)方案詳解》
《P2P技術(shù)詳解(三)：P2P技術(shù)之STUN、TURN、ICE詳解》
《高性能網(wǎng)絡(luò)編程(一)：?jiǎn)闻_(tái)服務(wù)器并發(fā)TCP連接數(shù)到底可以有多少》
《高性能網(wǎng)絡(luò)編程(二)：上一個(gè)10年，著名的C10K并發(fā)連接問(wèn)題》
《高性能網(wǎng)絡(luò)編程(三)：下一個(gè)10年，是時(shí)候考慮C10M并發(fā)問(wèn)題了》
《高性能網(wǎng)絡(luò)編程(四)：從C10K到C10M高性能網(wǎng)絡(luò)應(yīng)用的理論探索》
>> 更多同類文章 ……

[2] 有關(guān)IM/推送的通信格式、協(xié)議的選擇：
《為什么QQ用的是UDP協(xié)議而不是TCP協(xié)議？》
《移動(dòng)端即時(shí)通訊協(xié)議選擇：UDP還是TCP？》
《如何選擇即時(shí)通訊應(yīng)用的數(shù)據(jù)傳輸格式》
《強(qiáng)列建議將Protobuf作為你的即時(shí)通訊應(yīng)用數(shù)據(jù)傳輸格式》
《移動(dòng)端IM開發(fā)需要面對(duì)的技術(shù)問(wèn)題（含通信協(xié)議選擇）》
《簡(jiǎn)述移動(dòng)端IM開發(fā)的那些坑：架構(gòu)設(shè)計(jì)、通信協(xié)議和客戶端》
《理論聯(lián)系實(shí)際：一套典型的IM通信協(xié)議設(shè)計(jì)詳解》
《58到家實(shí)時(shí)消息系統(tǒng)的協(xié)議設(shè)計(jì)等技術(shù)實(shí)踐分享》
>> 更多同類文章 ……

[3] 有關(guān)IM/推送的心跳保活處理：
《Android進(jìn)程保活詳解：一篇文章解決你的所有疑問(wèn)》
《Android端消息推送總結(jié)：實(shí)現(xiàn)原理、心跳保活、遇到的問(wèn)題等》
《為何基于TCP協(xié)議的移動(dòng)端IM仍然需要心跳保活機(jī)制？》
《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺(tái)?；顚?shí)戰(zhàn)分享(進(jìn)程?；钇?》
《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺(tái)?；顚?shí)戰(zhàn)分享(網(wǎng)絡(luò)?；钇?》
《移動(dòng)端IM實(shí)踐：實(shí)現(xiàn)Android版微信的智能心跳機(jī)制》
《移動(dòng)端IM實(shí)踐：WhatsApp、Line、微信的心跳策略分析》
>> 更多同類文章 ……

[4] 有關(guān)WEB端即時(shí)通訊開發(fā)：
《新手入門貼：史上最全Web端即時(shí)通訊技術(shù)原理詳解》
《Web端即時(shí)通訊技術(shù)盤點(diǎn)：短輪詢、Comet、Websocket、SSE》
《SSE技術(shù)詳解：一種全新的HTML5服務(wù)器推送事件技術(shù)》
《Comet技術(shù)詳解：基于HTTP長(zhǎng)連接的Web端實(shí)時(shí)通信技術(shù)》
《WebSocket詳解（一）：初步認(rèn)識(shí)WebSocket技術(shù)》
《socket.io實(shí)現(xiàn)消息推送的一點(diǎn)實(shí)踐及思路》
>> 更多同類文章 ……

[5] 有關(guān)IM架構(gòu)設(shè)計(jì)：
《淺談IM系統(tǒng)的架構(gòu)設(shè)計(jì)》
《簡(jiǎn)述移動(dòng)端IM開發(fā)的那些坑：架構(gòu)設(shè)計(jì)、通信協(xié)議和客戶端》
《一套原創(chuàng)分布式即時(shí)通訊(IM)系統(tǒng)理論架構(gòu)方案》
《從零到卓越：京東客服即時(shí)通訊系統(tǒng)的技術(shù)架構(gòu)演進(jìn)歷程》
《蘑菇街即時(shí)通訊/IM服務(wù)器開發(fā)之架構(gòu)選擇》
《騰訊QQ1.4億在線用戶的技術(shù)挑戰(zhàn)和架構(gòu)演進(jìn)之路PPT》
《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)(演講全文)》
《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)》》
《快速裂變：見證微信強(qiáng)大后臺(tái)架構(gòu)從0到1的演進(jìn)歷程（一）》
《17年的實(shí)踐：騰訊海量產(chǎn)品的技術(shù)方法論》
>> 更多同類文章 ……

[6] 有關(guān)IM安全的文章：
《即時(shí)通訊安全篇（一）：正確地理解和使用Android端加密算法》
《即時(shí)通訊安全篇（二）：探討組合加密算法在IM中的應(yīng)用》
《即時(shí)通訊安全篇（三）：常用加解密算法與通訊安全講解》
《即時(shí)通訊安全篇（四）：實(shí)例分析Android中密鑰硬編碼的風(fēng)險(xiǎn)》
《傳輸層安全協(xié)議SSL/TLS的Java平臺(tái)實(shí)現(xiàn)簡(jiǎn)介和Demo演示》
《理論聯(lián)系實(shí)際：一套典型的IM通信協(xié)議設(shè)計(jì)詳解（含安全層設(shè)計(jì)）》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《來(lái)自阿里OpenIM：打造安全可靠即時(shí)通訊服務(wù)的技術(shù)實(shí)踐分享》
>> 更多同類文章 ……

[7] 有關(guān)實(shí)時(shí)音視頻開發(fā)：
《即時(shí)通訊音視頻開發(fā)（一）：視頻編解碼之理論概述》
《即時(shí)通訊音視頻開發(fā)（二）：視頻編解碼之?dāng)?shù)字視頻介紹》
《即時(shí)通訊音視頻開發(fā)（三）：視頻編解碼之編碼基礎(chǔ)》
《即時(shí)通訊音視頻開發(fā)（四）：視頻編解碼之預(yù)測(cè)技術(shù)介紹》
《即時(shí)通訊音視頻開發(fā)（五）：認(rèn)識(shí)主流視頻編碼技術(shù)H.264》
《即時(shí)通訊音視頻開發(fā)（六）：如何開始音頻編解碼技術(shù)的學(xué)習(xí)》
《即時(shí)通訊音視頻開發(fā)（七）：音頻基礎(chǔ)及編碼原理入門》
《即時(shí)通訊音視頻開發(fā)（八）：常見的實(shí)時(shí)語(yǔ)音通訊編碼標(biāo)準(zhǔn)》
《即時(shí)通訊音視頻開發(fā)（九）：實(shí)時(shí)語(yǔ)音通訊的回音及回音消除概述》
《即時(shí)通訊音視頻開發(fā)（十）：實(shí)時(shí)語(yǔ)音通訊的回音消除技術(shù)詳解》
《即時(shí)通訊音視頻開發(fā)（十一）：實(shí)時(shí)語(yǔ)音通訊丟包補(bǔ)償技術(shù)詳解》
《即時(shí)通訊音視頻開發(fā)（十二）：多人實(shí)時(shí)音視頻聊天架構(gòu)探討》
《即時(shí)通訊音視頻開發(fā)（十三）：實(shí)時(shí)視頻編碼H.264的特點(diǎn)與優(yōu)勢(shì)》
《即時(shí)通訊音視頻開發(fā)（十四）：實(shí)時(shí)音視頻數(shù)據(jù)傳輸協(xié)議介紹》
《即時(shí)通訊音視頻開發(fā)（十五）：聊聊P2P與實(shí)時(shí)音視頻的應(yīng)用情況》
《即時(shí)通訊音視頻開發(fā)（十六）：移動(dòng)端實(shí)時(shí)音視頻開發(fā)的幾個(gè)建議》
《即時(shí)通訊音視頻開發(fā)（十七）：視頻編碼H.264、V8的前世今生》
《學(xué)習(xí)RFC3550：RTP/RTCP實(shí)時(shí)傳輸協(xié)議基礎(chǔ)知識(shí)》
《簡(jiǎn)述開源實(shí)時(shí)音視頻技術(shù)WebRTC的優(yōu)缺點(diǎn)》
《良心分享：WebRTC 零基礎(chǔ)開發(fā)者教程（中文）》
《開源實(shí)時(shí)音視頻技術(shù)WebRTC中RTP/RTCP數(shù)據(jù)傳輸協(xié)議的應(yīng)用》
《基于RTMP數(shù)據(jù)傳輸協(xié)議的實(shí)時(shí)流媒體技術(shù)研究（論文全文）》
《聲網(wǎng)架構(gòu)師談實(shí)時(shí)音視頻云的實(shí)現(xiàn)難點(diǎn)(視頻采訪)》
《淺談開發(fā)實(shí)時(shí)視頻直播平臺(tái)的技術(shù)要點(diǎn)》
《還在靠“喂喂喂”測(cè)試實(shí)時(shí)語(yǔ)音通話質(zhì)量？本文教你科學(xué)的評(píng)測(cè)方法！》
《實(shí)現(xiàn)延遲低于500毫秒的1080P實(shí)時(shí)音視頻直播的實(shí)踐分享》
《移動(dòng)端實(shí)時(shí)視頻直播技術(shù)實(shí)踐：如何做到實(shí)時(shí)秒開、流暢不卡》
《如何用最簡(jiǎn)單的方法測(cè)試你的實(shí)時(shí)音視頻方案》
《技術(shù)揭秘：支持百萬(wàn)級(jí)粉絲互動(dòng)的Facebook實(shí)時(shí)視頻直播》
>> 更多同類文章 ……

[8] IM開發(fā)綜合文章：
《移動(dòng)端IM開發(fā)需要面對(duì)的技術(shù)問(wèn)題》
《開發(fā)IM是自己設(shè)計(jì)協(xié)議用字節(jié)流好還是字符流好？》
《請(qǐng)問(wèn)有人知道語(yǔ)音留言聊天的主流實(shí)現(xiàn)方式嗎？》
《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(一)：保證在線實(shí)時(shí)消息的可靠投遞》
《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(二)：保證離線消息的可靠投遞》
《談?wù)勔苿?dòng)端 IM 開發(fā)中登錄請(qǐng)求的優(yōu)化》
《完全自已開發(fā)的IM該如何設(shè)計(jì)“失敗重試”機(jī)制？》
《微信對(duì)網(wǎng)絡(luò)影響的技術(shù)試驗(yàn)及分析（論文全文）》
《即時(shí)通訊系統(tǒng)的原理、技術(shù)和應(yīng)用（技術(shù)論文）》
《開源IM工程“蘑菇街TeamTalk”的現(xiàn)狀：一場(chǎng)有始無(wú)終的開源秀》
>> 更多同類文章 …… 

[9] 開源移動(dòng)端IM技術(shù)框架資料：
《開源移動(dòng)端IM技術(shù)框架MobileIMSDK：快速入門》
《開源移動(dòng)端IM技術(shù)框架MobileIMSDK：常見問(wèn)題解答》
《開源移動(dòng)端IM技術(shù)框架MobileIMSDK：壓力測(cè)試報(bào)告》
>> 更多同類文章 ……

[10] 有關(guān)推送技術(shù)的文章：
《iOS的推送服務(wù)APNs詳解：設(shè)計(jì)思路、技術(shù)原理及缺陷等》
《Android端消息推送總結(jié)：實(shí)現(xiàn)原理、心跳?；睢⒂龅降膯?wèn)題等》
《掃盲貼：認(rèn)識(shí)MQTT通信協(xié)議》
《一個(gè)基于MQTT通信協(xié)議的完整Android推送Demo》
《IBM技術(shù)經(jīng)理訪談：MQTT協(xié)議的制定歷程、發(fā)展現(xiàn)狀等》
《求教android消息推送：GCM、XMPP、MQTT三種方案的優(yōu)劣》
《移動(dòng)端實(shí)時(shí)消息推送技術(shù)淺析》
《掃盲貼：淺談iOS和Android后臺(tái)實(shí)時(shí)消息推送的原理和區(qū)別》
《絕對(duì)干貨：基于Netty實(shí)現(xiàn)海量接入的推送服務(wù)技術(shù)要點(diǎn)》
《移動(dòng)端IM實(shí)踐：谷歌消息推送服務(wù)(GCM)研究（來(lái)自微信）》
《為何微信、QQ這樣的IM工具不使用GCM服務(wù)推送消息？》
>> 更多同類文章 ……

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

作者：Jack Jiang (點(diǎn)擊作者姓名進(jìn)入Github)
出處：http://www.52im.net/space-uid-1.html
交流：歡迎加入即時(shí)通訊開發(fā)交流群 215891622
討論：http://www.52im.net/
Jack Jiang同時(shí)是【原創(chuàng)Java Swing外觀工程BeautyEye】和【輕量級(jí)移動(dòng)端即時(shí)通訊框架MobileIMSDK】的作者，可前往下載交流。
本博文 歡迎轉(zhuǎn)載，轉(zhuǎn)載請(qǐng)注明出處（也可前往 我的52im.net 找到我）。