一、基本介紹

MobileIMSDK是一套全平臺原創開源IM通信層框架：

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

二、源碼倉庫同步更新

GitHub.com：

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

碼云gitee：

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

三、設計目標

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

四、框架組成

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

1. Android客戶端SDK：用于開發Android版即時通訊客戶端，支持Android 4.0及以上版本，查看API文檔；
2. iOS客戶端SDK：用于開發iOS版即時通訊客戶端，支持iOS 12.0及以上版本，查看API文檔；
3. Java客戶端SDK：用于開發跨平臺的PC端即時通訊客戶端，支持標準Java 1.6及以上版本，查看API文檔；
4. H5客戶端SDK：查看精編注釋版；
5. 微信小程序端SDK：查看精編注釋版；
6. Uniapp端SDK：查看精編注釋版；
7. 鴻蒙Next端SDK：SDK暫無開源版（查看精編注釋版），Demo完整工程源碼；
8. 服務端SDK：用于開發即時通訊服務端，支持Java 1.7及以上版本，查看API文檔；

整套MobileIMSDK框架的架構組成：

MobileIMSDK一直在持續開發和升級中，鴻蒙Next客戶端是MobileIMSDK工程的最新成果。

五、技術特征

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

六、演示程序

1. Android客戶端 Demo：點此安裝和使用；
2. iOS客戶端 Demo：點此安裝和使用；
3. Java客戶端 Demo：點此安裝和使用；
4. H5客戶端 Demo：點此查看介紹；
5. 微信小程序端 Demo：點此查看介紹；
6. Uniapp端 Demo：點此查看介紹；
7. 鴻蒙Next端 Demo：點此查看介紹 new；
8. 服務端 Demo：點此安裝和使用。

七、應用案例

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

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

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

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

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

八、打包下載（all in one）

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

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

九、典型應用場景

場景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要簡單的多。

十、開發指南

1. Android客戶端開發指南：點此查看；
2. iOS客戶端開發指南：點此查看；
3. Java客戶端開發指南：點此查看；
4. H5客戶端開發指南：點此查看；
5. 微信小程序端開發指南：點此查看；
6. Uniapp端開發指南：點此查看；
7. 鴻蒙Next端開發指南：點此查看；
8. Server端開發指南：點此查看。

附錄1：Demo截圖

1、在鴻蒙Next端運行效果：

>> 編譯和運行：查看鴻蒙Next端Demo完整源碼。

2、Android端、iOS端運行效果

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

3、H5端運行效果

4、微信小程序端運行效果

5、Uniapp端運行效果

6、Windows 運行效果

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

7、Mac OS X 運行效果

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

8、MobileIMSDK-Web版客戶端Demo運行效果：

8.1）MobileIMSDK-Web在手機端瀏覽器運行效果：（如何獲取MobileIMSDK-Web版：點此進入）

8.2）MobileIMSDK-Web在PC端瀏覽器運行效果：（如何獲取MobileIMSDK-Web版：點此進入）

附錄2：基于MobileIMSDK的全功能IM【案例】

>> 關于RainbowChat的更多資料請見：RainbowChat前端APP功能截圖網頁 （* 推薦 - 真機實拍視頻：Andriod端、iOS端）。

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

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

下圖為RainbowChat-Web的主界面[聊天窗全屏時] （更多截圖點此進入、更多演示視頻點此進入）：

下圖為RainbowChat-Web的主界面[獨立UI效果] （更多截圖點此進入、更多演示視頻點此進入）：

（以上內容同步發布于：http://www.52im.net/thread-52-1-1.html ）

本文由轉轉技術團隊趙衛兵分享，原題“鴻蒙新篇章：轉轉 APP 的 HarmonyOS Next 開發之旅”，下文進行了排版優化和內容修訂。

1、引言

2023 年在華為開發者大會（HDC.Together）上，除了面向消費者的 HarmonyOS 4 之外，華為還推出了面向開發者的 HarmonyOS Next 開發者預覽。

而在去年的 6 月份華為開發者大會上，對外開啟了 HarmonyOS Next Beta 版，并在當年內正式推出面向消費者的商用版本。

HarmonyOS Next，是鴻蒙生態的一個重要拐點。去年的時候，轉轉和華為已經達成合作，作為鴻蒙先鋒的一員，加入到鴻蒙應用的開發之中來。

客戶端從 2023 年 11 月份開始，人力開始逐漸的往這個方向投入，于 2024 年 2 月份正式開始進入業務開發，在 6 月 4 號，對外正式發布了基于 HarmonyOS Next 系統的轉轉 App 首個版本。

從早期的學習到最終第一個版本上線，我們經歷了以下幾個階段：

• 1）前期的熟悉和學習過程；
• 2）鴻蒙客戶端基建開發過程；
• 3）首個版本需求范圍確定和排期；
• 4）業務開發；
• 5）測試；
• 6）bug 修復/性能調優；
• 7）上線。

本文將要分享的是轉轉APP在開發全新鴻蒙NEXT端所遇到的一些問題，對比了鴻蒙開發和 Android、iOS 的不同，總結了這次開發過程中的一些經驗等等。希望能帶給你啟發。

2、關于作者

趙衛兵：目前負責轉轉集團 iOS 和鴻蒙系統 App 基礎架構和相關基礎建設。崇尚開源和分享精神，Sharing is everything ~

轉轉團隊分享的其它幾篇技術文章有興趣也可讀一讀：

1. 轉轉平臺IM系統架構設計與實踐(一)：整體架構設計
2. 轉轉平臺IM系統架構設計與實踐(二)：詳細設計與實現
3. Web端IM聊天消息該不該用瀏覽器本地存儲？一文即懂
4. 手把手教你使用網絡編程抓包神器Wireshark
5. 淺談網頁端IM技術及相關測試方法實踐（包括WebSocket性能測試）

3、初識鴻蒙NEXT

3.1 分布式技術

HarmonyOS Next 具備強大的分布式技術，能夠實現跨設備協同工作。用戶可以無縫地在不同的設備間切換和使用應用，無需感知設備的差異。HDC 大會中如 WPS Office、高德等 APP，使用了應用接續特性，在不同設備中進行流轉，令人印象深刻。這點在 iOS 和 Android 中并不完全具備。

3.2 高性能低時延

HarmonyOS Next采用輕量級的微內核設計。

iOS 使用的內核基于 XNU（X is Not Unix）內核，XNU 是一個混合內核，結合了微內核（Mach 內核）的內存管理、任務調度、進程間通信等特性和宏內核（BSD 內核）的文件系統、網絡堆棧、用戶進程管理等特性。

Android 內核基于修改過的 Linux 宏內核，增加了 Binder IPC、電源管理、安全性等模塊和機制，以更好的支持移動設備。

鴻蒙的微內核設計，官方稱相比宏內核，具備更高的性能和更低的時延，從而在多任務處理、設備響應和處理能力上具有明顯優勢。

3.3 自適應UI框架

通過 ArkUI和ArkTS，HarmonyOS Next能夠適應各種尺寸和形狀的屏幕設備，提供一致友好的用戶體驗。這個特性在跨設備協同時尤其重要。

3.4 多終端、多OS支持

HarmonyOS Next 不僅僅是一個手機操作系統，還能運行在平板、智能穿戴設備、智能家居設備等多種終端上，統一生態系統。對比蘋果的iOS，MacOS，TVOS，WatchOS，確實有些不同。但對于應用開發者而言，其實就是API的能力集合問題，這一點，鴻蒙使用 SysCap 系統能力集合達到了殊途同歸的效果。

3.5 更優秀的安全性

在應用安全層面，目前在應用的生態中有以下一些問題：

• 1）誘導用戶下載安裝惡意應用；
• 2）竊取用戶數據；
• 3）強制推送廣告；
• 4）利用漏洞攻擊其他應用程序；
• 5）盜版軟件。

這方面，由于Android 的開放性以及側載安裝的支持，問題表現的尤為明顯，而 iOS 是一個可以學習的老師。

針對上面的問題，HarmonyOS Next 又是如何應對的呢？

• 1）做好應用質量的監管，控制應用分發渠道，避免惡意應用分發到用戶設備上；
• 2）提供安全的數據授權機制，避免用戶過度授權造成安全威脅；
• 3）給應用程序開放的系統功能做到不被惡意利用；
• 4）幫助應用程序最小程度的受到漏洞影響；
• 5）為應用程序提供有效的核心數字產權保護手段，避免出現盜版軟件問題。

具體可以看下圖：

（圖片來自《鴻蒙生態應用安全技術白皮書 V1.0》）

4、和Android、iOS的開發有何不同？

鴻蒙開發上，和 Android、iOS 還是有不少相似和不同的地方，我挑選感受比較深刻的幾個點說下。

4.1 開發語言和工具鏈

鴻蒙開發使用的是ArkTS 語言，ArkTS基于 TypeScript 做了一些擴展，繼承了 TypeScript 的所有特性，是 TypeScript 的超集。

下面是官方的一些介紹：

ArkTS的一大特性是它專注于低運行時開銷。ArkTS對TypeScript的動態類型特性施加了更嚴格的限制，以減少運行時開銷，提高執行效率。通過取消動態類型特性，ArkTS代碼能更有效地被運行前編譯和優化，從而實現更快的應用啟動和更低的功耗。

與JavaScript的互通性是ArkTS語言設計中的關鍵考慮因素。鑒于許多移動應用開發者希望重用其TypeScript和JavaScript代碼和庫，ArkTS提供了與JavaScript的無縫互通，使開發者可以很容易地將JavaScript代碼集成到他們的應用中。這意味著開發者可以利用現有的代碼和庫進行ArkTS開發。

在開發工具上：使用的 IDE 是 DevEco Studio，基于 IntelliJ IDEA Community 開源版本打造，為開發者提供工程模板創建、開發、編譯、調試、發布等功能。華為在這個 IDE 上針對鴻蒙開發易用性上做了大量的工作，包含但不限于編譯器，代碼實時預覽、ArkUI Inspector、Profile 性能分析工具等等。

在包管理上：有點類似前端的 npm 包管理機制，不過在這塊，是叫 ohpm，整體上非常相似，但是細節上有一些不同，譬如 package.json 的文件命名、lock 文件的內容信息、獨立的開源中心倉等等。倉庫這塊也提供了私倉部署的方式，采用套件工具中的 ohpm-repo就可以部署到企業內部服務器上。

在調試上：和 Android 的 ADB 類似，鴻蒙這塊提供了一個 hdc 的工具，提供了類似查詢設備列表、網絡、文件、應用安裝卸載、shell、日志獲取等常用功能。

4.2 開發體驗

鴻蒙開發是用 ArkUI，類似 Flutter，SwiftUI 這樣的聲明式 UI，ArkUI 組件的命名和狀態管理和 SwiftUI 比較類似，上手比較容易。

4.3 開發資料和交流

Android 從 2008 年谷歌布，iOS 從 2007 年蘋果發布，距離到現在已經有了 16～17 年之久，在這期間，互聯網上積累了無數的開發資料和經驗分享，也有著大量的開源項目和社區。

而有關 HarmonyOS Next 方面的資料，目前更多的是官方開發指南和開源范例（集中在 gitee 上）。

社區方面，主要是華為開發者論壇，受限于開發者版本的迅速迭代，一些帖子討論的內容已經過時且不再適用。

而在博客、github 開源上，目前看到的其實并不多，更多的分享還是比較基礎，深度有價值的還不多。

目前在這個階段，更多的是企業和華為合作的情況下，內部使用 Issue 工單系統進行溝通交流。交流主要圍繞著需求、Bug 反饋、指南疑問來展開。

譬如：

• 1）指南資料中提供的能力，不滿足訴求，交流是否有更好的解決方案；
• 2）API 、IDE、工具鏈表現不符合預期，反饋 bug；
• 3）系統能力類比 Android、iOS 缺失的特性，交流是否有替代的解決方案。

截止到本篇文章寫的時候，轉轉華為工單交流的總數已達到 270+個。反饋的 bug 和缺失的能力，在后面的開發者預覽版本中都被修復或支持了。

印象比較深刻的一件事是：開發和測試期間我們發現了停留在登錄頁面不動，過個10 分鐘左右，系統就會卡死重啟，我們一度以為是 App 哪里有 bug。我們通過 hdc hilog 抓取系統輸出的日志，發現大約過了 10 分鐘左右，log 就會死循環打印，很明顯系統底層發生了一些異常。已經晚上快 1 點了，我們興奮的找到和我們對接這個問題的華為工程師張老師，將視頻和日志發送給他，張老師按照復現的路徑，也成功復現出來，并且抓取到日志。后面的幾天，經過華為伙伴的努力，終于定位到問題所在，是文件句柄 FD 存在泄露的情況，并在下一個開發者版本中推送修復了。

為華為工程師的敬業和效率豎一個大拇指，華為之所以強大，從這件事的跟進和解決效率上，就能理解到為什么。

5、踩坑后總結的幾個經驗

5.1 類比學習

投入鴻蒙開發的客戶端同學，有來自 Android 開發的，也有來自 iOS 開發的，或多或少對另外一端的系統了解的不是很全面。

在學習的過程中，我們發現鴻蒙的一些特性和 API 設計，有些和 iOS 比較像，而有些和 Android 有些像。我們內部經常討論交流和理解 HarmonyOS Next 的應用層設計問題。在方案選擇上，HarmonyOS Next 中都有借鑒和取舍。

這個階段：我們需要重點理解鴻蒙特有的一些設計概念和思想。譬如 Stage 模型，Stage模型是從 API 9 開始新增的模型，是目前主推且會長期演進的鴻蒙應用模型。在該模型中，由于提供了 AbilityStage、WindowStage 等類作為應用組件和 Window 窗口的“舞臺”，這種方式在 Android、iOS 上是不是有類似的概念呢？

如果我們如下類比 Android、iOS。

AbilityStage 和 WindowStage：

• 1）在 iOS 中，與 UIViewController 和 UIWindow 類似。UIViewController 管理視圖層次和界面行為，而 UIWindow 是應用程序的窗口，可以顯示內容；
• 2）在 Android 中，可以類比于 Activity 和 Window。Activity 是應用的單個屏幕，負責界面的創建和管理，而 Window 是 Activity 的頂層視圖容器。

UIAbility 和 ExtensionAbility：

• 1）UIAbility 可以和 iOS 的 UIViewController 以及 Android 的 Activity 相對應，因為它們都是用于管理和顯示用戶界面的基本單元。
• 2）ExtensionAbility 可以類比于 iOS 的 App Extension 和 Android 的 Service。App Extension 提供了將功能擴展到系統范圍內的能力，而 Service 在 Android 中則是運行在后臺的組件，執行長時間運行的操作。

雖然細節有所不同，但大方向上這樣對比和類比，會幫助我們快速理解鴻蒙相關開發概念。

5.2 項目管理和風險方案應對

首個版本的開發，幾乎涉及到了公司所有的業務部門，我們通過啟動會拉齊背景信息，前期讓大家梳理到新增一個鴻蒙終端對業務的影響范圍，以及解決方案。

1）PlanB 方案：

一些三方 SDK 如微信、支付寶等在前期都是沒有的，我們首個版本需要做好 PlanB 方案。涉及到的包括登錄、支付、分享等業務，都需要針對這些進行調整。

2）有限的測試機：

因為業務部門參與進來的很多，但工程樣機十分有限。服務端和前端同學代碼調整完畢后如何測試呢？這個是我們不得不考慮的一件事情。

新增一個鴻蒙終端，服務端調整后端代碼，在測試和沙箱測試時，除了回歸不要影響 Android 和 iOS 之外，還要能保證針對鴻蒙的兼容調整是有效的。鑒于鴻蒙測試機器十分有限，我們給 Server 同學提供了 Android 測試包，將 Android 測試包的終端 mock 成鴻蒙終端來供服務端測試接口，這樣子測試下來十分高效。

針對前端同學：不能再向剛才那樣做了，畢竟是用 Android 的 WebView。即便我們 WebView 的 UserAgent mock 成 Android 系統，使得通信和交互仍然走類似 Android 的策略，而這樣并不能代表真實的鴻蒙 WebView 環境，因為在 Next 系統中整個 Native 和 Webview 的通信 Bridge 是全新的一套方案，且鴻蒙的 API 實現接口也都需要走鴻蒙側來測試。針對這個情況，我們非常謹慎小心的將各個業務部門的參與進來的時間錯開，盡力保證在有限測試機的情況下，每個業務輪轉參與進來的時候都是有機器的。

5.3 多和華為伙伴進行溝通

這部分的經驗，具有一定的時效性。后期商用版本發布之后，可能這樣的溝通渠道、頻次很難再有了。

為什么要多和華為伙伴時刻保持密切的溝通？有幾個印象深刻的例子。

1）第一個例子：路由

鴻蒙關于頁面跳轉提供了兩套解決方案，一套是頁面路由 router，一套是組件導航 Navigation。前期我們在基建開發期間，采用的頁面路由 router 方案，@zz/router 組件代碼已經開發完畢了，但是到了開發 WebView 的 Hybrid 接口時，才意識到一個嚴重的問題，就是 router 提供的能力，并不能滿足我們復雜的頁面棧管理，譬如在頁面棧中多個 WebView，我們需要關閉指定的 WebView 頁面，router 提供的 API 能力是無法做到的。和華為溝通后才知道，官方是推薦 Navigation 來實現，且未來 router 方案不再演進。我們提出的復雜頁面棧管理的能力，彼時 Navigation 支持的還不完整，但是伙伴告訴我們，他們會在 Navigation 上滿足我們的需求。關閉頁面棧中指定 index 或者 name 的頁面，相信其他開發者也都會遇到，應該是一個普遍的需求。

基于這種情況，我們不得不迅速調整我們的路由組件，基于 Navigation 重新設計了一套路由方案，還好項目業務還沒有開始大量開發，要改動的地方也不是很多，如果溝通再晚點，恐怕調整起來代價會相對更高點。此時的溝通，讓我們少走了彎路，避免在 router 上走投無路死磕方案。

2）第二個例子：企業分發

企業分發通常用于企業內部測試、企業內部 App 等。Dev 證書和 iOS 的 Dev 證書類似，Provisioning Profile（p7b 文件）會有 100 臺設備的限制。考慮到將來，轉轉也想依賴企業分發能力，可以在測試中采用企業簽名打包來進行測試。雖說在當前階段不是硬性和必要的，但是我們還有一個轉轉質檢 App，這個 App 我們不能通過 AGC 后臺上架華為市場，因為在質檢中心，如果不走內部分發安裝，那么我們將會面臨著外網下載，會給質檢中心的帶寬帶來很大的負載以及成本。

我們密切關注者企業分發能力的就緒時間，在今年的 5 月份，AGC 后臺企業分發能力提供之后，立即進行了全流程處理，包括申請企業開發者、申請證書以及測試走通下載整個過程。這種情況下，通過及時交流，我們可以第一時間進行測試實踐，有效降低或者避免了未來方案上的一些風險。

3）第三個例子：安全控件與系統 Picker

相信廣大開發者今年剛開始介入 HarmonyOS Next 開發時，對于使用到的一些權限，如讀取剪貼板，讀取或者保存圖片到相冊等等這些 ACL（Access Control List）訪問控制列表權限，都是通過在開發者后臺勾選這些權限從而實現在應用中彈窗許可訪問。但是在今年 6 月份的溝通中，我們獲知后面要讓開發者全部適配到安全控件方案。這些安全控件都是系統提供的選擇器，使用之后，每次需要用戶明確操作才行。

目前在 Android 和 iOS 中，如果想要在應用中上傳一張照片，就需要同意該應用獲得圖庫的訪問權限，而帶來的弊端就是，這個應用今后可隨意訪問你圖庫中的所有圖片。相比之前的授權彈窗許可一次之后，可能造成的權限濫用，安全控件提升了用戶對敏感權限的操作感知，算是 HarmonyOS Next 在保障用戶隱私安全方面的一個亮點和優勢。

這其中的核心理念便是從權限管控到數據管控。在 Android 和 iOS 原本的權限管控方案中，比如一旦給了通訊錄權限，那么相當于把通訊錄的鑰匙給予了應用開發者，如果開發者違規使用，在用戶不知情的讀取整個通訊錄，其實是不符合用戶的隱私要求。而數據管控便是不會再把通訊錄的鑰匙給開發者，而是你要什么樣的通訊錄數據，那么你只能通過通訊錄安全選擇控件中來選擇想要讀取的通訊錄，不再讓應用隨意獲取整個通訊錄數據。

關于安全控件我們進行了多次溝通，了解了安全控件在華為側推進的節奏以及我們整改的期限時間等，另外我們也提出個別場景，安全控件還不足以滿足訴求，譬如用戶保存圖片到相冊，還沒有對應的安全控件能力。這方面的溝通，會讓我們及時的對 App 的隱私合規性做出優化調整，避免后面因為隱私權限問題而影響上架。

及時溝通對于了解 Bug 的解決情況，功能交付時間、華為伙伴的要求等都是很有必要的，因為這些都會影響到開發測試到上線的一個節奏。

6、鴻蒙NEXT上的WebView混合頁面開發

6.1 概述

回到我們大前端來，得提一下大家關注的 WebView。在 HarmonyOS Next 中仍然沿用之前統一的 WebView 架構。

在 V1 版本中，需要做的核心工作包括：

• 1）實現 WebView Core 層；
• 2）JSBridge 層，新增實現 HarmonyOS Next 的 Bridge 通信；
• 3）平移安全層能力；
• 4）實現 Hybrid API 接口，也就是 Ability 層的能力。

需要特別提一下的是：HarmonyOS Next 使用的 Web 瀏覽器基于 ArkWeb（方舟Web內核），該內核基于 Chrome 114 版本定制，對于各種 CSS、HTML、JS 屬性在各大瀏覽器中的兼容性情況可以使用 https://caniuse.com/#home 這個網站進行查詢。

6.2 前期如何確定影響范圍和制定方案

Ability 層的接口：轉轉的 WebView 歷經多年的演進，Native 與 WebView 的交互 API 是有一定歷史包袱的。我們不希望鴻蒙這次繼續背著包袱前行，所以我們計劃趁著這次前端業務兼容鴻蒙的機會，進行一波優化，丟棄一些已經計劃不再使用的能力或者接口。比如老的半屏 WebView 方案，導航欄按鈕功能設置方案、非統跳的頁面跳轉接口等。

但一個方案的確定要充分考慮客戶端實現的難易程度以及前端大量業務側統一修改的難度代價，需要做到盡可能的合理平衡。為了確定這點，我們根據線上最近一個月中URL 中接口調用的埋點日志，結合 URL 查詢所屬業務、開發測試負責人的內部接口，整理了一張巨大的二維矩陣表，通過在線表格的過濾、篩選等功能，可以非常直觀的看到所有還在使用中的接口的業務調用分布情況，為我們評估方案改造工作量提供了重要的參考。

一個 Hybrid API 在鴻蒙上支持情況，分為下面幾種情況。

a） 直接支持，前端無需修改：提供和 Android、iOS 一樣的接口能力：

• 1）功能對等：能力實現和 Andriod、iOS 一樣；
• 2）簡化：比如瀏覽大圖、奢侈品鑒定，暫時使用簡版選圖方案。

b） 推薦使用新方案：

• 1）譬如導航欄相關按鈕的能力、新半屏能力；
• 2）如 enterChat 等等功能，使用統跳接口來實現跳轉。

c） 不支持：

• 1）業務下線：業務不再需要，下線處理；
• 2）版本初期不考慮該功能；
• 3）某端特定功能：為了解決某個問題，某端專門增加的一個 api 供使用；
• 4）系統能力不支持：HarmonyOS Next 沒有該項能力。

最終根據這些原則，我們確定下來 V1 版本中 WebView API 的需求范圍、涉及業務方、改動方案。現在回想起來，當時我們做的這一步是非常有必要的，前期這些如果沒有梳理清楚，后面就非常容易造成溝通混亂以及影響開發進度。

6.3 關于性能

轉轉前端的頁面主要是 Web 形態，Hybrid 場景占據多數。在過去的幾年中，我們圍繞 Hybrid 形態，摸索出了一系列 Web 頁面的優化方案。從基礎的離線包，到復雜的預渲染、預請求等都有涉及。最終實現了 Hybrid 頁面與 Native 頁面在電商場景下，相差無幾的體驗。

目前鴻蒙在這塊優化上，還都沒來得及跟進這些優化手段。這個也是后面要繼續建設的一個方向，最終要拉齊到和Android、iOS 一樣的性能優化體驗。

7、后續開發展望

首個版本上線，只是一個起點。

在業務上，我們將不斷的繼續追平 Android、iOS 中那些重要的模塊和功能；

在開發工具體驗和支持上，也逐漸補足缺失的能力，比如豐富的Native、WebView小工具能力，進一步提升客戶端和前端在 HarmonyOS Next 下的開發體驗。

在性能體驗上，持續的關注和跟進性能問題，優化 WebView 以及 Native 的使用體驗，提升 App 的流暢度和響應速度。

在創新上，我們將持續探索，將更多的 HarmonyOS Next 下的創新場景，如元服務、意圖推薦等等融入到轉轉 App 中，提升用戶的購物使用體驗。

要做的事情很多，我們會在后續迭代中逐步完善起來這些能力，敬請期待。

8、相關資料

[1] 鴻蒙NEXT官方開發指南

[2] 一年擼完百萬行代碼，企業微信的全新鴻蒙NEXT客戶端架構演進之路

[3] 鴻蒙NEXT如何保證應用安全：詳解鴻蒙NEXT數字簽名和證書機制

[4] 開源IM聊天程序HarmonyChat：基于鴻蒙NEXT的WebSocket協議

[5] 微信純血鴻蒙版正式發布，295天走完微信14年技術之路！

[6] 即時通訊框架MobileIMSDK的鴻蒙NEXT端詳細介紹

[7] 即時通訊框架MobileIMSDK的鴻蒙NEXT端開發者手冊

[8] 轉轉平臺IM系統架構設計與實踐(一)：整體架構設計

[9] 轉轉平臺IM系統架構設計與實踐(二)：詳細設計與實現

[10] Web端IM聊天消息該不該用瀏覽器本地存儲？一文即懂

[11] 手把手教你使用網絡編程抓包神器Wireshark

[12] 淺談網頁端IM技術及相關測試方法實踐（包括WebSocket性能測試）

（本文已同步發布于：http://www.52im.net/thread-4820-1-1.html）

本文由夏冰軟件cc分享，下文進行了排版和內容優化。

1、引言

本文接上篇《什么是IM系統的消息時序一致性？》，本篇將通俗易懂地講解IM系統中的端到端加密原理，為了降低閱讀門檻，相關的技術概念會提及但不深入展開。

IM即時通訊系統的技術本質是“即時消息技術”，是互聯網實時互動場景的底層架構，包括聊天、直播、在線客服等業務領域在內，所有需要實時互動、高實時性的場景，都需要用到IM技術。而為了讓即時通訊更安全，高安全場景下的IM系統通常會使用端到端加密技術進行通訊加密。下面我們就來了解一下端到端加密技術在IM系統中的應用。

技術交流：

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發布于：http://www.52im.net/thread-4792-1-1.html）

2、系列文章

1. 《零基礎IM開發入門(一)：什么是IM系統？》
2. 《零基礎IM開發入門(二)：什么是IM系統的實時性？》
3. 《零基礎IM開發入門(三)：什么是IM系統的可靠性？》
4. 《零基礎IM開發入門(四)：什么是IM系統的消息時序一致性？》
5. 《零基礎IM開發入門(五)：什么是IM系統的端到端加密？（* 本文）》
6. 《零基礎IM開發入門(六)：什么是IM系統的的心跳機制？ (稍后發布)》
7. 《零基礎IM開發入門(七)：如何理解并實現IM系統消息未讀數？ (稍后發布)》
8. 《零基礎IM開發入門(八)：如何理解并實現IM系統的多端消息漫游？ (稍后發布)》

3、網絡通訊數據加密的3個層次

3.1 概述

一般的數據加密可以在通信的3個層次來實現：鏈路加密、節點加密和端到端加密。

3.2 鏈路加密

對于在兩個網絡節點間的某一次通信鏈路，鏈路加密能為網上傳輸的數據提供安全保證。對于鏈路加密(又稱在線加密)，所有消息在被傳輸之前進行加密，在每一個節點對接收到的消息進行解密，然后先使用下一個鏈路的密鑰對消息進行加密，再進行傳輸。

在到達目的地之前，一條消息可能要經過許多通信鏈路的傳輸。由于在每一個中間傳輸節點消息均被解密后重新進行加密，因此，包括路由信息在內的鏈路上的所有數據均以密文形式出現，這樣，鏈路加密就掩蓋了被傳輸消息的源點與終點。由于填充技術的使用以及填充字符在不需要傳輸數據的情況下就可以進行加密，這使得消息的頻率和長度特性得以掩蓋，從而可以防止對通信業務進行分析。

相關文章推薦閱讀：《IM聊天系統安全手段之通信連接層加密技術》。

3.3 節點加密

盡管節點加密能給網絡數據提供較高的安全性，但它在操作方式上與鏈路加密是類似的：兩者均在通信鏈路上為傳輸的消息提供安全性，都在中間節點先對消息進行解密，然后進行加密。因為要對所有傳輸的數據進行加密，所以加密過程對用戶是透明的。然而，與鏈路加密不同，節點加密不允許消息在網絡節點以明文形式存在，它先把收到的消息進行解密，然后采用另一個不同的密鑰進行加密，這一過程是在節點上的一個安全模塊中進行。

節點加密要求報頭和路由信息以明文形式傳輸，以便中間節點能得到如何處理消息的信息，因此這種方法對于防止攻擊者分析通信業務是脆弱的。

3.4 端到端加密

端到端加密允許數據在從源點到終點的傳輸過程中始終以密文形式存在。采用端到端加密(又稱脫線加密或包加密)，消息在被傳輸時到達終點之前不進行解密，因為消息在整個傳輸過程中均受到保護，所以即使有節點被損壞也不會使消息泄露。

端到端加密系統的價格便宜些，并且與鏈路加密和節點加密相比更可靠，更容易設計、實現和維護。端到端加密還避免了其它加密系統所固有的同步問題，因為每個報文包均是獨立被加密的，所以一個報文包所發生的傳輸錯誤不會影響后續的報文包。端到端加密系統通常不允許對消息的目的地址進行加密，這是囚為每一個消息所經過的節點都要用此地址來確定如何傳輸消息。由于這種加密方法不能掩蓋被傳輸消息的源點與終點，因此它對于防止攻擊者分析通信業務是脆弱的。

沒有使用端到端加密時的通信原理圖（各個環節都存在泄密的可能）：

使用端到端加密后的通信原理圖（除了發送者和接收者，其它環境都是密文狀態）：

4、IM系統中的端到端加密原理

在IM系統中，當用戶A發送消息給用戶B時，IM系統會生成一對公鑰和私鑰，并將公鑰發送給用戶B。用戶A使用用戶B的公鑰對消息進行加密，然后將加密后的消息發送給用戶B。

在用戶B接收到消息后，使用自己的私鑰對消息進行解密，從而獲取明文內容。由于私鑰只有用戶B擁有，因此除了用戶B之外，任何人都無法解密消息。

沒有使用端到端加密時的聊天消息存在諸多風險：

使用了端到端加密后的聊天就安全多了：

5、IM系統使用端到端加密的好處

數據安全性：在IM系統中，端到端加密可以確保消息在傳輸過程中始終保持加密狀態，防止黑客和第三方竊取用戶的通信內容。

隱私保護：由于消息內容只有通信雙方能夠解密和閱讀，即使是IM系統應用自身也無法獲取明文內容。這意味著用戶的隱私得到了最大程度的保護。

抗竊聽：IM系統使用端到端加密技術，使得竊聽者無法獲取通信內容，從而有效防止了竊聽行為的發生。

6、IM系統使用端到端加密的意義

由于在數據傳輸到服務器之后，任何有權訪問此服務器的人，包括員工、供應商及其他有關人員（甚至是黑客），都有可能讀取到用戶的數據。

所以，使用端到端加密技術主要有以下意義：

1）保護個人隱私：在信息時代，個人隱私面臨著越來越大的威脅。在IM系統中使用端到端加密可以有效保護了用戶的通信內容，確保個人隱私不被侵犯。

2）防止數據泄露：許多用戶在社交軟件中分享了大量的個人信息和敏感數據。而IM系統中的端到端加密就可以確保這些數據在傳輸過程中不會被竊取，從而避免了數據泄露的風險。

3）抵御網絡攻擊：黑客和網絡犯罪分子經常利用網絡漏洞和弱點來攻擊用戶的通信。IM系統中的端到端加密可以有效防止這些攻擊，保護用戶的通信安全。

4）維護社交關系：人們越來越依賴社交應用來保持聯系和交流。IM系統使用端到端加密可以使得用戶能夠放心地分享私密信息，維護社交關系的同時保護了個人隱私。

7、IM系統使用端到端加密的不足

通訊效率低：由于端對端加密需要對通訊數據進行加密和解密，因此可能會導致通信效率較低。

需雙向支持：端對端加密需要發送方和接收方都需要支持該技術，否則就將無法實現端對端加密通信。

安全性問題：雖然端對端加密可以防止中間人攻擊，但如果黑客能夠獲得了私鑰或公鑰，那么他們也能夠輕易地獲取到通信數據。

8、延伸閱讀

本文內容主要是面向即時通訊技術的初學者以及產品經理，所以相關的技術概念都沒有深入探討，感光趣的可以繼續深入閱讀我整理的以下幾篇資料。

1. IM聊天系統安全手段之通信連接層加密技術
2. IM聊天系統安全手段之傳輸內容端到端加密技術
3. 移動端安全通信的利器——端到端加密（E2EE）技術詳解
4. 簡述實時音視頻聊天中端到端加密（E2EE）的工作原理

9、參考資料

[1] 網絡編程懶人入門(三)：快速理解TCP協議一篇就夠

[2] 即時通訊初學者必知必會的20個網絡編程和通信安全知識點

[3] 為什么要用HTTPS？深入淺出，探密短連接的安全性

[4] 理論聯系實際：一套典型的IM通信協議設計詳解（含安全層設計）

[5] 微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解

[6] 移動端安全通信的利器——端到端加密（E2EE）技術詳解

[7] 常用加解密算法與通訊安全講解

[8] 通俗易懂：一篇掌握即時通訊的消息傳輸安全原理

[9] 基于Netty的IM聊天加密技術學習：一文理清常見的加密概念、術語等

[10] 手把手教你為基于Netty的IM生成自簽名SSL/TLS證書

[11] 微信技術分享：揭秘微信后臺安全特征數據倉庫的架構設計

[12] 即時通訊初學者必知必會的20個網絡編程和通信安全知識點

（本文已同步發布于：http://www.52im.net/thread-4792-1-1.html）

本文由B端技術中心資深開發工程師馬家憶分享，原題“B站在實時音視頻技術領域的探索與實踐”，下文進行了排版和內容優化。

1、引言

直播行業從傳統的娛樂直播發展到教育直播、電商直播等形式，產生了很多新的玩法。傳統的直播是一位主播展示才藝，觀眾通過彈幕、送禮物等方式進行互動。隨著網絡質量不斷地提高，用戶也對直播平臺產生的新的要求，實時互動直播的場景就出現了，觀眾可以同時觀看多位主播之間互動的畫面，讓直播間的氣氛更好。B站直播的連麥PK、視頻連線業務就提供了這個能力。主播看到的是對方主播實時的流（延遲400ms以內），而觀眾看到的是“準實時”的流（延遲2~5s左右）。

本文講述搭建這樣一套最新流行的實時視頻直播系統需要了解的背景知識以及系統的整體架構，希望對大家有幫助。

2、系列文章

本文是系列文章中的第 13 篇，本系列總目錄如下：

《視頻直播技術干貨(一)：揭秘百萬級粉絲互動的Facebook實時視頻直播》

《視頻直播技術干貨(二)：P2P技術如何將實時視頻直播帶寬降低75%？》

《視頻直播技術干貨(三)：實時直播答題系統的實現思路與技術難點分享》

《視頻直播技術干貨(四)：首次披露快手是如何做到百萬觀眾同場看直播仍能秒開且不卡頓的？》

《視頻直播技術干貨(五)：七牛云使用QUIC協議實現實時視頻直播0卡頓》

《視頻直播技術干貨(六)：新浪微博實時直播答題的百萬高并發架構實踐》

《視頻直播技術干貨(七)：實時視頻直播首屏耗時400ms內的優化實踐》

《視頻直播技術干貨(八)：淘寶高清、低延時的實時視頻直播技術解密》

《視頻直播技術干貨(九)：千萬級直播系統后端架構設計的方方面面》

《視頻直播技術干貨(十)：一文讀懂主流視頻直播系統的推拉流架構、傳輸協議等》

《視頻直播技術干貨(十一)：超低延時視頻直播技術的演進之路》

《視頻直播技術干貨(十二)：從入門到放棄，快速學習Android端直播技術》

《視頻直播技術干貨(十三)：B站實時視頻直播技術實踐和音視頻知識入門》（* 本文）

3、關于作者

馬家憶：B端技術中心資深開發工程師。

4、實時音視頻關鍵技術概述

從0到1搭建一套實時音視頻系統并支撐現有的業務，如果沒有接觸過這方面的東西會感覺無從下手。

我們可以看到，1996年IETF就推出了RTP協議用于實時音視頻傳輸，2011年Google推出了WebRTC用于網頁端實時音視頻通話（見《了不起的WebRTC：生態日趨完善，或將實時音視頻技術白菜化》）。

從這些現有的協議和項目中，我們可以發現實時音視頻技術的關鍵點，評估自身現有的基礎組件支持情況并結合業務場景尋找適合自己的解決方案。

5、關鍵技術1：傳輸協議

RTP協議（Real-time Transport Protocol）定義了在互聯網上傳輸實時音視頻數據的標準格式，屬于應用層協議。RFC 3550描述RTP協議的傳輸層主要使用UDP，RFC 4571描述了RTP協議的TCP傳輸方式。

在我們的實時音視頻場景中應當優先選擇UDP，理由如下：

1）TCP保證數據流的可靠性和順序性。TCP的超時重傳策略為了保證通用和公平，相對比較保守，重傳超時時間（RTO）可能會變的很大。假如中途丟失一個包，后續的包即使先到達也要緩存起來等待重傳完成以后才能送到應用層。在網絡狀況不佳的情況下，使用TCP傳輸會產生較大的延遲；

2）UDP允許數據包丟失、亂序和重復。即使數據丟失也不會阻塞接收緩沖區等待重傳，這就為實時性提供了保障。在上層的RTP協議中，協議頭部包含了時間戳和序列號，可以對數據包進行重排和丟棄，解決了亂序和重復的問題。如果接收端監測到丟包，并且丟失的包是必要的且無法恢復，則發送NACK消息通知發送端重傳（下一節會詳細探討這個話題）。

UDP雖然在低延遲領域上有壓倒性的優勢，但是用戶側有可能存在防火墻攔截所有的UDP包。考慮到在網絡環境足夠好的情況下使用TCP也能達到不錯的效果，因此我們做了一個降級策略，優先使用UDP，當且僅當UDP不通的時候使用TCP。

6、關鍵技術2：丟包補償

前面講到我們的傳輸層協議優先選擇UDP，那么就需要引入一些機制解決丟包問題。

前向糾錯FEC（Forward Error Correction）指的是發送端發送原始數據的同時附加部分冗余的信息，如果接收端檢測到原始數據丟失則嘗試使用冗余的信息進行恢復。發送端發送n個數據包，同時根據原始數據生成k個冗余的數據包，將n+k個數據包發送出去，接收端只要收到至少n個數據包就可以得到全部的原始數據。

FEC算法的關鍵在于異或。異或(Exclusive OR)是一個數學運算符，數學符號為“⊕”，兩邊數值轉換成二進制按位運算，相同時為0，不同時為1。

以一階冗余算法為例，n個數據包生成1個冗余包，發送n+1個數據包。我們發送三個數值分別為a、b、c，生成冗余數據x=a ⊕b ⊕ c一起發送。假如數值b在傳輸中丟失了，計算a ⊕c ⊕ x即可得到b。

在實際應用中，FEC沒有這么簡單，WebRTC實現了UlpFEC和FlexFEC，UlpFEC可以針對數據包的重要程度實施不同程度的保護以充分利用帶寬，FlexFEC還支持對列做冗余，同時WebRTC默認的音頻編碼器Opus本身就支持FEC。

前向糾錯適合少量隨機丟包的場景，可以無視網絡延遲時間，但是增加了帶寬消耗。

后向糾錯包括ARQ（Automatic Repeat Request）和PLC（Packet Loss Concealment）。ARQ指的是接收端檢測到數據丟失的時候發送NACK報文請求發送端重傳，適合突發大量丟包的場景，沒有額外的帶寬消耗，但是時效性取決于RTT，如果存在很多接收端還要考慮避免NACK風暴造成雪崩。PLC用于音頻，當數據缺失時使用模型根據前后數據預測丟失的數據。

總之，前向糾錯和后向糾錯各有優缺點，需要搭配使用。

7、關鍵技術3：流量控制

流量控制指的是根據網絡狀況的波動估算可用帶寬，根據帶寬的變化自動調節音視頻碼率和發送速率。當網絡質量變差的時候迅速降低數據量以確保實時性，網絡較好時則慢慢提升數據量帶來更清晰的畫面。在WebRTC中提供了優秀的Google Congestion Control算法，包括基于延遲的評估和基于丟包率的評估，取兩種評估方式的最小值作為目標帶寬通知編碼器和數據發送模塊。

基于延遲的評估算法包括Transport-CC和Goog-REMB，目前最新版的WebRTC默認使用的是Transport-CC。Transport-CC在發送端進行帶寬評估，接收端通過TransportFeedback RTCP包向發送端反饋每個RTP包的到達時間，發送端在一個時間窗口內計算每個RTP包到達時間與發送時間之差，通過Trendline濾波器處理后預測網絡狀況。假設我們當前處于Hold狀態，如果檢測到網絡狀態為OverUse，此時應該減小數據量，變更為Decrease狀態；如果檢測到網絡狀態為Normal，此時可以嘗試增加數據量，變更為Increase狀態。

基于丟包的評估算法是當網絡突發大量丟包時的兜底策略：

• 1）如果丟包率在2%以下的時候說明網絡質量好，目標帶寬增加8%；
• 2）如果丟包率在在2%~10%說明當前發送數據的帶寬和網絡質量相匹配可以保持不變；
• 3）如果丟包率大于10%說明網絡質量差，目標帶寬減小到(1-丟包率*0.5)* 當前帶寬。

8、關鍵技術4：數據緩沖

如果我們只考慮實時性，那么收到數據就立刻解碼并渲染必然是最好的選擇，但是網絡并不穩定，延遲、亂序、丟包、重復包都有可能發生。如果采用上面的策略，音頻可能因為網絡的抖動變的斷斷續續，視頻可能因為丟包導致缺少參考幀從而出現黑屏或花屏，所以有必要引入一個緩沖區，增加一點可以接受的延遲來保證用戶體驗。

在WebRTC中，視頻包會被放入JitterBuffer模塊進行處理，JitterBuffer會進行視頻包的排序、組裝成完整的幀、確保參考幀有效，然后把數據送到解碼器。同時，根據網絡狀況自適應地調節緩沖區的長度。音頻包會被放入NetEQ中，它維護了音頻的緩沖區，同時負責將音頻同步到視頻。我們做播放器一般都是以音頻的時間為基準同步視頻，但是WebRTC剛好相反，它是以視頻為基準的。當音頻數據堆積的時候加速音頻播放，音頻數據不足的時候降低速度把音頻拉長。

9、關鍵技術5：回聲消除

在語音通話的場景中，麥克風采集到的聲音發送給遠端，遠端的揚聲器播放出來以后又被遠端的麥克風采集到這個聲音并傳送回來，這樣講話的人會感覺到有回聲，影響體驗。

WebRTC提供了回聲消除算法AEC，時延估計（Delay Estimation）模塊找到揚聲器信號和麥克風信號的時延，線性自適應濾波器（Linear Adaptive Filter）參考揚聲器信號估算回聲信號并將其剪去，最后通過非線性處理（Nonlinear Processing）模塊消除殘留的回聲。

10、關鍵技術6：最優路徑

實時音視頻對網絡的要求非常高，如果通話雙方距離很遠，那么通話質量是很難保證的。城市A的設備給城市D的設備發送數據，直接發送未必是最優的選擇，從城市B和城市C中轉一下有可能更快。

理想的解決方案是在全球部署加速節點，用戶就近接入。根據加速節點之間的實時網絡質量探測數據，找到一條最優傳輸路徑，避開網絡的擁堵。

11、開源音視頻框架WebRTC簡述

剛才介紹了實時音視頻系統實現過程中所需的關鍵技術，多次提到了WebRTC。顯然，對于絕大多數團隊來說，這些內容如果全部自主研發幾乎是不可能的事情，而我們站在WebRTC的基礎上去設計自己的系統是較為明智的選擇。

WebRTC的代碼非常復雜，想要把它搞清楚是一件非常困難的任務，我第一次看到WebRTC的代碼根本就不知道從哪里下手。

幸運的是，WebRTC官方提供了架構圖，可以先幫助我們對它進行一個宏觀的了解。

WebRTC整體架構大概可以分為接口層、會話層、引擎層和設備I/O層：

1）接口層包括Web API和WebRTC C++ API，Web API給Web開發者提供了JavaScript接口，這樣Web端就具備了接入WebRTC的能力；WebRTC C++ API面向的是瀏覽器開發者，讓瀏覽器開發商具備集成WebRTC的能力。當然，WebRTC C++ API也可以用于Native客戶端接入；

2）會話層主要包含信令相關的邏輯，比如媒體協商，P2P連接管理等；

3）引擎層是WebRTC最核心的功能，包括音頻引擎、視頻引擎和傳輸模塊。音頻引擎包含音頻編解碼器（Opus）、NetEQ和著名的3A（回聲消除、自動增益、降噪）算法；視頻引擎包括視頻編解碼器（VP8、VP9、H264）、JitterBufer和圖像增強（降噪）算法；傳輸模塊包含SRTP、多路復用和P2P模塊；

4）設備I/O層主要和硬件交互，包括音視頻采集和渲染，以及網絡I/O。

上面一節描述的實時音視頻關鍵技術中，WebRTC實現了除“最優路徑”之外的全部內容。WebRTC幾乎每個模塊都是可以按需替換的，便于我們增加定制的內容。我們可以根據實際需求決定如何使用WebRTC，Native客戶端可以通PeerConnection接口接入，服務端拿到RTP/RTCP包以后完全可以直接調用引擎層處理拿到最終的YUV和PCM數據，甚至只把WebRTC內部模塊摳出來用在自己的系統上也是沒問題的。

更多相關資料可閱讀：

1. 零基礎入門：基于開源WebRTC，從0到1實現實時音視頻聊天功能
2. 實時音視頻入門學習：開源工程WebRTC的技術原理和使用淺析
3. 零基礎快速入門WebRTC：基本概念、關鍵技術、與WebSocket的區別等

12、B站視頻直播系統架構

我們回到B站的連麥PK業務場景，兩位主播進行互動PK，同時大量觀眾在直播間觀看PK的過程。

顯然，兩位主播通話要求低延遲，必須使用實時音視頻系統交互；而觀眾觀看直播的延遲要求相對沒那么嚴格，可以采取傳統直播的模式，通過RTMP或者SRT推流到CDN，用戶從CDN拉流。

然后我們要思考兩個問題。

12.1 問題1：主播之間的音視頻通話是采用P2P還是服務器中轉？

首先對P2P和服務器中轉兩種方案做個對比：

對于P2P方案來說，只需要部署STUN和TURN服務器，如果成功建立P2P連接那么后續媒體數據傳輸就不需要經過服務器，所以具有成本優勢。然而，P2P的缺點也很明顯，如果打洞失敗還是需要TURN服務器中轉，且建立連接的過程耗時較高，用戶之間距離較遠的情況下網絡質量不可控，而且現有的第三方網絡加速服務基本上都不支持P2P。

我們這里選擇服務器中轉的方案，因為實時音視頻本身對網絡的要求比較高，不會設置過高的碼率，所以網絡傳輸的數據量是可控的，成本能夠接受。而且我們的實時音視頻數據要對接AI審核，還要實現服務器混流，這是P2P方案做不到的。

12.2 問題2：推送給觀眾的流到CDN，這個工作放在主播客戶端還是服務器？

兩位主播PK對應的是兩路流，觀眾只從CDN拉一路流，所以必須有個地方做混流。這里的混流指的是把兩位主播的視頻進行拼接、音頻進行混合，然后打包成一路流。主播客戶端能收到對方的流，可以和自己的流做混流；在前面提到的服務器中轉方案中，服務器有雙方的流，同樣也可以完成混流。

我們先對比一下兩種方案的優劣：

服務器進行混流需要先解碼再編碼，這需要消耗大量計算資源，所以成本很高；主播客戶端進行混流需要額外增加一路流的編碼和上傳，對設備性能和上行帶寬來說也是很大的挑戰。

主播客戶端需要等待服務器把對方的流發送過來才能混流，所以從延遲的角度來看服務器混流稍微占據優勢，不過這個延遲相比CDN的延遲可以忽略不計。如果后期對通話質量要求變高，主播的設備性能和上行帶寬跟不上，我們可以很容易增加服務器來擴展計算資源和帶寬，所以在可擴展性方面服務器混流勝出。

另外，當主播從正常直播切換到連麥PK狀態的時候，采用服務器混流必須先把直播的流停掉再由服務器接管，中間的時間差可能會產生卡頓或黑屏影響觀眾體驗，而主播客戶端混流可以做到無縫切換。

所以，這兩種方案各有優缺點，我們采取折衷的辦法：如果主播的設備負載較低且上行帶寬比較充足，優先采用主播客戶端混流的方式，否則降級為服務器混流。

12.3 開始架構設計

上面兩個問題分析清楚了，就可以開始設計了。

這是我們的系統整體架構：

rtc-service主要提供信令、頻道管理、主播管理、公有云上媒體服務器集群的健康檢查和節點分配、同步主播狀態到業務服務器、記錄通話流水。

rtc-job是對rtc-service的補充，定期檢查當前在線主播的狀態，發現主播異常下線時觸發兜底邏輯。

rtc-router負責收發主播的音視頻數據。主播可以收到同一個頻道內其他人的音視頻流。如果需要服務器混流，則訪問注冊中心并采用Google的有界負載一致性哈希算法（Consistent Hashing with Bounded Loads）選取rtc-mixer節點，并往對應節點推送主播的音視頻流。

rtc-mixer負責混流，根據需求拼接畫面和混音，然后推送到CDN，觀眾通過CDN拉流。

主播的客戶端并沒有直接向rtc-router發送數據，而是通過第三方的四層加速網絡轉發。我們前面提到了“最優路徑”的概念，第三方的四層加速服務可以讓用戶接入最近的加速節點，然后尋找最優路徑把數據轉發到我們的公有云節點。客戶端只能看到第三方的加速節點IP，看不到我們公有云媒體服務器的IP，這在一定程度上可以防止服務器遭到攻擊；其次，我們可以在保證異地多活的前提下讓公有云集群相對比較集中，節省成本。

服務的可用性和容錯性也是一個很重要的問題，假如在主播PK即將勝利的時刻服務出現故障，彈出"PK異常終止請重新再來"，這很令人絕望。我們不僅要保證服務可用，還要盡最大可能保證服務出現故障時減小對用戶的影響，讓流程能夠走下去。接下來討論系統中每個風險模塊為了實現這個目標所采取的措施：

四層加速網絡故障。這個屬于第三方廠商提供的服務，每個廠商提供的接入方式大同小異，基本上就是附加的header有差別，所以同時對接多家廠商對客戶端來說是很容易做到的。客戶端進行連通性檢查，只要存在至少一家廠商的服務可用，就不會影響業務。

公有云上的rtc-router和rtc-mixer故障。在公有云上部署服務，盡量要多廠商、多區域部署，防止單機房整體宕機。我們同樣準備了多個集群，每個集群都部署了多臺rtc-router、rtc-mixer和ZooKeeper，單個集群可以獨立工作，如果單個集群不可用或者負載達到上限則會被熔斷。核心機房的rtc-service會對公有云上的集群進行健康檢查，如果rtc-router宕機，rtc-service會通過信令通道通知客戶端切換到同集群中其他服務器，當同集群沒有可用機器時則切換集群。如果rtc-mixer宕機，rtc-router會通過ZooKeeper重新選擇一臺接管混流任務。

核心機房的rtc-service和rtc-job故障。這部分內容和B站大部分核心服務部署在同樣的集群，復用了B站比較成熟的高可用架構。這部分內容可以參考其他文章，這里不再贅述。

13、本文小結

如果我們把實時音視頻技術比作一座富麗堂皇的城池，這篇文章只能帶領大家來到城門口。我們也不會停止探索的腳步。希望大家讀到這里能夠有所收獲，如有疏漏，歡迎批評指正。

14、參考資料

[1] 實時語音通訊的回音及回音消除概述

[2] 實時語音通訊的回音消除技術詳解

[3] 實時語音通訊丟包補償技術詳解

[4] 零基礎，史上最通俗視頻編碼技術入門

[5] IM實時音視頻聊天時的回聲消除技術詳解

[6] 學習RFC3550：RTP/RTCP實時傳輸協議基礎知識

[7] 基于RTMP數據傳輸協議的實時流媒體技術研究（論文全文）

[8] 愛奇藝技術分享：輕松詼諧，講解視頻編解碼技術的過去、現在和將來

[9] 零基礎入門：實時音視頻技術基礎知識全面盤點

[10] 實時音視頻面視必備：快速掌握11個視頻技術相關的基礎概念

[11] 零基礎入門：基于開源WebRTC，從0到1實現實時音視頻聊天功能

[12] 實時音視頻入門學習：開源工程WebRTC的技術原理和使用淺析

[13] 零基礎快速入門WebRTC：基本概念、關鍵技術、與WebSocket的區別等

[14] 移動端實時音視頻直播技術詳解（五）：推流和傳輸

[15] 移動端實時音視頻直播技術詳解（六）：延遲優化

[16] 實時視頻直播客戶端技術盤點：Native、html5、WebRTC、微信小程序

[17] 淺談開發實時視頻直播平臺的技術要點

[18] 視頻直播技術干貨：一文讀懂主流視頻直播系統的推拉流架構、傳輸協議等

（本文已同步發布于：http://www.52im.net/thread-4785-1-1.html）