世界实时：“卷”到海外！教你实现海外语聊社交

• 2023-02-11 08:07:20 来源：腾讯云

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

(资料图)

什么是语聊社交？

● 主要特点

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

● 场景玩法

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

1）1V1语聊房

1V1语聊常见的应用场景有亲密聊、陪聊、语音交友等，大部分社交类App都上线了1V1语聊功能，分为免费和付费陪聊两种玩法。

2）多人语聊房

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

3）语音电台

语音电台是目前很多社交App的玩法，在语音电台中，会有主播单人直播或主持人和几名固定陪聊嘉宾，同时播放背景音乐和音效，麦下观众可以赠送礼物上麦，参与语音互动。

4）KTV语聊房

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

如何搭建语聊社交应用？

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

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

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

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

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

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

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

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

1）房间管理

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

● 技术架构

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

● 具体实现

在房间管理实现中会区分不同的角色分为房主、听众2个角色。

角色	描述	区别
房主	房间最高权限的拥有者，可以创建或者销毁房间	● 角色必须为主播● 创建或者销毁业务房间/IM群组/TRTC房间
听众	房间的参与者，也可以上麦变成主播	● 角色可以为观众/主播● 进退房间

不同角色的基本实现流程如下：

房主

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接口开启语音推流和拉流，所以在整个麦位管理中，必须是由 业务侧麦位模块（管理服务/列表服务）、即时通信IM模块（SDK/后台）、TRTC 模块（SDK/后台）三大模块进行组合实现的，然而正因为用户上麦/下麦经过的模块较多，任意模块与其他模块出现状态不统一的情况，都会“幽灵麦”，关于“幽灵麦”后续章节会展开详细介绍，所以每个模块都需要按照一定的流程正确进行。具体的架构流程如下图所示：

● 具体实现

在麦位管理实现中会区分不同的角色分为房主、听众2个角色。

角色	描述	区别
房主	麦位最高权限者，负责所有麦位的管理，房主退房后会自动解散所有麦位	● 角色必须为主播● 进房主动上麦● 同意/拒绝上麦申请● 抱人上/下麦● 麦位声音的静音/解禁● 麦位的封禁/解禁
听众	房间内麦位参与者，可以上下麦互动	● 角色可以为观众/主播● 申请上/下麦麦

不同角色的基本实现流程如下：

房主

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房间订阅拉流：通常小规模语聊房场景可以选择纯 TRTC 流接入方案，技术复杂度更低，亦可体验到更好的实时互动特性。

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

● 具体实现

1）RTC 流订阅模式

通常小规模语聊房场景可以选择纯 TRTC 流接入方案，技术复杂度更低，亦可体验到更好的实时互动特性。如下图所示，从麦上用户和麦下观众两个角色展示了一种最经典的实时互动语聊房的推拉流架构方案。

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

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

● 手动订阅：在用户进入房间后，需要手动调用 startRemoteView 启动视频流的订阅和解码，需要手动调用 muteRemoteAudio 启动音频的播放。

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

2）CDN 流拉取方案

CDN 直播观看，也叫 “CDN 旁路直播”，由于 TRTC 采用 UDP 协议进行传输音视频数据，而标准直播 CDN 则采用的 RTMP\HLS\FLV 等协议进行数据传输，所以需要将 TRTC 中的音视频数据旁路到直播 CDN 中，才能在让观众通过直播 CDN 观看。TRTC 的低延时观看能力，单房间支持的最大人数上限为10万人。CDN 观看虽然延迟要高一些，但支持10万人以上的并发观看，且 CDN 的计费价格更加便宜。

● 拉流方案对比

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

拉流方案	技术难度	费用成本	观看效果	人数限制	应用场景
观众拉 RTC 单流	简单	中等	低延迟	10万	互动游戏房等
观众拉 RTC 混流	复杂	中等	低延迟	10万	KTV语聊房等
观众拉 CDN 单流	中等	较低	中高延迟	无限制	强自定义布局
观众拉 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还支持在通话过程中动态调整音频质量，以便让用户在不同网络环境下均能拥有良好的听感体验。

音质模式	音质参数	音质说明
人声模式	采样率：16k；单声道；编码码率：16kbps	具备最强的网络抗性，在弱网环境下流畅度最佳
默认模式	采样率：48k；单声道；编码码率：50kbps	对音乐的还原度比人声模式要好，同时传输数据量比音乐模式要低很多
音乐模式	采样率：48k；全频带立体声；编码码率：128kbps	音频传输的数据量很大，适合需要高保真传输音乐的场景

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 = 1;trtcStreamEncoderParam.audioEncodedKbps = 50;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("uid", mUserId);                        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 端直接计算。

步骤三：服务端下发给客户端用于TRTC进房

如下图所示，当您的服务器计算好 PrivateMapKey 之后，就可以下发给您的 App，SDK 会在进房和上麦两个时刻校验 PrivateMapKey。

2）实时检测幽灵麦用户

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

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

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

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

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

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

// 启用音量大小提示mTRTCCloud.enableAudioVolumeEvaluation(300);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，强行将幽灵麦用户从房间内踢出，并配合高级权限控制，从而确保该用户无法再次进入房间。

● 安全合规

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

总结与展望

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

标签： 实时音视频 即时通信

推荐阅读

猜您喜欢