导读｜随着互联网出海的热潮袭来，语聊社交出海再度掀起新一轮风口，国内外基于语音聊天室的社交APP如雨后春笋般涌现出来。然而随着国内同质化竞争加剧，大量国内团队选择出海分一杯羹。那么海外语聊社交场景有什么特点？其实现方案又与国内有何不同？读完本文，你将能够理解并掌握基于腾讯云音视频搭建语聊房的基本要素，以及海外语聊方案的具体实现和优化思路。

什么是语聊社交？

● 主要特点

语聊社交的典型形态就是语聊房，语聊房是指在线语音连麦虚拟房间，每个房间通常设有 5-10 个麦位，主播和连麦观众在麦上聊天，其他观众可以进入房间观看。不同房型的麦位数量和房间内可容纳最大观众数量不同。

【资料图】

● 场景玩法

在语聊房场景中，房主和几名麦上用户以语音的方式在线互动，麦下观众不能发言只能收听，通过赠送礼物和聊天消息互动。房间通常会设置不同的主题类型，以吸引具有相同爱好的用户观看互动。语聊房目前比较常见的形式有1V1语聊房、多人语聊房、电台语聊房、KTV语聊房。

1）1V1语聊房

1V1语聊房常见的应用场景有单聊、陪聊、语音匹配交友等，大部分社交类App都上线了1V1语聊功能，通常分为免费和付费两种模式。

2）多人语聊房

多人语聊房延伸出的玩法非常多，其中每种玩法都有所差别。除了多人纯语聊，还有跟其他娱乐形式结合的玩法。比如在线会议、游戏开黑、赛事直播、一起看电影等。

3）电台语聊房

在电台语聊房场景中，通常会有主播单人直播或主持人和几名陪聊嘉宾，同时播放背景音乐和音效，麦下观众可以赠送礼物，上麦参与语音互动。

4）KTV语聊房

在KTV语聊房场景中，大家可以点歌、接唱、合唱等，主要分为排麦独唱和实时合唱两种模式。 排麦独唱为一个人主唱，其他连麦用户排队等候轮唱。 实时合唱为多个人同时合唱，连麦用户可以随时申请加入合唱。

如何搭建语聊社交应用？

通常一个完整的语聊社交应用，根据功能的完整度，可以分为四个层级：基础组件、功能层、应用层、业务层。整体架构如下所示，接下来会逐个讲解各层级的内容，以对搭建语聊房的基本要素有个比较完整的认知。

● 基础组件：提供最基础的能力，比如音频互动、文字交流、回放存储等，该组件主要以SDK或者某一单独的服务呈现，比如实时音视频SDK、即时通信IM SDK、直播/点播服务、审核服务等。

● 功能层：基础组件中能力的应用，比如弹幕，就是使用到即时通信IM SDK中的文字交流的能力；还有麦位移动，是指麦位列表中的某人的麦位进行了变更，也是借助了即时通信IM的信令能力，将某人麦位变化的信息下发到房间内。

● 业务层：功能模块的聚合，比如创建房间、房间列表、进/退房就是房间管理的聚合；上/下麦、麦位移动、麦位禁言、锁麦/解锁麦就是麦位管理的聚合。

● 应用层：最终呈现给用户的业务形态，比如1V1语聊、多人语聊、语音电台等都是业务层根据一定玩法形态展现给用户的。

在整个语聊技术架构实现中，难度最大的是基础组件的实现。如果完全进行自研的话，开发成本高而且周期较长。比如开发实时音视频组件，就需要具备专业的音视频底层技术开发能力，还需要处理一系列的机型适配、漏回音、无声、节点部署、网络互通等复杂问题。为此我们可以考虑使用云上提供的基础组件，站在巨人的肩膀上，能够有效降低开发成本，实现快速上线。

如何基于腾讯云实现语聊社交？

腾讯云提供了丰富的基础组件，能满足实现语聊房所需的基础组件。接下来将基于腾讯云提供的基础组件，对语聊房架构实现进行详细的讲解，并从核心业务模块中的房间管理、麦位管理、音视频流管理，录制与审核，贯穿核心功能进行分析。

1）房间管理

语聊社交主要是在一个个房间内进行语音互动的，创建房间的用户是为主播，其他进入房间的用户为观众。房间管理主要负责对一个个房间进行管理，主要功能包括对房间的创建、销毁、加入、退出。

● 技术架构

在房间管理的实现中，主要有房间列表、房间创建/销毁/进入/退出的功能。功能看似比较简单，是否由业务侧自己完全实现就可以了呢？答案是否定的，因为房间内使用的其他功能，比如消息收发、信令收发、音频流收发，都使用到了即时通信IM与实时音视频TRTC的能力。既然IM和TRTC都有房间管理，是否直接基于这两个基础组件就能快速实现呢？答案也是否定的，因为房间中的业务侧信息，比如链路情况、礼物列表，主播头像等信息和房间列表等功能，IM和TRTC不直接提供此类功能，所以在整个房间管理中，必须由业务侧房间模块（管理服务/列表服务）、即时通信IM模块（SDK/后台）、TRTC模块（SDK/后台）三大模块进行组合实现。具体的架构流程如下图所示：

● 具体实现

在房间管理的实现中会区分不同的角色，主要分为房主、听众两种角色。

不同角色的具体实现流程如下：

房主

1. 通过业务侧接口创建相应的房间；

2. 创建IM群组；

3. 进入业务房间/IM群组/TRTC房间，与其他人进行互动；

4. 退出IM群组/TRTC房间/业务房间；

5. 销毁IM群组/业务房间。

听众

1. 获取房间列表；

2. 进入业务房间/IM群组/TRTC房间，与其他人进行互动；

3. 退出IM群组/TRTC房间/业务房间。

● API时序

下面将结合腾讯云即时通信IM SDK与实时音视频TRTC SDK来描述整个房间管理的API调用细节，图中IM SDK核心类为V2TIMManager，TRTC SDK核心类为TRTCCloud。

房主API调用时序：

听众API调用时序：

2）麦位管理

语聊房内的麦位一般都是有序且有限的，比如听众上麦一般需要经得房主的同意后有序上麦，并且房间内的麦位数量通常在 5-10个之间。麦位管理主要负责根据业务场景定义房间内的麦位数量，以及当前房间所有麦位的状态管理。麦位管理主要包含上/下麦、换麦、锁麦位、邀请上麦、麦位禁言等功能。

● 技术架构

在麦位管理的实现中，主要有抱人上麦、踢人下麦、麦位禁言、麦位移动、麦位静音等功能。首先需要业务后台维护一套用户麦位列表状态的信息，即为业务麦位服务，而在用户上麦/下麦的时候，则需要用到即时通信IM的能力，将用户上下麦与房主同意的相关信令下发到客户端。然后在用户进行语音互动交流的时候，则需要用到实时音视频TRTC的能力，调用TRTC SDK接口开启语音推拉流。所以在整个麦位管理中，必须是由业务侧麦位模块（管理服务/列表服务）、即时通信IM模块（SDK/后台）、TRTC 模块（SDK/后台）三大模块进行组合实现的。然而正因为用户上麦/下麦所用到的模块比较多，任意模块与其他模块出现状态不统一的时候，都会出现“幽灵麦”现象，关于“幽灵麦”后续章节会展开详细介绍。因此每个模块都需要按照一定的流程正确进行，具体的架构流程如下图所示：

● 具体实现

在麦位管理的实现中会区分不同的角色，主要分为房主、听众两种角色。

不同角色的具体实现流程如下：

房主

1. 房主创建并加入房间；

2. 根据房间属性获取到麦位列表，并主动上麦；

3. 听众上麦有两种方式，一种是听众主动申请上麦，房主同意，另外一种是房主邀请听众上麦，听众同意；

4. 听众上麦后，与麦位上的其他人进行互动；

5. 听众下麦有两种方式，一种是听众主动下麦，另外一种是房主将听众抱下麦；

6. 房主退出并销毁房间；

听众

1. 听众进入房间；

2. 听众获取麦位列表；

3. 听众申请上麦，房主同意后，将上麦与麦上其他主播互动；

4. 听众退出房间；

● API时序

以下将结合腾讯云即时通信IM SDK与实时音视频产品TRTC SDK来描述整个麦位管理的API调用细节，图中IM SDK核心类为V2TIMManager，TRTC SDK核心类为TRTCCloud。

3）音频流管理

音频流管理是将房间内TRTC SDK采集到的房主/主播的声音经过网络传输后，再拉流并播放给听众。其中拉流有两种方案：TRTC房间订阅拉流、转推CDN直播拉流。

● 技术架构

1） TRTC房间订阅拉流：通常小规模语聊房场景可以选择纯RTC流接入方案，技术复杂度更低，亦可体验到更好的实时互动特性；

2） 转推CDN直播拉流：由于TRTC采用UDP协议进行音视频数据的传输，而标准直播CDN则采用RTMP\HLS\FLV等协议进行数据传输，所以需要将TRTC的音视频数据旁路到直播CDN中，才能在让观众通过直播CDN拉流观看。

● 具体实现

1）RTC流订阅模式

纯RTC流接入方案易用性强，且具备最佳的实时互动性。如下图所示，以麦上用户和麦下观众两个角色展示了一种最经典的实时互动语聊房的推拉流方案架构。

针对房间内的实时流订阅，TRTC共有两种订阅模式可供选择：自动订阅、手动订阅。

● 自动订阅：默认模式，用户在进入房间后会立刻接收到该房间中的音频流，音频会自动播放；

● 手动订阅：用户进入房间后，需要手动调用muteRemoteAudio启动音频的播放。

在绝大多数场景下，用户进入房间后都会订阅房间中所有主播的音频流，因此TRTC默认采用了自动订阅模式，以求得最佳的“秒开体验”。 而手动订阅模式则具备更好的灵活性和可定制性，用户可以选择性地订阅音频流。

2）CDN流拉取方案

CDN直播观看，也叫 “CDN 旁路直播”。TRTC的低延时观看能力，单房间支持的最大人数上限为10万人。CDN观看虽然延迟要高一些，但支持10万人以上的并发观看，且CDN的计费价格相对便宜。

● 拉流方案对比

下面将以四种拉流方案为例，从技术难度、费用成本、观看效果、人数限制、应用场景等维度进行对比分析：

4）录制与审核管理

由于国内外相关监管政策的要求，有对语聊房音频内容进行录制存储的需求。录制与审核的相关介绍如下：

● 技术架构

在录制与审核管理中，主要有录制、审核、用户封禁等功能。首先需要业务后台维护录制相关的服务，用来管理主播的回看与调用TRTC后台或者CDN开启录制服务，然后在TRTC后台/CDN收到业务侧的服务后，将拉到的音视频流数据保持在数据存储中心，一般保存在COS中；另外业务后台也是需要维护审核的服务，调用开启和接收天御的审核服务与告警，如果审核确认是违规的内容的话，则还需用到即时通信IM的能力，通过信令通知违规的用户下麦。具体的架构流程如下图所示：

● 具体实现

1）云端录制方案

云端录制是通过TRTC的“哑终端”的方式进到TRTC的房间内拉流，能对房间内的单流或者合流进行录制，整体的方案可以参考官网文档，业务侧通过调用相关的云端录制接口，进行录制。

2）CDN录制方案

CDN录制是通过TRTC后台的混流转码接口/TRTC SDK混流转推接口，混流转码转推到腾讯云直播/第三方CDN，并通过腾讯云直播/第三方CDN的相关录制服务，进行录制。

3） 天御审核方案

TRTC联合T-Sec天御，提供了实时的音视频内容识别与告警服务，客户在使用实时音视频服务时，支持手动或全局自动发起策略进行音视频内容的识别和告警：

● 手动自定义审核：客户只需要调用天御音视频流接口即可实时检测音视频流中是否出现违规内容，音视频安全审核服务会通过回调把违规信息发送给客户指定的回调 URL；

● 全局自动审核：客户可指定审核策略和审核流类型，TRTC云端自动帮忙完成应用下所有房间内的音视频内容审核，并通过回调把违规信息发送给客户指定的回调 URL，无需手动发起审核。

具体实现接入方案可以参考官网文档。

4）封禁方案

在内容审核服务监测发现有违规内容的时候，通过回调给业务审核的服务，业务审核服务通过机器/人工再审核的方式的确定是否是违规内容，如果确认是违规的内容，则通过即时通信IM后台给违规的主播发送封禁消息，主播在收到封禁消息时，停止音视频流上行。

海外语聊技术特性与解决方案

在整个语聊技术架构中，核心是实时音视频通信能力。平稳且流畅的用户体验，是出海语聊应用的制胜法宝。然而，海外纷繁复杂的基础设施和网络条件对于实时音视频的挑战是巨大的。针对海外语聊技术特性，我们总结了几点常见问题及其解决方案。

● 海外复杂网络应对

海外部分国家网络基础设施薄弱，网络整体呈现带宽低、延迟高、资费贵等特性。对于海外复杂的网络环境，腾讯云音视频在全球网络部署、QoS&QoE等方面均有针对性优化措施。

腾讯云音视频在全球70多个国家和地区部署了超过2800个CDN加速节点，全网带宽资源储备高达200T+。音视频QoS优化针对海外入网环境，通过云端智能调控，确保极端网络环境下引擎策略也可以配置化。云端智能流控引擎可以快速调整音频帧长、FEC比例、JitterBuffer大小等，确保适应极端弱网环境，如限带宽、高丢包、突发抖动等场景。甚至针对部分地区UDP封禁的情况，可以降级至TCP实现互联互通。

● 音频带宽优化策略

1） 音频质量动态配置

实时音视频TRTC提供了三种精心校调好的音质模式：人声模式、默认模式、音乐模式，用来满足各种垂直场景下对音质的差异化追求。不同的音质模式侧重点各不相同，实际场景中可以根据偏好（保音质/保流畅）选择配置。另外，TRTC还支持在通话过程中动态调整音频质量，以便让用户在不同网络环境下均能拥有良好的听感体验。

2）房间内音频混流

在语聊房场景中，一般都有8个聊天主播，按每人50kpbs音频码率计算的话，观众收听则需要400kpbs的下行带宽的要求，往往在海外网络比较差的环境中，几乎无法正常收听。另外400kpbs的码率对部分低端的手机性能挑战也是很大，为此我们也通过音频混流来对下行带宽进行了优化。基于能量竞争选路的房间内音频混流技术，在确保最终的产品能力和不混流对齐的情况下，能够大幅降低用户下行带宽，提升弱网抗性。

音频混流回推：选择在房间内把上行音频混在一起之后，再推回房间，然后用户拉流的时候只需拉一路，就能收到8个人的声音，这可以直接把下行带宽的占用从400k降到50k，对用户下行网络有极大的改善。示例代码如下：

// 创建 TRTCPublishTarget 对象TRTCCloudDef.TRTCPublishTarget target = new TRTCCloudDef.TRTCPublishTarget();// 混流后回推到房间target.mode = TRTCCloudDef.TRTC_PublishMixStream_ToRoom;target.mixStreamIdentity.intRoomId = Integer.parseInt(mRoomId);// 混流机器人的 userid，不能和房间内其他用户的 userid 重复target.mixStreamIdentity.userId = mUserId + "_mix"; // 设置转码后的音频流的编码参数（可自定义）TRTCCloudDef.TRTCStreamEncoderParam trtcStreamEncoderParam = new TRTCCloudDef.TRTCStreamEncoderParam();trtcStreamEncoderParam.audioEncodedChannelNum = 2;trtcStreamEncoderParam.audioEncodedKbps = 64;trtcStreamEncoderParam.audioEncodedCodecType = 0;trtcStreamEncoderParam.audioEncodedSampleRate = 48000;// 设置音频混流参数TRTCCloudDef.TRTCStreamMixingConfig trtcStreamMixingConfig = new TRTCCloudDef.TRTCStreamMixingConfig();// 支持填写空值，会自动将所有主播的音频混合输出trtcStreamMixingConfig.audioMixUserList = null;// 发起混流转推请求mTRTCCloud.startPublishMediaStream(target, trtcStreamEncoderParam, trtcStreamMixingConfig);

音频混流下发单流音量：对于拉单流的用户，能根据某个流的音量变化进行音浪展示，而通过混流就很难分辨出来了。为此我们通过在云端混流时将发言人的userid和音量信息下发到SEI中，这样在拉流时通过解析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) {                // 可以设置适当的音量阈值                if (user.volume > 10) {                    // 更新对应麦位的音浪视图                    updateSeatVoiceView();                    // 通过 SEI 消息发送本地音量信息                    if (user.userId.equals(mUserId)) {                        JSONObject jsonObject = new JSONObject();                        jsonObject.put("userid", user.userId);                        jsonObject.put("volume", user.volume);                        jsonObject.().getBytes();                        mTRTCCloud.sendSEIMsg(jsonObject.().getBytes(), 1);                    }                }            }        }    }}

● 幽灵麦预防与检测

幽灵麦，又称炸麦或黑麦，是指不在麦上的用户能说话，并且其他用户能听到其说话的声音。在海外用户经常会遇到，如果没有合适的手段制止的话，会对其他用户体验造成很大的影响。幽灵麦出现的根本原因是业务的麦位状态跟TRTC房间的推拉流状态不一致，可能存在以下几种情况：

● 听众下麦麦位列表更新了，但因IM群组属性未更新，所以未及时调用TRTC切换角色为观众和关闭麦克风，从而导致处于麦下却还能发言；

● 听众下麦麦位列表更新了，但调用了TRTC切换角色接口，因网络原因失败了，从而导致处于麦下却还能发言；

● APP被暴力破解，从而导致usersig被黑客截获，从而能进到TRTC房间自由发言。

应对策略可以分为几个步骤：权限预防、实时检测、踢出幽灵麦用户。

1）权限预防

通过开启TRTC的高级权限控制可以更加细粒度地控制用户进房及上麦权限，从而防止幽灵麦现象的发生。开启高级权限控制后，TRTC的后台服务系统不仅会校验UserSig这一个“进房票据”，还会校验一个叫做PrivateMapKey的“权限票据”，权限票据中包含了一个加密后的roomId和一个加密后的“权限位列表”。

步骤一：在TRTC控制台中开启高级权限控制

当某一个SDKAppid开启高级权限控制后，使用该SDKAppId的所有用户都需要在TRTCParams中传入 privateMapKey 参数才能成功进房。

步骤二：在服务端集成计算PrivateMapKey

由于客户端非常容易被逆向破解，从而导致权限控制失效，因此PrivateMapKey只适合在服务端计算再返回给您的App，绝不能在您的App端直接计算。

步骤三：服务端下发鉴权参数给客户端

如下图所示，当您的服务器计算好PrivateMapKey之后，就可以在需要的时候下发给您的客户端，SDK会在进房、上麦两个时刻校验PrivateMapKey，你可以在此时控制用户权限。

2）实时检测幽灵麦用户

方法一：手动订阅拉流检测幽灵麦

基本原理：通过手动订阅模式，在收到远端用户发布音频流的回调中额外校验业务麦位状态，从而决策是否订阅（播放）该用户音频流。

● onUserAudioAvailable(userId, true) 如果该用户不在业务麦位列表中，则执行 muteRemoteAudio(userId, true)，静音该非法用户音频；

● onUserAudioAvailable(userId, true) 如果该用户存在业务麦位列表中，则执行 muteRemoteAudio(userId, false)，正常播放该用户音频。

方法二：音量大小回调检测幽灵麦

基本原理：通过 TRTC 音量大小回调，比对当前上行音频用户列表和业务侧麦位状态列表，从而识别出不在麦上却有上行音频的幽灵麦。当检测出幽灵麦后，客户端本地执行静音该用户的远端音频流，同时上报到服务端，服务端决策是否将该用户踢出房间。示例代码如下：

// 启用音量大小提示，可自定义回调间隔mTRTCCloud.enableAudioVolumeEvaluation(500);private class TRTCCloudImplListener extends TRTCCloudListener {    // 每路音量大小的反馈回调    public void onUserVoiceVolume(ArrayList userVolumes, int totalVolume) {        super.onUserVoiceVolume(userVolumes, totalVolume);        for (TRTCCloudDef.TRTCVolumeInfo speaker : userVolumes) {            if (!speaker.userId.equals(mUserId) && speaker.volume > 0) {                ...                // 比对判断当前 speaker 是否在业务侧麦上用户列表中                // 若为否，判定当前 speaker 为幽灵麦，执行以下逻辑                ...                count++;                if (count >= 5) { // 增加容忍次数防止误判                    // 主动静音幽灵麦用户                    mTRTCCloud.muteRemoteAudio(speaker.userId, true);                    count = 0；                    ...                    // 上报幽灵麦用户给服务端做相应处理（踢人）                    ...                }            }        }    }}

3）踢出幽灵麦用户

基本原理：通过TRTC后台的移除用户接口 RemoveUser，强行将幽灵麦用户从房间内踢出，并配合高级权限控制，从而确保该用户无法再次进入房间。

● 安全合规

腾讯云实时音视频遵从不同国家和行业的合规性要求，除了保证所提供服务的安全性、合规性、可用性、保密性和隐私性之外，还可以满足企业及其客户的多项合规监管需求。腾讯云实时音视频还拥有一套独立完整的国际站点，海外环境部署与国内完全隔离，数据不会回传国内，符合海外法律法规。此外，腾讯云也通过了70项全球权威认证，例如ISO 27017/27018/27701/29151、CSA STAR、NIST CSF等。

总结与展望

本文主要介绍了语聊社交的常见场景与具体的实现方案，并且针对出海可能遇到的挑战及其解决方案进行详细分享，相信随着国内越来越多的公司出海，还会继续遇到更多新的挑战，欢迎大家到评论区留言，一起讨论。