為了更好地分類閱讀52im.net 總計1000多篇精編文章，我將在每周三推送新的一期技術文集，本次是第12 期。

[- 1 -] 應用保活終極總結(一)：Android6.0以下的雙進程守護保活實踐

[鏈接] http://www.52im.net/thread-1135-1-1.html

[摘要] 因為Android機型太多太雜，以及各廠商定制ROOM的差異，Android應用保活沒有一勞永逸和萬能的方法，本文探討的是Android應用在Android 6.0以下系統中的典型應用場景下的保活實踐（Android 6.0及以上系統的防殺和復活方法，詳見本系列文章的下兩篇《應用保活終極總結(二)：Android6.0及以上的保活實踐(進程防殺篇)》、《Android應用保活終極總結(三)：Android6.0及以上的保活實踐(被殺復活篇)》），內容僅供參考，希望給您帶來啟發。

[- 2 -] 應用保活終極總結(二)：Android6.0及以上的保活實踐(進程防殺篇)

[鏈接] http://www.52im.net/thread-1138-1-1.html

[摘要] 本文便是對最近一周的Android進程防殺、進程被殺復活的探索、學習、測試的內容總結，以備將來不時之需。因保活防殺和被殺復活涉及內容較多，我將它分成了兩篇：即進程防殺篇（本文）和進程被殺復活篇（下篇），本篇將討論如何實現進程防殺。

[- 3 -] 應用保活終極總結(三)：Android6.0及以上的保活實踐(被殺復活篇)

[鏈接] http://www.52im.net/thread-1140-1-1.html

[摘要] 本文將重點討論進程被殺后復活的可能性及實踐。

[- 4 -] Android進程保活詳解：一篇文章解決你的所有疑問

[鏈接] http://www.52im.net/thread-438-1-1.html

[摘要] 什么樣的應用需要進程保活？通常情況下，即時通訊類的應用（包括IM聊天應用、消息推送服務等）為了保證消息的全時、實時送達能力，必須要實現進程或Service的保活。而就這一看似不起眼的問題，實際處理起來，因為眾多Android手機和Android系統版本的差異，讓問題的處理充滿了不確定性。

[- 5 -] Android端消息推送總結：實現原理、心跳保活、遇到的問題等

[鏈接]http://www.52im.net/thread-341-1-1.html

[摘要] 最近研究Android推送的實現, 研究了兩天一夜, 有了一點收獲, 寫下來既為了分享, 也為了吐槽. 需要說明的是有些東西偏底層硬件和通信行業, 我對這些一竅不通, 只能說說自己的理解.

[- 6-] 為何基于TCP協議的移動端IM仍然需要心跳保活機制？

[鏈接] http://www.52im.net/thread-281-1-1.html

[摘要] 很多人認為，TCP協議自身先天就有KeepAlive機制，為何基于它的通訊鏈接，仍然需要在應用層實現額外的心跳保活？本文將從移動端IM實踐的角度告訴你，即使使用的是TCP協議，應用層的心跳保活仍舊必不可少。

[- 7 -] 一文讀懂即時通訊應用中的網絡心跳包機制：作用、原理、實現思路等

[鏈接] http://www.52im.net/thread-2697-1-1.html

[摘要] 要想真正理解即時通訊應用底層的開發，心跳機制必須掌握，而這也是本文寫作的目的，希望能帶給你啟發。

[- 8-]  微信團隊原創分享：Android版微信后臺保活實戰分享(進程保活篇)

[鏈接] http://www.52im.net/thread-210-1-1.html

[摘要] 盡量保證應用的進程不被Android系統回收。這是本文要討論的內容。

[- 9 -] 微信團隊原創分享：Android版微信后臺保活實戰分享(網絡保活篇)

[鏈接] http://www.52im.net/thread-209-1-1.html

[摘要] 如何保證消息接收實時性。這是本文要討論的內容。

[- 10-] 移動端IM實踐：實現Android版微信的智能心跳機制

[鏈接] http://www.52im.net/thread-120-1-1.html

[摘要] 設計此方案的主要目標是，在盡量不影響用戶收消息及時性的前提下，根據網絡類型自適應的找出保活信令TCP連接的盡可能大的心跳間隔，從而達到減少安卓微信因心跳引起的空中信道資源消耗，減少心跳Server的負載，以及減少部分因心跳引起的耗電。

[- 11-] 移動端IM實踐：WhatsApp、Line、微信的心跳策略分析

[鏈接] http://www.52im.net/thread-121-1-1.html

[摘要] 本文著重分析WhatsApp、Line、微信的心跳。

[- 12-] Android P正式版即將到來：后臺應用保活、消息推送的真正噩夢

[鏈接] http://www.52im.net/thread-1832-1-1.html

[摘要] Android P官方公開的開發者資料來看，此版加入或強化的多項設備電量管理新特性，使得需要后臺消息推送、應用保活的APP變的越來越困難，黑科技恐將成為歷史。

[- 13-] 全面盤點當前Android后臺保活方案的真實運行效果（截止2019年前）

[鏈接] http://www.52im.net/thread-2176-1-1.html

[摘要] 正因為Android系統版本的差異，也導致了各種保活黑科技的運行效果大相徑庭，所以本文正好借此機會，盤點一下當前主流（截止2019年前）的保活黑科技在市面上各版本Android手機上的運行效果，希望能給大家提供一些客觀的參考

[- 14-] 融云技術分享：融云安卓端IM產品的網絡鏈路保活技術實踐

[鏈接] http://www.52im.net/thread-2744-1-1.html

[摘要] 眾所周知，IM 即時通訊是一項對即時性要求非常高的技術，而保障消息即時到達的首要條件就是鏈路存活。那么在復雜的網絡環境和國內安卓手機被深度定制化的條件下，如何保障鏈路存活呢？本文詳解了融云安卓端IM產品在基于 TCP 協議實現鏈路保活方面的實踐總結。

[- 15-] 一種Android端IM智能心跳算法的設計與實現探討（含樣例代碼）

[鏈接] http://www.52im.net/thread-783-1-1.html

[摘要] 本文將與大家一起探討一種更加簡單易行和實用的心跳算法，不一定適合所有人，但希望能需要的同行帶來一些啟發。

[- 16-] 跟著源碼學IM(一)：手把手教你用Netty實現心跳機制、斷線重連機制

[鏈接] http://www.52im.net/thread-2663-1-1.html

[摘要] 說到用Netty來開發IM或推送系統，以一個生產級產品的標準來說，最基本的心跳機制、斷線重連機制肯定得有吧？好，如果你還不清楚這些，那就看看本文吧！

[- 17-] 跟著源碼學IM(五)：正確理解IM長連接、心跳及重連機制，并動手實現

[鏈接] http://www.52im.net/thread-2799-1-1.html

[摘要] 本文正好借著在CIM系統中有這樣兩個需求（CIM是本文作者從零開發的一個學習性質的IM系統，詳見《拿起鍵盤就是干：跟我一起徒手開發一套分布式IM系統》），正好來聊一聊我是如何理解IM長連接的心跳及重連機制，以及又是怎么踩坑已及填坑的。

[- 18-] 2020年了，Android后臺保活還有戲嗎？看我如何優雅的實現

[鏈接] http://www.52im.net/thread-2881-1-1.html

[摘要] 總之，Android應用的后臺保活在某些場景下，還是有持續的需求。除了之前那些耳熟能詳的保活黑科技以外，在Android 9.0（甚至Android 10）時代，我們還有哪些保活方法可以用？那么，請跟著本文作者的思路，看看更優雅的后臺保活實現方法吧。

[- 19-] 史上最強Android保活思路：深入剖析騰訊TIM的進程永生技術

[鏈接] http://www.52im.net/thread-2893-1-1.html

[摘要] 本文將從Andriod系統層面為你深入剖析騰訊TIM這款IM應用的超強保活能力，希望能給你帶來更多Android方面的靈感。

[- 20-] Android進程永生技術終極揭密：進程被殺底層原理、APP應對被殺技巧

[鏈接] http://www.52im.net/thread-2921-1-1.html

[摘要] 本文的技術原理講解透徹、系統源碼分享到位、樣例代碼也很有參考意義，希望能對有同樣興趣愛好的Android開發者、IM開發者、推送系統開發者等，帶來對于Android進程保活技術的深入理解。

[- 21-] Android保活從入門到放棄：乖乖引導用戶加白名單吧(附7大機型加白示例

[鏈接] http://www.52im.net/thread-3033-1-1.html

[摘要] 本文將以某款線上的IM產品為例，介紹它是如何引導用戶在多款主流機型上加白名單的，并分享了該款IM中已制作完成的多達7款主流Andriod機型的詳細加白FAQ頁面資源（含完整HTML+圖片），方便您進行參考、學習和研究，希望能為你的應用開發帶來幫助。

[- 22-] 阿里IM技術分享(五)：閑魚億級IM消息系統的及時性優化實踐

[鏈接] http://www.52im.net/thread-3726-1-1.html

[摘要] 本文將根據閑魚IM消息系統在消息及時性方面的優化實踐，詳細分析了IM在線通道面臨的各種技術問題，并通過相應的技術手段來優化從而保證用戶消息的及時到達。

[- 23-] 萬字長文：手把手教你實現一套高效的IM長連接自適應心跳保活機制

[鏈接] http://www.52im.net/thread-3908-1-1.html

[摘要] 我將通過本篇文章，手把手教大家實現一套可自適應的心跳保活機制，從而能高效穩定地維持諸如IM聊天這類需求的長連接。

??52im社區本周新文：《即時通訊框架MobileIMSDK的微信小程序端開發者手冊》，歡迎閱讀！??

我是Jack Jiang，我為自已帶鹽！https://github.com/JackJiang2011/MobileIMSDK/

一、基本介紹

MobileIMSDK - 微信小程序端是一套基于微信原生 WebSocket 的即時通訊庫：

• 1）超輕量級、無任何第 3 方庫依賴（開箱即用）；
• 2）純 JS 編寫、ES6 語法、高度提煉，簡單易用；
• 3）基于微信原生 WebSocket API，簡潔優雅；
• 4）支持運行于任何支持微信小程序的手機端；
• 5）能與 MobileIMSDK 的各種客戶端完美互通；
• 6）可應用于微信小程序中的消息推送、客服聊天、企業 OA、IM 等場景。

二、與 MobileIMSDK 的關系

MobileIMSDK - 微信小程序端是基于微信原生 WebSocket 協議的 MobileIMSDK 配套客戶端庫。

MobileIMSDK 是一套專為移動端開發的開源原創 IM 通信層框架：

• 歷經 8 年、久經考驗；
• 超輕量級、高度提煉，lib 包 50KB 以內；
• 精心封裝，一套 API 同時支持 UDP、TCP、WebSocket 三種協議（可能是全網唯一開源的）；
• 客戶端支持 iOS、Android、標準 Java、H5、小程序、Uniapp(開發中..)；
• 服務端基于 Netty，性能卓越、易于擴展；??
• 可與姊妹工程 MobileIMSDK-Web 無縫互通實現網頁端聊天或推送等；??
• 可應用于跨設備、跨網絡的聊天 APP、企業 OA、消息推送等各種場景。

以下是 MobileIMSDK 的最新通信架構圖：

MobileIMSDK 的客戶端庫一直在持續開發和升級中，目前 基于 Uniapp 的 MobileIMSDK 客戶端正在開發中 。

三、設計目標

直接使用原生的微信小程序 WebSocket 有以下問題和劣勢：

• 1）功能有限：沒有心跳保活、斷線重連、消息送達保證（重傳和去重）等即時通訊關鍵算法和邏輯；
• 2）API 簡陋：在如此有限的原生 API 下，能邏輯清晰地實現并組合心跳保活、斷線重連、消息送達保證等算法，需要相當高的技術掌控力；
• 3）邏輯耦合：經驗欠缺的開發人員，會將 WebSocket 通信與前端 UI 界面代碼混在一起，使得 UI 界面的重構、維護、改版都非常困難。

針對以上問題，而 MobileIMSDK - 微信小程序端庫將讓開發者專注于 UI 應用層的開發，網絡通信層的專業代碼交由 SDK 開發人員，從而解偶 UI 前端和通信層的邏輯耦合性，大大降低技術復雜性。

MobileIMSDK - 微信小程序端庫的設計目標是為您的開發帶來以下便利：

• 1）界面與通信解偶：UI 界面與網絡通信代碼解耦，UI 界面的重構、維護、改版都非常容易和優雅；
• 2）輕量級和兼容性：受益于堅持原生微信小程序 WebSocket API，簡潔輕量，無需任何額外依賴；
• 3）核心內聚和收斂：得益于長期的提煉和經驗積累，SDK 核心層高度封裝，開發者無需理解復雜算法即可簡單上手。
• 4）純 JS 輕量級實現：SDK 為純 JS 編寫、ES6 語法，無重量級框架和庫依賴，可干凈利落地對接各種既有系統。

四、技術亮點

• 輕量易使用：超輕量級 —— 純 JS 編寫且無任何第 3 方庫依賴，高度提煉 —— 簡單易用；
• 代碼現代感：盡可能優先使用 ES6 語法，摒棄舊式 JS 語法的年代感；
• 兼容性很好：基于微信原生 WebSocket API，可很好地運行于支持微信小程序的手機端；
• 斷網恢復能力：擁有網絡狀況自動檢測、斷網自動治愈的能力；
• 送達保證機制：完善的 QoS 消息送達保證機制（多重保障），不漏過每一條消息；
• 通信協議封裝：實現了一個對上層透明的即時通訊通信協議模型；
• 身份認證機制：實現了簡單合理的身份認證機制；
• 完善的 log 信息：在開發調試階段，確保每一個算法關鍵步驟都有日志輸出，讓您的運行調試更為便利；
• 界面代碼解耦：實現了 UI 界面代碼與 SDK 網絡通信代碼解偶，防止界面代碼跟 IM 核心代碼混在一起，不利于持續升級、重用和維護；
• 聊天協議兼容：實現了與 MobileIMSDK 各種客戶端完全兼容的協議模型。

五、Demo 運行截圖

六、詳細介紹

① MobileIMSDK - 微信小程序端的詳細介紹：點此查看 ??

② MobileIMSDK - 微信小程序端的開發手冊：點此查看 ??

③ MobileIMSDK 開源框架的詳細介紹：https://gitee.com/jackjiang/MobileIMSDK  ??

為了更好地分類閱讀52im.net 總計1000多篇精編文章，我將在每周三推送新的一期技術文集，本次是第10 期。

[-1-] 簡述傳輸層協議TCP和UDP的區別

[鏈接] http://www.52im.net/thread-580-1-1.html

[摘要] 本文將從應用層的角度，簡要的對比TCP和UDP協議的區別，或許能給你些許啟發。

[-2-] 為什么QQ用的是UDP協議而不是TCP協議？

[鏈接] http://www.52im.net/thread-279-1-1.html

[摘要] QQ既有UDP也有TCP！不管UDP還是TCP，最終登陸成功之后，QQ都會有一個TCP連接來保持在線狀態。這個TCP連接的遠程端口一般是80，采用UDP方式登陸的時候，端口是8000。

[-3-]移動端即時通訊協議選擇：UDP還是TCP？

[鏈接] http://www.52im.net/thread-33-1-1.html

[摘要]對于有選擇困難證的人來說，基于以上因素，加上UDP和TCP協議的本質差異，這樣的選擇確實很糾結。本文將從作者的實踐總結，給出自已的觀點，如有異議還請理性回復，不為找噴，僅供參考。

[-4-]快速理解TCP和UDP的差異

[鏈接] http://www.52im.net/thread-1160-1-1.html

[摘要] 本文延續《網絡編程懶人入門》系列文章的風格，通過快速對比分析 TCP 和 UDP 的區別，來幫助即時通訊初學者快速了解這些基礎的知識點，從而在IM、消息推送等網絡通信應用場景中能準確地選擇合適的傳輸層協議。

[-5-] 快速理解為什么說UDP有時比TCP更有優勢

[鏈接] http://www.52im.net/thread-1277-1-1.html

[摘要] 隨著網絡技術飛速發展，網速已不再是傳輸的瓶頸，UDP協議以其簡單、傳輸快的優勢，在越來越多場景下取代了TCP，如網頁瀏覽、流媒體、實時游戲、物聯網。本文作為《網絡編程懶人入門》系列文章的第5篇，將為您快速梳理UDP協議在某些場景下對比TCP協議所具有的優勢。

[-6-] UDP的連接性和負載均衡

[鏈接] http://www.52im.net/thread-1018-1-1.html

[摘要]本文將從實踐出發，討論UDP在實際應用中的連接性和負載均衡問題。

[-7-] 深入地理解UDP協議并用好它

[鏈接] http://www.52im.net/thread-1024-1-1.html

[摘要] 本文接系列文章的上篇《不為人知的網絡編程(五)：UDP的連接性和負載均衡》，將從實踐出發，討論如何深入地理解UDP協議并在實踐中用好它。

[-8-] 如何讓不可靠的UDP變的可靠？

[鏈接] http://www.52im.net/thread-1293-1-1.html

[摘要] 涉及到實時傳輸我們都會先考慮 RUDP，RUDP 應用在我們APP核心傳輸體系的各個方面，但不同的系統場景我們設計了不同的 RUDP 方式，所以基于那些激烈的討論和我們使用的經驗，我決定扒一扒 RUDP，來給大家分享如何讓UDP變的可靠的實踐經驗。

[-9-] 從底層入手，深度分析TCP連接耗時的秘密

[鏈接] http://www.52im.net/thread-3265-1-1.html

[摘要] 經過日常工作的思考之后，我更想弄明白的是，TCP的開銷到底有多大，能否進行量化。一條TCP連接的建立需要耗時延遲多少，是多少毫秒，還是多少微秒？能不能有一個哪怕是粗略的量化估計？當然影響TCP耗時的因素有很多，比如網絡丟包等等。我今天只分享我在工作實踐中遇到的比較高發的各種情況。

[-10-]徹底搞懂TCP協議層的KeepAlive保活機制

[鏈接] http://www.52im.net/thread-3506-1-1.html

[摘要] 限于篇幅，該篇并沒有深入探討TCP協議本身的KeepAlive機制，所以這次借本文想把TCP協議的KeepAlive保活機制給詳細的整理出來，以便大家能深入其中一窺究竟。

[-11-] 拔掉網線再插上，TCP連接還在嗎？一文即懂

[鏈接] http://www.52im.net/thread-3846-1-1.html

[摘要] 本篇文章，我們就從系統層面深入地探討一個有趣的TCP技術問題：拔掉網線后，再插上，原本的這條TCP連接還在嗎？或者說它還“好”嗎？

[-12-] 單臺服務器并發TCP連接數到底可以有多少

[鏈接] http://www.52im.net/thread-561-1-1.html

[摘要] 到底一臺服務器能夠支持多少TCP并發連接呢？這就是本文要討論的問題。

??52im社區本周新文：《得物從0到1自研客服IM系統的技術實踐之路》，歡迎閱讀！??

我是Jack Jiang，我為自已帶鹽！https://github.com/JackJiang2011/MobileIMSDK/

1、項目簡介

MobileIMSDK是一套專為移動端開發的原創IM通信層框架：

• 1）歷經8年、久經考驗；
• 2）超輕量級、高度提煉，lib包50KB以內；
• 3）精心封裝，一套API同時支持UDP、TCP、WebSocket三種協議（可能是全網唯一開源的）；
• 4）客戶端支持iOS、Android、標準Java、H5(暫未開源)、小程序(開發中..)、Uniap(開發中..)；
• 5）服務端基于Netty，性能卓越、易于擴展 new；
• 6）可與姊妹工程 MobileIMSDK-Web 無縫互通實現網頁端聊天或推送等；
• 7）可應用于跨設備、跨網絡的聊天APP、企業OA、消息推送等各種場景。

2、代碼托管同步更新

GitHub.com：

• 代碼托管：https://github.com/JackJiang2011/MobileIMSDK
• 技術社區： 點擊查看更多資料

碼云gitee：

• 代碼托管： http://git.oschina.net/jackjiang/MobileIMSDK
• 技術社區： 點擊查看更多資料

3、設計目標

讓開發者專注于應用邏輯的開發，底層復雜的即時通訊算法交由SDK開發人員，從而解偶即時通訊應用開發的復雜性。

4、框架組成

整套MobileIMSDK框架由以下6部分組成：

• 1）Android客戶端SDK：用于開發Android版即時通訊客戶端，支持Android 2.3及以上版本，查看API文檔；
• 2）iOS客戶端SDK：用于開發iOS版即時通訊客戶端，支持iOS 8.0及以上版本，查看API文檔；
• 3）Java客戶端SDK：用于開發跨平臺的PC端即時通訊客戶端，支持標準Java 1.6及以上版本，查看API文檔；
• 4）H5客戶端SDK：暫無開源版，查看精編注釋版；
• 5）小程序端SDK：持續開發中，敬請關注；
• 6）服務端SDK：用于開發即時通訊服務端，支持Java 1.7及以上版本，查看API文檔；

整套MobileIMSDK框架的架構組成：

5、技術特征

• 久經考驗：歷經8年，從Andriod 2.3、iOS 5.0 時代持續升級至今（絕不爛尾）；
• 超輕量級：高度提煉，lib包50KB以內；
• 多種協議：可能是全網唯一開源可同時支持UDP、TCP、WebSocket三種協議的同類框架；
• 多種網絡：精心優化的TCP、UDP、WebSocket協議實現，可應用于衛星網、移動網、嵌入式物聯網等場景；
• 高效費比：獨有的UDP協議實現，無連接特性，同等條件下可實現更高的網絡負載和吞吐能力；
• 消息走向：支持即時通訊技術中消息的所有可能走向，共3種（即C2C、C2S、S2C）；
• 粘包半包：優雅解決各端的TCP經典粘包和半包問題，底層封裝，應用層完全無感知；
• QoS機制：完善的消息送達保證機制（多重保障），不漏過每一條消息；
• 健壯可靠：實踐表明，非常適于在高延遲、跨洲際、不同網絡制式環境中穩定、可靠地運行；
• 斷網恢復：擁有網絡狀況自動檢測、斷網自動治愈的能力；
• 原創算法：核心算法和實現均為原創，保證了持續改進和提升的空間；
• 多種模式：預設多種實時靈敏度模式，可根據不同場景控制即時性、流量和客戶端電量消耗；
• 數據壓縮：自有協議實現，未來可自主定制數據壓縮，靈活控制客戶端的流量、服務端網絡吞吐；
• 高度封裝：高度封裝的API接口，保證了調用的簡易性，也使得可應用于更多的應用場景；
• Web支持：可與姊妹工程 MobileIMSDK-Web 無縫互通實現網頁端聊天或推送等；
• 擴展性好：服務端基于Netty，繼承了Netty的優秀高可擴展性；
• 性能優異：服務端繼承了Netty高性能、高吞吐特性，適用于高性能服務端場景。

MobileIMSDK 所支持的全部3種即時通訊消息走向分別是：

(1) Client to Client (C2C)：即由某客戶端主動發起，接收者是另一客端；

(2) Client to Server (C2S)：即由某客戶端主動發起，接收者是服務端；

(3) Server to Client (S2C)：即由服務端主動發起，接收者是某客戶端。

6、性能測試

壓力測試表明，MobileIMSDK用于推送場景時，理論單機負載可接近千萬級。用于聊天應用時，單機負載也可達數十萬。

當然，每款應用都有各自的特點和差異，請視具體場景具體評估之，測試數據僅供參考。

性能測試報告：點此查看。

7、演示程序

• 1）Android客戶端 Demo：點此安裝和使用；
• 2）iOS客戶端 Demo：點此安裝和使用；
• 3）Java客戶端 Demo：點此安裝和使用；
• 4）H5客戶端 Demo：點此查看介紹；
• 5）服務端 Demo：點此安裝和使用 new。

8、應用案例

RainbowChat是一款基于MobileIMSDK的產品級聊天APP，更多詳情：點擊下載體驗 或 查看運行截圖。

① 基于MobileIMSDK的產品級聊天APP：

▶ 詳細介紹、下載體驗 或 查看運行截圖。

② MobileIMSDK在高網絡延遲下的案例：

▶ 某款基于MobileIMSDK的商業商品，曾運營于跨洲際的復雜網絡環境下，端到端通信延遲在洲際網絡繁忙時可高達600ms以上（與服務端的單向延遲約為300ms左右，而通常大家訪問國內主流門戶的延遲約為20~50ms），某段時期的非敏感運營數據 點此查看。

9、打包下載（all in one）

• ① 最新發布版（國外地址）：Github打包下載
• ② 最新發布版（國內地址）：碼云gitee打包下載（訪問速度快！）

說明：最新發布版打包內容中，已包含完整的demo源碼、sdk源碼、api文檔、編譯后的分發包等。

10、典型應用場景

場景1：聊天APP

• 應用說明：可用于開發類似于微信、QQ等聊天工具。
• 消息走向：需使用C2C、C2S、S2C全部類型。

特別說明：MobileIMSDK并未定義聊天應用的應用層邏輯和協議，開發者可自行定義并實現之。

場景2：消息推送

• 應用說明：可用于需要向客戶端實時推送信息的各種類型APP。
• 消息走向：僅需使用S2C 1種消息走向，屬MobileIMSDK的最簡單應用場景。

場景3：企業OA

• 應用說明：可用于實現企業OA的指令、公文、申請等各種消息實時推送，極大提升用戶體驗，并可延伸至移動設備。
• 消息走向：僅需使用S2C 1種消息走向，屬MobileIMSDK的最簡單應用場景。

場景4：企業OA的增強型

• 應用說明：可用于實現企業OA中各種系統級、用戶級消息的實時互動，充分利用即時通訊技術提升傳統OA的價值。
• 消息走向：可使用C2C、C2S、S2C全部類型，這與聊天APP在很多方面已無差別，但企業OA有自已的用戶關系管理模型和邏輯，較之全功能聊天APP要簡單的多。

11、開發指南

• 1）Android客戶端開發指南：點此查看；
• 2）iOS客戶端開發指南：點此查看；
• 3）Java客戶端開發指南：點此查看；
• 4）H5客戶端開發指南：點此查看；
• 5）Server端開發指南：點此查看。

12、關注作者

博客地址：點擊入進、Github主頁：點擊進入

附錄1：Demo截圖

1）Android和iOS運行效果

>> 安裝和使用：進入Android版Demo幫助頁、進入iOS版Demo幫助頁。

2）Windows 運行效果

>> 安裝和使用：進入Java版Demo幫助頁。

3）Mac OS X 運行效果

>> 安裝和使用：進入Java版Demo幫助頁。

>> 關于RainbowChat的更多資料請見：RainbowChat前端APP功能截圖網頁 。

附錄3：基于MobileIMSDK-Web的網頁端IM系統【案例】

下圖為RainbowChat-Web的主界面（更多截圖點此進入、更多演示視頻點此進入）：