來(lái)源：騰訊云

導(dǎo)讀｜隨著互聯(lián)網(wǎng)出海的熱潮襲來(lái)，語(yǔ)聊社交出海再度掀起新一輪風(fēng)口，國(guó)內(nèi)外基于語(yǔ)音聊天室的社交APP如雨后春筍般涌現(xiàn)出來(lái)。然而隨著國(guó)內(nèi)同質(zhì)化競(jìng)爭(zhēng)加劇，以及相關(guān)監(jiān)管政策趨嚴(yán)，大量國(guó)內(nèi)團(tuán)隊(duì)選擇出海分一杯羹。那么海外語(yǔ)聊社交場(chǎng)景有什么特點(diǎn)？其實(shí)現(xiàn)方案又與國(guó)內(nèi)有何不同？讀完本文，你將能夠理解并掌握基于騰訊云音視頻搭建語(yǔ)聊房的基本要素，以及海外語(yǔ)聊方案的具體實(shí)現(xiàn)和優(yōu)化思路。

什么是語(yǔ)聊社交？

● 主要特點(diǎn)

語(yǔ)聊社交的典型形態(tài)就是語(yǔ)聊房，語(yǔ)聊房是指在線語(yǔ)音連麥虛擬房間，每個(gè)房間設(shè)有 5-10 個(gè)麥位，主播和連麥觀眾在麥上聊天，其他觀眾可以進(jìn)入房間觀看。不同房型的麥位數(shù)量和房間內(nèi)最大觀眾數(shù)量不同。

● 場(chǎng)景玩法

在語(yǔ)聊房場(chǎng)景中，房主和幾名麥上用戶以語(yǔ)音的方式在線互動(dòng)，麥下觀眾不能發(fā)言，只能收聽(tīng)，通過(guò)贈(zèng)送禮物和聊天消息互動(dòng)。通常會(huì)設(shè)置不同的房間類型，以吸引具有相同愛(ài)好的用戶觀看互動(dòng)。語(yǔ)聊房比較常見(jiàn)的形式有1V1語(yǔ)聊房、多人語(yǔ)聊房、語(yǔ)音電臺(tái)、KTV語(yǔ)聊房。

(資料圖片)

1）1V1語(yǔ)聊房

1V1語(yǔ)聊常見(jiàn)的應(yīng)用場(chǎng)景有親密聊、陪聊、語(yǔ)音交友等，大部分社交類App都上線了1V1語(yǔ)聊功能，分為免費(fèi)和付費(fèi)陪聊兩種玩法。

2）多人語(yǔ)聊房

多人語(yǔ)聊房延伸出的玩法非常多，其中每種玩法都有所差別。除了多人純語(yǔ)聊，還有跟其他娛樂(lè)形式結(jié)合的玩法。比如在線會(huì)議、游戲開(kāi)黑、賽事直播、一起看電影等。

3）語(yǔ)音電臺(tái)

語(yǔ)音電臺(tái)是目前很多社交App的玩法，在語(yǔ)音電臺(tái)中，會(huì)有主播單人直播或主持人和幾名固定陪聊嘉賓，同時(shí)播放背景音樂(lè)和音效，麥下觀眾可以贈(zèng)送禮物上麥，參與語(yǔ)音互動(dòng)。

4）KTV語(yǔ)聊房

在KTV語(yǔ)聊房中，大家可以點(diǎn)歌、評(píng)論、猜歌、接唱等，主要分為排麥獨(dú)唱和實(shí)時(shí)合唱兩種模式。 排麥獨(dú)唱為一個(gè)人主唱，其他連麥用戶排隊(duì)等候輪唱。 實(shí)時(shí)合唱為多個(gè)人合唱，連麥用戶可以隨時(shí)申請(qǐng)加入合唱。

如何搭建語(yǔ)聊社交應(yīng)用？

通常一個(gè)完整的語(yǔ)聊社交應(yīng)用，根據(jù)功能的完整度，分為四個(gè)層級(jí)（基礎(chǔ)組件、功能層、應(yīng)用層、業(yè)務(wù)層），整體的架構(gòu)如下所示，接下來(lái)會(huì)逐個(gè)講解各層級(jí)的內(nèi)容，通過(guò)講解對(duì)完整語(yǔ)聊房的要素有比較完整的認(rèn)識(shí)。

● 基礎(chǔ)組件：是提供最基礎(chǔ)的能力，比如音頻互動(dòng)、文字交流、回放存儲(chǔ)等，該組件主要以SDK或者某一單獨(dú)的服務(wù)呈現(xiàn)，比如實(shí)時(shí)音視頻SDK、即時(shí)通信IM SDK、直播/點(diǎn)播服務(wù)、審核服務(wù)。

● 功能層：是基礎(chǔ)組件中能力的應(yīng)用，比如彈幕，則是使用到即時(shí)通信IM SDK中的文字交流的能力；還有麥位移動(dòng)，是指麥位列表中的某人的麥位進(jìn)行了移動(dòng)，也是借助了即時(shí)通信IM的信令的能力，將某人麥位變化的信息下發(fā)到房間內(nèi)。

● 業(yè)務(wù)層：是功能模塊的聚合，比如創(chuàng)建房間、房間列表、進(jìn)/退房就是房間管理的聚合，上/下麥、麥位移動(dòng)、麥位禁言、鎖麥/解鎖麥 就是麥位管理的聚合。

● 應(yīng)用層：是最終呈現(xiàn)給用戶的業(yè)務(wù)形態(tài)，比如1v1語(yǔ)聊、多人語(yǔ)聊、語(yǔ)音電臺(tái)等都是根據(jù)業(yè)務(wù)層根據(jù)一定玩法形態(tài)展現(xiàn)給用戶的。

那么在整個(gè)技術(shù)架構(gòu)實(shí)現(xiàn)中，難度最大的是基礎(chǔ)組件實(shí)現(xiàn)，如果完全進(jìn)行自研的話，開(kāi)發(fā)成本高而且周期較長(zhǎng)，比如開(kāi)發(fā)實(shí)時(shí)音視頻組件，就需要具備專業(yè)音視頻底層技術(shù)的開(kāi)發(fā)能力，還需要處理一系列的機(jī)型適配、漏回音、無(wú)聲、節(jié)點(diǎn)部署、網(wǎng)絡(luò)互通等復(fù)雜的問(wèn)題，為此我們可以考慮使用云上提供的基礎(chǔ)組件，站在巨人的肩膀上，能大大的降低開(kāi)發(fā)成本，快速實(shí)現(xiàn)上線。

如何基于騰訊云實(shí)現(xiàn)語(yǔ)聊社交？

騰訊云提供了豐富的基礎(chǔ)組件，能滿足實(shí)現(xiàn)語(yǔ)聊房所需的基礎(chǔ)組件，接下來(lái)將基于騰訊云提供的基礎(chǔ)組件，對(duì)語(yǔ)聊房架構(gòu)實(shí)現(xiàn)進(jìn)行詳細(xì)的講解，將從核心業(yè)務(wù)模塊中的房間管理、麥位管理、音視頻流管理，錄制與審核管理，貫穿所其核心功能進(jìn)行逐個(gè)講解。

1）房間管理

語(yǔ)聊社交主要是在一個(gè)個(gè)房間內(nèi)進(jìn)行語(yǔ)音互動(dòng)的，創(chuàng)建房間的用戶是為主播，其他進(jìn)入同一個(gè)房間的用戶為觀眾。房間管理主要是負(fù)責(zé)對(duì)一個(gè)個(gè)房間進(jìn)行管理，主要功能包括對(duì)房間的創(chuàng)建、銷毀、加入、退出。

● 技術(shù)架構(gòu)

在房間管理的實(shí)現(xiàn)中，主要有房間列表、房間創(chuàng)建/銷毀/進(jìn)入/退出的功能，功能看似比較簡(jiǎn)單，是否由業(yè)務(wù)側(cè)自己完全實(shí)現(xiàn)就可以了呢？答案是否定的，因?yàn)榉块g內(nèi)使用的其他功能，比如消息發(fā)送收發(fā)/信令收發(fā)、音頻流的收發(fā)，都是使用到了即時(shí)通信IM與TRTC的能力，這兩個(gè)組件都是基于房間進(jìn)行的，所以還需實(shí)現(xiàn)即時(shí)通信IM和TRTC的房間創(chuàng)建/銷毀/進(jìn)入/退出。但既然通信IM和TRTC都是有房間管理，是否直接基于這兩個(gè)基礎(chǔ)組件快速實(shí)現(xiàn)呢？答案也是否定的，因?yàn)榉块g中的業(yè)務(wù)側(cè)詳細(xì)信息，比如鏈路情況、禮物列表，主播頭像等信息和房間列表功能，即時(shí)通信IM和TRTC都不提供這樣的功能的，所以在整個(gè)房間管理中，必須是由 業(yè)務(wù)側(cè)房間模塊（管理服務(wù)/列表服務(wù)）、即時(shí)通信IM模塊（SDK/后臺(tái)）、TRTC 模塊（SDK/后臺(tái)）三大模塊進(jìn)行組合實(shí)現(xiàn)的。具體的架構(gòu)流程如下圖所示：

● 具體實(shí)現(xiàn)

在房間管理實(shí)現(xiàn)中會(huì)區(qū)分不同的角色分為房主、聽(tīng)眾2個(gè)角色。

不同角色的基本實(shí)現(xiàn)流程如下：

房主

1. 通過(guò)業(yè)務(wù)接口創(chuàng)建對(duì)應(yīng)的房間

2. 創(chuàng)建IM群組

3. 進(jìn)入業(yè)務(wù)房間/IM房間/TRTC房間，與其他人互動(dòng)

4. 退出IM房間/TRTC房間/業(yè)務(wù)房間

5. 銷毀IM群組

聽(tīng)眾

1. 獲取房間列表

2. 進(jìn)入業(yè)務(wù)房間/IM群組/TRTC房間，與其他人互動(dòng)

3. 退出IM群組/TRTC房間/業(yè)務(wù)房間

● API時(shí)序

以下將結(jié)合騰訊云 即時(shí)通信IM SDK 與實(shí)時(shí)音視頻產(chǎn)品TRTC SDK來(lái)講述整個(gè)房間管理的API調(diào)用細(xì)節(jié)，圖中IM SDK為V2TIMManager，TRTC SDK為T(mén)RTCCloud。

房主API調(diào)用時(shí)序：

聽(tīng)眾API調(diào)用時(shí)序：

2）麥位管理

語(yǔ)聊社交房?jī)?nèi)的麥位一般都是有序且有限的，比如房間聽(tīng)眾上麥一般需要經(jīng)得房主的同意有序的上麥，并且房間內(nèi)的麥位都是 5-10 個(gè)麥位之間。麥位管理主要負(fù)責(zé)根據(jù)業(yè)務(wù)場(chǎng)景定義房間內(nèi)的麥位數(shù)量，以及當(dāng)前房間所有麥位的狀態(tài)管理。麥位管理主要包含的功能：上/下麥、換麥、鎖麥位、邀請(qǐng)上麥、麥位禁言等。

● 技術(shù)架構(gòu)

在麥位管理的實(shí)現(xiàn)中，主要有抱人上麥、踢人下麥、麥位禁言、麥位移動(dòng)、麥位靜音的功能，首先需要業(yè)務(wù)后臺(tái)維護(hù)一套用戶麥位列表狀態(tài)的信息，即為業(yè)務(wù)麥位服務(wù)，而在用戶上麥/下麥的時(shí)候，就需要即時(shí)通訊IM能力，將用戶上下麥與房主同意的相關(guān)信令下發(fā)到客戶端，然后在用戶進(jìn)行語(yǔ)音互動(dòng)交流的時(shí)候，就需要TRTC實(shí)時(shí)音視頻的能力，調(diào)用TRTC接口開(kāi)啟語(yǔ)音推流和拉流，所以在整個(gè)麥位管理中，必須是由 業(yè)務(wù)側(cè)麥位模塊（管理服務(wù)/列表服務(wù)）、即時(shí)通信IM模塊（SDK/后臺(tái)）、TRTC 模塊（SDK/后臺(tái)）三大模塊進(jìn)行組合實(shí)現(xiàn)的，然而正因?yàn)橛脩羯消?下麥經(jīng)過(guò)的模塊較多，任意模塊與其他模塊出現(xiàn)狀態(tài)不統(tǒng)一的情況，都會(huì)“幽靈麥”，關(guān)于“幽靈麥”后續(xù)章節(jié)會(huì)展開(kāi)詳細(xì)介紹，所以每個(gè)模塊都需要按照一定的流程正確進(jìn)行。具體的架構(gòu)流程如下圖所示：

● 具體實(shí)現(xiàn)

在麥位管理實(shí)現(xiàn)中會(huì)區(qū)分不同的角色分為房主、聽(tīng)眾2個(gè)角色。

不同角色的基本實(shí)現(xiàn)流程如下：

房主

1. 房主創(chuàng)建并加入房間；

2. 根據(jù)房間屬性獲取到麥位列表，并主動(dòng)上麥；

3. 聽(tīng)眾上麥有兩種方式，一種是聽(tīng)眾主動(dòng)申請(qǐng)上麥，房主同意，另外一種是房主主動(dòng)邀請(qǐng)聽(tīng)眾上麥，聽(tīng)眾同意；

4. 聽(tīng)眾上麥后，麥位上其他的人進(jìn)行互動(dòng)；

5. 聽(tīng)眾下麥有兩種方式，一種是聽(tīng)眾主動(dòng)下麥，另外一種是房主主動(dòng)將聽(tīng)眾抱下麥；

6. 房主退出并銷毀房間；

聽(tīng)眾

1. 聽(tīng)眾進(jìn)入房間；

2. 聽(tīng)眾獲取麥位列表；

3. 聽(tīng)眾申請(qǐng)上麥，房主同意后，將上麥與麥上其他主播互動(dòng)；

4. 聽(tīng)眾退出房間；

● API時(shí)序

以下將結(jié)合騰訊云 即時(shí)通信IM SDK與實(shí)時(shí)音視頻產(chǎn)品TRTC SDK來(lái)講述整個(gè)麥位管理的API調(diào)用細(xì)節(jié)，圖中IM SDK為V2TIMManager，TRTC SDK為T(mén)RTCCloud。

3）音頻流管理

音頻流管理是將房間內(nèi)TRTC SDK采集到的房主/主播的聲音，經(jīng)過(guò)網(wǎng)絡(luò)傳輸后，再拉流并播放給聽(tīng)眾，拉流有兩種方案：TRTC房間訂閱拉流和CDN 直播拉流。

● 技術(shù)架構(gòu)

1） TRTC房間訂閱拉流：通常小規(guī)模語(yǔ)聊房場(chǎng)景可以選擇純 TRTC 流接入方案，技術(shù)復(fù)雜度更低，亦可體驗(yàn)到更好的實(shí)時(shí)互動(dòng)特性。

2） CDN 直播拉流：由于 TRTC 采用 UDP 協(xié)議進(jìn)行傳輸音視頻數(shù)據(jù)，而標(biāo)準(zhǔn)直播 CDN 則采用的 RTMP\HLS\FLV 等協(xié)議進(jìn)行數(shù)據(jù)傳輸，所以需要將 TRTC 中的音視頻數(shù)據(jù)旁路到直播 CDN 中，才能在讓觀眾通過(guò)直播 CDN 觀看。

● 具體實(shí)現(xiàn)

1）RTC 流訂閱模式

通常小規(guī)模語(yǔ)聊房場(chǎng)景可以選擇純 TRTC 流接入方案，技術(shù)復(fù)雜度更低，亦可體驗(yàn)到更好的實(shí)時(shí)互動(dòng)特性。如下圖所示，從麥上用戶和麥下觀眾兩個(gè)角色展示了一種最經(jīng)典的實(shí)時(shí)互動(dòng)語(yǔ)聊房的推拉流架構(gòu)方案。

針對(duì)房間內(nèi)的實(shí)時(shí)流訂閱，TRTC 共有兩種訂閱模式可供選擇：自動(dòng)訂閱、手動(dòng)訂閱。

● 自動(dòng)訂閱：默認(rèn)模式，用戶在進(jìn)入房間后會(huì)立刻接收到該房間中的音視頻流，音頻會(huì)自動(dòng)播放，視頻會(huì)自動(dòng)開(kāi)始解碼；

● 手動(dòng)訂閱：在用戶進(jìn)入房間后，需要手動(dòng)調(diào)用 startRemoteView 啟動(dòng)視頻流的訂閱和解碼，需要手動(dòng)調(diào)用 muteRemoteAudio 啟動(dòng)音頻的播放。

在絕大多數(shù)場(chǎng)景下，用戶進(jìn)入房間后都會(huì)訂閱房間中所有主播的音視頻流，因此 TRTC 默認(rèn)采用了自動(dòng)訂閱模式，以求得最佳的“秒開(kāi)體驗(yàn)”。 而手動(dòng)訂閱模式則具備更好的靈活性和可定制性，用戶可以選擇性地訂閱音視頻流。

2）CDN 流拉取方案

CDN 直播觀看，也叫 “CDN 旁路直播”，由于 TRTC 采用 UDP 協(xié)議進(jìn)行傳輸音視頻數(shù)據(jù)，而標(biāo)準(zhǔn)直播 CDN 則采用的 RTMP\HLS\FLV 等協(xié)議進(jìn)行數(shù)據(jù)傳輸，所以需要將 TRTC 中的音視頻數(shù)據(jù)旁路到直播 CDN 中，才能在讓觀眾通過(guò)直播 CDN 觀看。TRTC 的低延時(shí)觀看能力，單房間支持的最大人數(shù)上限為10萬(wàn)人。CDN 觀看雖然延遲要高一些，但支持10萬(wàn)人以上的并發(fā)觀看，且 CDN 的計(jì)費(fèi)價(jià)格更加便宜。

● 拉流方案對(duì)比

下面將以四種拉流方案為例，從技術(shù)難度、費(fèi)用成本、觀看效果、人數(shù)限制、應(yīng)用場(chǎng)景等維度進(jìn)行對(duì)比分析：

4）錄制與審核管理

由于國(guó)內(nèi)外相關(guān)監(jiān)管平臺(tái)的要求，也是需要對(duì)語(yǔ)聊房音頻內(nèi)容進(jìn)行錄制存儲(chǔ)的，所以整個(gè)錄制與審核的架構(gòu)如下：

● 技術(shù)架構(gòu)

在錄制與審核管理中，主要有錄制、審核、用戶封禁的功能，首先需要業(yè)務(wù)后臺(tái)維護(hù)錄制相關(guān)的服務(wù)，用來(lái)管理主播的回看與調(diào)用TRTC后臺(tái)或者CDN開(kāi)啟錄制服務(wù)，然后在TRTC后臺(tái)/CDN收到業(yè)務(wù)側(cè)的服務(wù)后，將拉到的音視頻流數(shù)據(jù)保持在數(shù)據(jù)存儲(chǔ)中心，一般保存在COS中；另外業(yè)務(wù)后臺(tái)也是需要維護(hù)審核的服務(wù)，調(diào)用開(kāi)啟和接收天御的審核服務(wù)與告警，如果審核確認(rèn)是違規(guī)的內(nèi)容的話，則還需用到即時(shí)通信IM的能力，通過(guò)信令通知違規(guī)的用戶下麥。具體的架構(gòu)流程如下圖所示：

● 具體實(shí)現(xiàn)

1）云端錄制方案

云端錄制是通過(guò)TRTC的“啞終端”的方式進(jìn)到TRTC的房間內(nèi)拉流，能對(duì)房間內(nèi)的單流或者合流進(jìn)行錄制，整體的方案可以參考官網(wǎng)文檔，業(yè)務(wù)側(cè)通過(guò)調(diào)用相關(guān)的云端錄制接口，進(jìn)行錄制。

2）CDN錄制方案

CDN錄制是通過(guò)TRTC 后臺(tái)的混流轉(zhuǎn)碼接口/TRTC SDK混流轉(zhuǎn)推接口，通過(guò)混流轉(zhuǎn)碼轉(zhuǎn)推到騰訊云直播/第三方CDN，并通過(guò)騰訊云直播/第三方CDN的相關(guān)錄制服務(wù)，進(jìn)行錄制。

3） 天御審核方案

TRTC聯(lián)合T-Sec天御，提供了實(shí)時(shí)的音視頻內(nèi)容識(shí)別與告警服務(wù)，客戶在使用實(shí)時(shí)音視頻服務(wù)時(shí)，支持手動(dòng)或全局自動(dòng)發(fā)起策略進(jìn)行音視頻內(nèi)容的識(shí)別和告警：

● 手動(dòng)自定義審核：客戶只需要調(diào)用天御音視頻流接口即可實(shí)時(shí)檢測(cè)音視頻流中是否出現(xiàn)違規(guī)內(nèi)容，音視頻安全審核服務(wù)會(huì)通過(guò)回調(diào)把違規(guī)信息發(fā)送給客戶指定的回調(diào) URL。

● 全局自動(dòng)審核：客戶可指定審核策略和審核流類型，TRTC云端自動(dòng)幫忙完成應(yīng)用下所有房間內(nèi)的音視頻內(nèi)容審核，并通過(guò)回調(diào)把違規(guī)信息發(fā)送給客戶指定的回調(diào) URL，無(wú)需手動(dòng)發(fā)起審核。

具體實(shí)現(xiàn)接入方案可以參考官方文檔。

4）封禁方案

在內(nèi)容審核服務(wù)監(jiān)測(cè)發(fā)現(xiàn)有違規(guī)內(nèi)容，通過(guò)回調(diào)給業(yè)務(wù)審核的服務(wù)，業(yè)務(wù)審核服務(wù)通過(guò)機(jī)器/人工再審核的方式的確定是否是違規(guī)內(nèi)容，如果確認(rèn)是違規(guī)的內(nèi)容，則通過(guò)即時(shí)通信IM 后臺(tái)給違規(guī)的主播發(fā)送封禁的消息，主播在收到封禁消息時(shí)，停止音視頻流上行。

海外語(yǔ)聊技術(shù)特性與解決方案

在整個(gè)語(yǔ)聊技術(shù)架構(gòu)中，核心是實(shí)時(shí)音視頻通信能力。平穩(wěn)且流暢的用戶體驗(yàn)，是出海語(yǔ)聊應(yīng)用的制勝法寶。然而，海外紛繁復(fù)雜的基礎(chǔ)設(shè)施和網(wǎng)絡(luò)條件對(duì)于實(shí)時(shí)音視頻的挑戰(zhàn)是巨大的。針對(duì)海外語(yǔ)聊技術(shù)特性，我們總結(jié)了幾點(diǎn)常見(jiàn)問(wèn)題及其解決方案。

● 海外復(fù)雜網(wǎng)絡(luò)應(yīng)對(duì)

海外部分國(guó)家網(wǎng)絡(luò)基礎(chǔ)設(shè)施薄弱，網(wǎng)絡(luò)整體呈現(xiàn)帶寬低、延遲高、資費(fèi)貴等特性。對(duì)于海外復(fù)雜的網(wǎng)絡(luò)環(huán)境，騰訊云音視頻在全球網(wǎng)絡(luò)部署、QoS&QoE等方面均有針對(duì)性優(yōu)化措施。另外，我們還可以提供個(gè)性化的云控參數(shù)配置調(diào)整，歡迎聯(lián)系技術(shù)團(tuán)隊(duì)。

騰訊云音視頻在全球70多個(gè)國(guó)家和地區(qū)部署了超過(guò)2800個(gè)CDN加速節(jié)點(diǎn)，全網(wǎng)帶寬資源儲(chǔ)備高達(dá)200T+。音視頻QoS優(yōu)化針對(duì)海外入網(wǎng)環(huán)境，通過(guò)云端智能調(diào)控，確保極端網(wǎng)絡(luò)環(huán)境下引擎策略也可以配置化。云端智能流控引擎可以快速調(diào)整音頻幀長(zhǎng)、FEC比例、JitterBuffer大小等，確保適應(yīng)極端弱網(wǎng)環(huán)境，如限帶寬、高丟包、突發(fā)抖動(dòng)等場(chǎng)景。甚至針對(duì)部分地區(qū)UDP封禁的情況，可以降級(jí)至TCP實(shí)現(xiàn)互聯(lián)互通。

● 音頻帶寬優(yōu)化策略

1） 音頻質(zhì)量動(dòng)態(tài)配置

實(shí)時(shí)音視頻TRTC提供了三種精心校調(diào)好的音質(zhì)模式：人聲模式、默認(rèn)模式、音樂(lè)模式，用來(lái)滿足各種垂直場(chǎng)景下對(duì)音質(zhì)的差異化追求。不同的音質(zhì)模式側(cè)重點(diǎn)各不相同，實(shí)際場(chǎng)景中可以根據(jù)偏好（保音質(zhì)/保流暢）選擇配置。另外，TRTC還支持在通話過(guò)程中動(dòng)態(tài)調(diào)整音頻質(zhì)量，以便讓用戶在不同網(wǎng)絡(luò)環(huán)境下均能擁有良好的聽(tīng)感體驗(yàn)。

2）房間內(nèi)音頻混流

在語(yǔ)聊房場(chǎng)景中，一般都有8個(gè)聊天主播，按每人50kpbs音頻碼率計(jì)算的話，觀眾收聽(tīng)則需要400kpbs的下行帶寬的要求，往往在海外網(wǎng)絡(luò)比較差的環(huán)境中，幾乎無(wú)法正常收聽(tīng)。另外400kpbs的碼率對(duì)部分低端的手機(jī)性能挑戰(zhàn)也是很大，為此我們也通過(guò)音頻混流來(lái)對(duì)下行帶寬進(jìn)行了優(yōu)化。基于能量競(jìng)爭(zhēng)選路的房間內(nèi)音頻混流技術(shù)，在確保最終的產(chǎn)品能力和不混流對(duì)齊的情況下，能夠大幅降低用戶下行帶寬，提升弱網(wǎng)抗性。

音頻混流回推：選擇在房間內(nèi)把上行音頻混在一起之后，再推回房間，然后用戶拉流的時(shí)候只需拉一路，就能收到8個(gè)人的聲音，這可以直接把下行帶寬的占用從400k降到50k，對(duì)用戶下行網(wǎng)絡(luò)有極大的改善。示例代碼如下：

// 創(chuàng)建 TRTCPublishTarget 對(duì)象TRTCCloudDef.TRTCPublishTarget target = new TRTCCloudDef.TRTCPublishTarget();// 混流后回推到房間target.mode = TRTCCloudDef.TRTC_PublishMixStream_ToRoom;target.mixStreamIdentity.intRoomId = Integer.parseInt(mRoomId);// 混流機(jī)器人的 userid，不能和房間內(nèi)其他用戶的 userid 重復(fù)target.mixStreamIdentity.userId = mUserId + "_mix"; // 設(shè)置轉(zhuǎn)碼后的音頻流的編碼參數(shù)TRTCCloudDef.TRTCStreamEncoderParam trtcStreamEncoderParam = new TRTCCloudDef.TRTCStreamEncoderParam();trtcStreamEncoderParam.audioEncodedChannelNum = 1;trtcStreamEncoderParam.audioEncodedKbps = 50;trtcStreamEncoderParam.audioEncodedCodecType = 0;trtcStreamEncoderParam.audioEncodedSampleRate = 48000;// 設(shè)置音頻混流參數(shù)TRTCCloudDef.TRTCStreamMixingConfig trtcStreamMixingConfig = new TRTCCloudDef.TRTCStreamMixingConfig();// 支持填寫(xiě)空值，會(huì)自動(dòng)將所有主播的音頻混合輸出trtcStreamMixingConfig.audioMixUserList = null;// 發(fā)起混流轉(zhuǎn)推請(qǐng)求mTRTCCloud.startPublishMediaStream(target, trtcStreamEncoderParam, trtcStreamMixingConfig);

音頻混流下發(fā)單流音量：對(duì)于拉單流的用戶，能根據(jù)某個(gè)流的音量變化進(jìn)行音浪展示，而通過(guò)混流就很難分辨出來(lái)了。為此我們通過(guò)在云端混流時(shí)將發(fā)言人的userid和音量信息下發(fā)到SEI中，這樣在拉流時(shí)通過(guò)解析SEI信息，就能展示單流音量了。

private class TRTCCloudImplListener extends TRTCCloudListener {    public void onUserVoiceVolume(ArrayList userVolumes, int totalVolume) {        super.onUserVoiceVolume(userVolumes, totalVolume);        if (userVolumes != null && userVolumes.size() > 0) {            for (TRTCCloudDef.TRTCVolumeInfo user : userVolumes) {                // 可以設(shè)置適當(dāng)?shù)囊袅块撝?               if (user.volume > 10) {                    // 更新對(duì)應(yīng)麥位的音浪視圖                    updateSeatVoiceView();                    // 通過(guò) SEI 消息發(fā)送本地音量信息                    if (user.userId.equals(mUserId)) {                        JSONObject jsonObject = new JSONObject();                        jsonObject.put("uid", mUserId);                        jsonObject.put("volume", user.volume);                        jsonObject.().getBytes();                        mTRTCCloud.sendSEIMsg(jsonObject.().getBytes(), 1);                    }                }            }        }    }}

● 幽靈麥預(yù)防與檢測(cè)

幽靈麥，又稱炸麥或黑麥，是指不在麥上的用戶能說(shuō)話，并且其他用戶能聽(tīng)到他說(shuō)話的聲音。在海外用戶經(jīng)常會(huì)遇到，如果沒(méi)有合適的手段制止的話，會(huì)對(duì)其他用戶體驗(yàn)造成很大的影響。幽靈麥出現(xiàn)的根本原因是業(yè)務(wù)的麥位狀態(tài)跟 TRTC 房間的推拉流狀態(tài)不一致，可能存在以下幾種情況：

● 聽(tīng)眾下麥麥位列表更新了，但因IM群組屬性未更新，所以未及時(shí)調(diào)用TRTC切換角色為觀眾和關(guān)閉麥克風(fēng)，從而導(dǎo)致處于麥下卻還能發(fā)言；

● 聽(tīng)眾下麥麥位列表更新了，但調(diào)用了TRTC切換角色接口，因網(wǎng)絡(luò)原因失敗了，從而導(dǎo)致處于麥下卻還能發(fā)言；

● APP被暴力破解，從而導(dǎo)致usersig被黑客截獲，從而能進(jìn)到TRTC房間自由發(fā)言。

應(yīng)對(duì)策略主要分為：權(quán)限預(yù)防、實(shí)時(shí)檢測(cè)、踢出幽靈麥用戶。

1）權(quán)限預(yù)防

通過(guò)開(kāi)啟 TRTC 的高級(jí)權(quán)限控制可以更加細(xì)粒度地控制用戶進(jìn)房及上麥權(quán)限，從而防止幽靈麥現(xiàn)象的發(fā)生。開(kāi)啟高級(jí)權(quán)限控制后，TRTC 的后臺(tái)服務(wù)系統(tǒng)不僅會(huì)校驗(yàn) UserSig 這一個(gè)“進(jìn)房票據(jù)”，還會(huì)校驗(yàn)一個(gè)叫做 PrivateMapKey 的“權(quán)限票據(jù)”，權(quán)限票據(jù)中包含了一個(gè)加密后的 roomid 和一個(gè)加密后的“權(quán)限位列表”。

步驟一：在 TRTC 控制臺(tái)中開(kāi)啟高級(jí)權(quán)限控制

當(dāng)某一個(gè) SDKAppid 開(kāi)啟高級(jí)權(quán)限控制后，使用該 SDKAppid 的所有用戶都需要在 TRTCParams 中傳入 privateMapKey 參數(shù)才能成功進(jìn)房。

步驟二：在服務(wù)端集成計(jì)算 PrivateMapKey

由于客戶端非常容易被逆向破解，從而導(dǎo)致權(quán)限控制失效，因此 PrivateMapKey 只適合在服務(wù)端計(jì)算再返回給您的 App，絕不能在您的 App 端直接計(jì)算。

步驟三：服務(wù)端下發(fā)給客戶端用于TRTC進(jìn)房

如下圖所示，當(dāng)您的服務(wù)器計(jì)算好 PrivateMapKey 之后，就可以下發(fā)給您的 App，SDK 會(huì)在進(jìn)房和上麥兩個(gè)時(shí)刻校驗(yàn) PrivateMapKey。

2）實(shí)時(shí)檢測(cè)幽靈麥用戶

方法一：手動(dòng)訂閱拉流檢測(cè)幽靈麥

基本原理：通過(guò)手動(dòng)訂閱模式，在收到遠(yuǎn)端用戶發(fā)布音頻流的回調(diào)中額外校驗(yàn)業(yè)務(wù)麥位狀態(tài)，從而決策是否訂閱（播放）該用戶音頻流。

● onUserAudioAvailable(userId, true) 如果該用戶不在業(yè)務(wù)麥位列表中，則執(zhí)行 muteRemoteAudio(userId, true)，靜音該非法用戶音頻；

● onUserAudioAvailable(userId, true) 如果該用戶存在業(yè)務(wù)麥位列表中，則執(zhí)行 muteRemoteAudio(userId, false)，正常播放該用戶音頻。

方法二：音量大小回調(diào)檢測(cè)幽靈麥

基本原理：通過(guò) TRTC 音量大小回調(diào)，比對(duì)當(dāng)前上行音頻用戶列表和業(yè)務(wù)側(cè)麥位狀態(tài)列表，從而識(shí)別出不在麥上卻有上行音頻的幽靈麥。當(dāng)檢測(cè)出幽靈麥后，客戶端本地執(zhí)行靜音該用戶的遠(yuǎn)端音頻流，同時(shí)上報(bào)到服務(wù)端，服務(wù)端決策是否將該用戶踢出房間。示例代碼如下：

// 啟用音量大小提示mTRTCCloud.enableAudioVolumeEvaluation(300);private class TRTCCloudImplListener extends TRTCCloudListener {    // 每路音量大小的反饋回調(diào)    public void onUserVoiceVolume(ArrayList userVolumes, int totalVolume) {        super.onUserVoiceVolume(userVolumes, totalVolume);        for (TRTCCloudDef.TRTCVolumeInfo speaker : userVolumes) {            if (!speaker.userId.equals(mUserId) && speaker.volume > 0) {                ...                // 比對(duì)判斷當(dāng)前 speaker 是否在業(yè)務(wù)側(cè)麥上用戶列表中                // 若為否，判定當(dāng)前 speaker 為幽靈麥，執(zhí)行以下邏輯                ...                count++;                if (count >= 5) { // 增加容忍次數(shù)防止誤判                    // 主動(dòng)靜音幽靈麥用戶                    mTRTCCloud.muteRemoteAudio(speaker.userId, true);                    count = 0；                    ...                    // 上報(bào)幽靈麥用戶給服務(wù)端做相應(yīng)處理（踢人）                    ...                }            }        }    }}

3）踢出幽靈麥用戶

基本原理：通過(guò)TRTC后臺(tái)的移除用戶接口 RemoveUser，強(qiáng)行將幽靈麥用戶從房間內(nèi)踢出，并配合高級(jí)權(quán)限控制，從而確保該用戶無(wú)法再次進(jìn)入房間。

● 安全合規(guī)

騰訊云實(shí)時(shí)音視頻遵從不同國(guó)家和行業(yè)的合規(guī)性要求，除了保證所提供服務(wù)的安全性、合規(guī)性、可用性、保密性和隱私性之外，還可以滿足企業(yè)及其客戶的多項(xiàng)合規(guī)監(jiān)管需求。騰訊云實(shí)時(shí)音視頻還擁有一套獨(dú)立完整的國(guó)際站點(diǎn)，海外環(huán)境部署與國(guó)內(nèi)完全隔離，數(shù)據(jù)不會(huì)回傳國(guó)內(nèi)，以符合海外當(dāng)?shù)胤煞ㄒ?guī)。實(shí)時(shí)音視頻也通過(guò)了一些權(quán)威認(rèn)證，比如ISO27017/27018/27701/29151、CSA STAR、NIST CSF等。

總結(jié)與展望

本文主要介紹了語(yǔ)聊社交的常見(jiàn)場(chǎng)景與具體的實(shí)現(xiàn)方案，并且針對(duì)出海可能遇到的挑戰(zhàn)及其解決方案進(jìn)行詳細(xì)分享，相信隨著國(guó)內(nèi)越來(lái)越多的公司出海，還會(huì)繼續(xù)遇到更多新的挑戰(zhàn)，歡迎大家到評(píng)論區(qū)留言，一起討論。

標(biāo)簽： 實(shí)時(shí)音視頻 即時(shí)通信