融合通信常見問題3月刊 | 雲信小課堂

「融合通信常見問題」月刊將在每月末與大家見面，該月刊主要包括錯題集、知識加油站、技術加餐三大板塊，彙集實踐過程中的易錯問題和解題思路，分享融合通信領域的前沿資訊和技術乾貨，爲您的開發提效加速，爲您的進階之路添磚加瓦。

本期內容概覽

看這裏！別人踩過的坑快繞開！

Mac 端使用 Type-C 耳機說話別人聽不到；

聲音從藍牙耳機播放切換到外放；

退到後臺一段時間後再說話，對方聽不到聲音；

iOS 端呼叫組件初始化時 APP 卡死；

小程序說話，Native 聽不到；

發送信息失敗；

因加密模式問題無法上架到 Google 商店；

App 啓動時，應用使用不流暢

......

這些知識點你知道嗎：

直播場景與通信場景有什麼區別？

SDK 支持的 QoS 策略是什麼意思？

如何處理無聲問題？

如何處理回聲問題？

這些乾貨也不容錯過！

網易會議組件正式開源

網易會議開源之移動端篇、桌面端篇

RTC 音頻質量評價和保障

Gitlab-ci 替代 webhook 觸發Jenkins job

SQLite 簡介

20萬字《網易智企技術合輯》重磅發佈

一、錯題集

音視頻通話

疑難問題 1：

Mac 端插入 Type-C 耳機之後說話，其他端聽不到。

易錯等級：⭐⭐⭐⭐

錯題原因：

Mac 對於 Type-C 耳機的適配有問題，Mac 端在插入 Type-C 耳機後，說話時系統聲音面板中的輸入電平很低或者幾乎沒有，而且在該情況下，市面上其他的通話軟件效果均一致。因此判斷無法正常使用 Type-C 的耳機是 Mac 對於 Type-C 耳機的適配不好導致。

解題思路：

建議可以更換其他耳機或者使用系統麥克風通話。

疑難問題 2：

音視頻發送音頻流，接收端聽到的聲音異常，從藍牙耳機播放切換到外放。

接收端一開始聽到的聲音是通過藍牙耳機播放的，在調用 enableLocalAudio 設置成 true 之後，聲音異常變爲外放，再次調用 enableLocalAudio 設置成 false 之後，聲音恢復通過藍牙耳機播放。

易錯等級：⭐⭐⭐

錯題原因：

iOS 的音頻是通過 AVAudioSession 管理的，是單例類，不止 SDK 可以調用，客戶業務層也可以修改 AVAudioSession 的 option，這個問題現象看跟調用 SDK 的方法有關，實際上是在調用 SDK 方法的時候，客戶業務層有調用修改 AVAudioSession 的 option，修改成了外放類型 AVAudioSessionCategoryOptionDefaultToSpeaker。

解題思路：

業務層有使用到 AVAudioSession 的時候，注意管理好業務層的調用。在通過 SDK 進行音頻輸出的時候避免修改 AVAudioSession。

疑難問題 3：

Android 端發送音視頻/純音頻，退到後臺一段時間後再說話，對方聽不到聲音。

易錯等級：⭐⭐⭐

錯題原因：

音視頻採集退後臺後被系統限制。長時間退後臺，採集是個高危動作，極有可能被系統限制，取決於用戶對APP 的設置及系統對這種行爲的限制要求，系統限制詳情請見行爲變更（https://developer.android.com/about/versions/pie/android-9.0-changes-all）；

解題思路：

在鎖屏或將應用退至後臺前，建議用戶可以先開啓前臺服務，從而讓應用正常工作（繼續採集聲音和視頻畫面），在退出鎖屏或返回前臺前終止前臺服務；不過需要有個預期：因爲高版本 Android 系統對於退後臺繼續採集這種敏感操作非常嚴格，前臺服務的保活也是有風險的，需要考慮好異常情況的處理方式。

疑難問題 4：

iOS 端呼叫組件初始化時，偶現 APP 卡死情況

易錯等級：⭐⭐⭐

錯題原因：

呼叫組件內部初始化 IM 和老版本 RTC SDK 互鎖導致卡死。

解題思路：

按照官網文檔在 pod 導入 NERtcCallKit 的時候，指定 NERtcSDK 版本爲 4.2.120。

示例如下：

pod 'NERtcCallKit', '1.5.0'

pod 'NERtcSDK', '4.2.120'

4.2.120 版本是呼叫組件適配的穩定版本，pod 不指定版本拉到的 NERtcSDK 不是穩定版本。

疑難問題 5：

小程序和 Native 通話時，小程序說話，Native 聽不到

易錯等級：⭐⭐⭐

錯題原因：

小程序調用 publish 時參數傳遞錯誤。小程序端 publish 時，需要傳入要發佈的媒體類型，而在傳參時錯誤的認爲傳入 video 表示音視頻都發布。

解題思路：

1. 發佈音視頻流時 publish 中 mediaType 應設置爲''（空字符串）；
2. 發佈純視頻流時 mediaType 應設置爲 video；
3. 發佈純音頻流時 mediaType 應設置爲 audio。

IM即時通訊

疑難問題 6：

以下兩種場景時，發送失敗，報錯參數錯誤：

1.再次 sendMessage 發送已經發送過的圖片和文件類消息；

2.直接 forwardMessage 發送新創建的消息。

易錯等級：⭐⭐⭐

錯題原因：

1.文件類消息創建的時候可以選擇相冊路徑和 data 兩種形式創建，創建的時候會賦值給文件 NIMMessageObject 的私有屬性 sourceImage，sourceFilepath 和s ourceData。發送完消息的時候，這些私有屬性會置空。如果再次調用 sendmessage 方法的話，會因爲找不到這些參數報錯參數錯誤；

2.forwardMessage 發送消息，SDK 會解析 messageObject 的 encodeContent 屬性，拿到 messageObject 的對象數據進行轉發，如果是新創建的消息調用轉發方法發送會因爲找不到 messageObject 的 encodeContent 報錯參數錯誤。

解題思路：

1.這種場景如果是轉發的場景就需要調用轉發的接口 forwardMessage，或者先調用 makeForwardMessageFromMessage 構造轉發的message，再 sendMessage 發送。

如果是自己想多次發送同一個內容的消息，就按創建消息的流程，創建一個 message 對象發送一次，避免發送完不重新創建就再次 sendMessage 同一個 message對象。

2.新創建的消息直接使用 sendMessage 發送，避免調用轉發接口 forwardMessage 發送。

疑難問題 7：

客戶需要上架到 Google 商店的時候，會被檢測到有一處使用了不安全的加密模式的問題，導致無法上架。

易錯等級：⭐⭐⭐

錯題原因：

Google 不支持 AES/ECB/PKCS5Padding 的加密模式。

解題思路：

在 IM SDK 8.11.5 之後的版本去除了該加密模式，可以升級處理。

疑難問題 8：

App 啓動的時候，應用會出現使用不流暢的情況。看 logcat 日誌顯示 IM 相關日誌頻繁打印。

易錯等級：⭐⭐⭐

錯題原因：

有可能是頻繁調用阻塞查詢本地數據的接口，這類接口會查詢本地數據庫，如果在 UI 線程中循環調用會出現性能問題，導致 UI 卡頓。可以通過在 logcat 日誌中過濾 TransExec: execute Transaction 關鍵字，確認是否有 IM 接口頻繁調用的情況，尤其需要注意“xxxBlock();”這類同步方法。

解題思路：

1. 確認是否爲業務層實現有問題，通過調整業務層邏輯，避免接口頻繁調用。

2. 查看api確認是否有批量查詢的方法，避免循環調用。例如 TeamService.queryTeamBlock 可以改爲 TeamService.queryTeamListBlock。

3. 改爲異步調用方法，或者放在子線程中調用，防止UI卡頓。

二、知識加油站

直播場景與通信場景有什麼區別？

NERTC SDK 通過 setChannelProfile 方法設置實時音視頻通話的場景，您可以通過該方法將房間設置爲通信場景或直播場景，默認爲通信場景。網易雲信會針對不同實時音視頻場景設置不同的優化策略，例如用戶角色、默認視頻編碼碼率等。

通信場景設置推薦用於一對一或多人音視頻通話場景，直播場景設置推薦用於語音聊天室、小班課、主播 PK 等互動直播場景。

用戶角色

爲了便於管理用戶權限，在直播場景中實現更細節的權限控制，音視頻通話 2.0 支持在直播場景中設置用戶角色。用戶角色可設置爲主播（broadcastor）或觀衆（audience）。

• 直播場景中，用戶默認角色爲主播，可以發送音視頻流、配置推流任務等。通過方法 setClientRole 可切換用戶角色，切換爲觀衆後，只能接收音視頻流。
• 通話場景中，用戶默認角色爲主播。不支持切換用戶角色爲觀衆。

QoS 策略

直播場景和通信場景下的默認 QoS 策略不同，主要表現在以下方面。

• 直播場景。在直播場景下，NERTC SDK 的 QoS 策略控制側重於保證畫質清晰度。因此在默認情況下，如果分辨率和幀率相同，直播場景的碼率相較於通信場景更高。在弱網環境下會有一定延時。
• 通信場景。在通信場景下，NERTC SDK 的 QoS 策略控制側重於保證音視頻通話的實時性，最大程度上保證低時延。在弱網環境下會降低音質、畫質來保證音視頻通話流暢。

SDK 支持的 QoS 策略是什麼意思？

QoS: Quality of Service，服務質量。

當參與音視頻通話的用戶網絡較差時，SDK 會啓動 QoS 策略，自動調整收發數據的分辨率、碼率、幀率。 多人音視頻通話：A、B、C、D 通話。

• 對於視頻數據如果 A 上行發送網絡較差，或者 B、C、D 下行接收網絡較差，服務器都會回調給 A 並觸發 QoS，調整 A 發送的數據。
• 對於音頻數據如果 A 上行發送網絡較差，則服務器回調給 A 並觸發 QoS，調整 A 發送的數據；如果 B、C、D下行接收網絡較差，則服務器根據 B、C、D 的網絡情況重新編碼音頻數據發送給 B、C、D。

如何處理無聲問題？

無聲問題定義：通話過程中或通話全程，單方或多方聽不到聲音。

問題處理思路：如下圖所示，發送端與接收端之間有多個音頻處理與傳輸過程，建議通過採集、編碼、網絡傳輸、解碼、播放等各模塊對問題進行定位。

• 檢查採集及播放設備的使用權限。
• 檢查音視頻房間的連接狀態。
• 檢查發佈/訂閱接口調用。
• 檢查揚聲器/麥克風打開狀態。
• 檢查靜音接口調用。
• 檢查外接設備狀態，如藍牙耳機、音箱，如 Windows 設備需檢查驅動程序或使用系統自帶的設備自檢。

如以上內容均未存在問題，請聯繫網易雲信同事，雲信技術支持會及時提供技術服務幫助問題定位及解決。

如何處理回聲問題？

回聲問題定義：本端在音頻傳入時，揚聲器播放自己傳入的音頻。

問題處理思路：如下圖所示，發送端聽到本端的聲音，一般爲接收端回聲消除處理出現不可靠的情況導致，如在多人的場景下，需先定位明確的異常接收端。

• 隔離通話雙方設備的物理距離。
• 依次靜音房間內的用戶，判斷出現回聲的異常源。
• 異常源佩戴耳機的情況下可去除回聲。
• 提供異常源的設備具體信息包含 SDK 客戶端日誌。

請將收集的異常源信息提供給雲信技術支持，雲信技術支持會及時反饋異常處理進度及結果，該過程一般無需進行 SDK 替換。

三、技術加餐

網易智企發佈“易+”開源計劃，網易會議組件正式開源

內容概述：網易智企發佈”易+”開源計劃，旗下融合通信雲服務專家網易雲信打響頭炮，正式開源網易會議組件，並將在第二季度開源低延時直播技術。

“易+”開源 | 網易會議開源之移動端篇

內容概述：網易會議組件源代碼已經上傳至 GitHub，該項目由網易雲信團隊自研，結合網易雲信系統相關通訊功能、實時音視頻、即時消息、白板、直播等功能構建了一套會議系統，本文主要介紹了網易會議組件在網易會議移動端的實踐落地。

“易+”開源 | 網易會議開源之桌面端篇

內容概述：線上會議越來越普遍，很多企業希望能夠開發出一套自己的會議系統，方便工作和交流；網易雲信在通信領域深耕多年，基於自身能力打造了一款成熟的會議系統並將其開源，本文將介紹網易會議桌面端的相關內容。

技術乾貨 | RTC 音頻質量評價和保障

內容概述：會議、連麥、音視頻通話、在線教育、遠程醫療等實時互動場景對 RTC 音頻的質量提出了越來越高的要求，如何對 RTC 音頻的效果開展測試，通過構建客觀、標準、可重複的評價體系來保證好的音頻傳輸質量，也成爲目前比較緊急和重要的課題。

技術乾貨 | Gitlab-ci 替代 webhook 觸發Jenkins job

內容概述：網易雲信的 gitlab 服務器搭建在外網，Jenkins 服務器搭建在內網，因此 gitlab 沒辦法直接把 webhook 發送給 Jenkins，而 pipeline 的搭建採用第三方 relay 轉發的方式，但是這個 relay 經常“罷工”。本文根據網易雲信的落地實踐，詳細介紹瞭如何藉助 Gitlab-ci 替代 webhook 觸發 Jenkins job。

技術乾貨 | SQLite 簡介

內容概述：SQLite 是世界上使用最廣泛的數據庫引擎。SQLite 內置於所有手機和大多數計算機中，並捆綁在人們每天使用的無數其他應用程序中。本文主要介紹了 SQLite 的相關特性。

2週年福利 | 20萬字《網易智企技術合輯》重磅發佈！

內容概述：「網易智企技術+」即將迎來 2 週歲生日，網易智企精心挑選 51 篇技術文章，集結成這份 20 萬字的《網易智企技術合輯》，送給每一位開發者！

​