架构集一---语音连麦聊天室实现方案分析

前言

语音聊天基本是社交软件必备的功能，语音相比文字图片更丰富，比视频又更简便，是天然的社交工具。除了单纯的1对1语音或视频聊天，在实时音视频技术支持下，很多 APP 已经延伸出非常多的玩法。

目前比较火的语聊房又分为语音电台、语音游戏、私人聊天房、多人语聊房、KTV 语聊房等细分的场景，延伸出去还有更多的形态，目前比较火的音遇 APP ，就是语聊房的最新形态。

语音电台是目前很多社交APP的玩法。主播可以在直播间中给听众讲故事、脱口秀、唱歌，内容形式不胜枚举，观众也可以申请上麦与主播聊天互动（一般需要打赏或者付费后）。主要实现的功能就是语音连麦。在聊的基础上，加上了背景伴奏音以及通过消息系统来实现的文字消息功能。看似简单，但是这种模式用户的活跃度较高，付费意愿也更高，一些优质的语音社交平台能达到很高的流水。

语音游戏，它也是语音聊天室的常见应用场景。从去年大热的狼人杀、剧本杀，再到王者荣耀、吃鸡等游戏中的语音开黑，越来越多的游戏开始为玩家创建实时互动的场景，同时实时的音视频对话也成为了部分游戏类型的主要功能。功能上与语音直播相似，只是在这个频道中，上麦下麦的玩法逻辑有所不同。

如何实现语音聊天室

以上只是包含了语音聊天的部分场景而已，综上来看，语音聊天室需要满足的主要功能包括：

• 支持多人参与的语音聊天

• 支持本地混音

• 多种连麦模式

要实现一个具备以上功能的语音聊天室，大致可以分为三步：实现语音连麦、支持本地混音，多种连麦模式的设计。

首先是实现语音连麦。如果要通过自研的方法实现，难度会比较大：

• 需要自己部署服务器做好高并发处理；

• 需要对编解码器优化来解决回声、噪声问题；

• 需要有成熟的技术方案降低延迟、提高音质；

• 需要兼容各种网络环境下的用户体验等。

总体来讲，就是需要解决设备端、网络中的语音连麦稳定低延时问题与可用性问题。

下图为语音聊天室场景化方案的架构图与实现思路：

 

实现语音连麦

通常，观众上麦请求、主播通过上麦申请等一系列操作都是通过消息服务来完成的。任意模式下，进入房间后可以允许听众上麦，用户发出上麦申请，房主同意后，听众可上麦，角色由听众变为了主播。主播要遵循房间模式来实现自己的功能。

会议属性：在语音聊天室 Demo 中，抢麦、主持、自由麦等模式均是通过会议属性实现的，包括各个模式中的上麦者，也是会议属性实现的。当会议属性发生更改时，会广播给房间内所有人。

---

创建语聊房间

首先创建者通过 AppServer 创建并加入语聊房间，IM 聊天室。在房主通过 AppServer 创建并进入房间后，通过音视频提供的会议属性接口修改房间的会议属性，从而自定义一些房间的属性。

我们可以通过一张图，来了解创建语聊房间接口的调用逻辑：

 

加入语聊房间

当房主创建语聊房间后，其他人通过 AppServer 看到有房间被创建，可以输入房间密码加入到房间中。当加入房间后，就会收到会议属性变更的通知，从而得到会议属性。

我们可以通过一张图，来了解观众进入语聊房间接口的调用逻辑：

上图中每步涉及到的 iOS/Android 接口如下，其中部分调用到了 AppServer 的接口，开发者需要自己实现 AppServer 功能。

上麦

已在语聊房间的观众通过 IMServer 发送 message 向房主发起上麦请求，房主同意后，通过 MediaServer 改变会议属性，将观众上麦成为主播，成为主播后就能说话进行推流。房间内其他的人都能收到推流通知并进行订阅。

我们可以通过一张图，来了解观众上麦接口的调用逻辑：

 

下麦、销毁房间

当主播在麦上时，如果想要下麦，同样通过 IMServer 向房主发送 message 发起下麦请求，这里无需房主同意，默认直接下麦。若房主主动将主播下麦，则没有之前这步，房主直接通过 MediaServer 改变会议属性，将主播下麦成为观众，主播成为观众后就停止推流。房主调用 AppServer 销毁房间，进而销毁conference、chatroom。

我们可以通过一张图，来了解主播下麦、房主销毁语聊房间接口的调用逻辑：

 

本地混音

本地混音是指将几种不同的声音在发送端混在一起。例如常见的K歌场景，就需要将人唱歌的声音和歌曲的背景音乐进行混音处理。所以，在实现了基本的连麦功能后，我们还需要增加背景音乐的混音、播放控制。

在这里，主播可以在自己的客户端上选择要播放的音乐，然后通过 SDK 的 startAudioMixing 接口在本地与主播语音混音后播放给连麦听众和普通听众。并且连麦语音与背景音乐播放互不干扰，帮助用户活跃房间内的气氛。在默认情况下，背景音乐是循环播放的。

有些开发者希望以语音社交切入泛娱乐市场，也有一些市场上的视频社交玩家，希望加入语音聊天室，来进一步拓展市场版图。由于该场景方案是基于环信音视频 SDK 实现，可以同时满足以上两种需求。

多种连麦模式

在语音聊天室 Demo 中，提供了三种模式，自由麦模式、主持模式、抢麦模式（开发者还可以基于此扩展更多模式玩法）。这三种模式就是通过会议属性区分的，当用户进入房间后，就可以知道当前的房间属于哪种模式。

主持模式

在语音电台类的直播间，一般都会设有一个主持人来管理连麦，以维持连麦的秩序，可支持“抱麦”、“连麦”、“禁麦”、“轮麦”、“排麦”等能力的“麦序管理”功能，将让用户在游戏的过程中更“嗨”，更“带感”。由于这种产品模式，用户的活跃度较高，付费意愿也更高，市场上如伴伴、吱呀、音泡等不少以语音电台为核心社交产品都获得了不错的流水。

总结来说，语音电台的连麦管理就是一种主持人模式，这种模式由于人人都想和主播连麦，出风头表现，必定会需要一定的门槛，即送礼可上麦。该模式其实就是在语音聊天室的基础上的一种“主持”玩法。环信语聊解决方案，针对“主持”玩法的实现已经为开发者给出了方案。

主持玩法是目前语音连麦聊天室中必备的玩法之一。通过房主的主持，大家可以有序的进行发言，更好的组织聊天室的互动场景。 在主持模式，由房主指定谁可以发言，被指定的主播可以发言，其他人不能发言。这个功能是通过会议属性来实现的，当房主指定发言人后，房主修改会议属性，所有人收到会议属性变更通知，如果发现会议属性中是指定的自己发言，自己打开麦克风。其他人关闭。当房主指定另外一个主播发言时，房主修改会议属性，所有人收到会议属性变更通知，当前主播自动下麦。

我们可以通过一张图，来了解主持模式中接口的调用逻辑：

抢麦模式

前段时间一款名为“音遇”的 APP 突然火了，以黑马之姿频繁登上各大榜单。据七麦数据统计，上线不到三个月，音遇总下载量达650万，这一增速仍在保持。从数据来看，音遇似乎将社交 APP 带到了一个风口。

音遇的确好玩，因为它的本质是游戏。音遇的核心玩法是劲歌抢唱和热歌接唱，形式是6人抢唱和6人接唱+抢唱，该核心功能基于用户更好地参与互动和享受竞技游戏来打造体验，而不是基于如何更好地唱歌来打造。

整场游戏下来，用户体验到的，是手速不够快、抢不到歌的遗憾，是听到各种或惊艳或车祸的现场的赞叹或调侃，是跟用户的互动，是胜利后的意犹未尽等等，反倒很容易忘了唱歌本身的好坏。我们体验到的，是这款游戏带给我们的乐趣，而不是唱歌本身。所以，用户在音遇上的游戏体验大于享受音乐的体验。

音遇重点是通过竞技游戏打造用户体验，让用户在游戏的过程中更“嗨”，更“带感”。

总结来说，音遇的火热和“劲歌抢唱”这种模式密切相关。“劲歌抢唱”其实就是在语音聊天室的基础上的一种“抢麦”玩法。环信语聊解决方案，针对“抢麦”玩法的实现已经为开发者给出了方案。

在抢麦模式下，只有抢到麦的主播可以发言，由 AppServer 来决定是否抢到麦，当房主发起抢麦时，首先请求 AppServer ， AppServer 确定主播可以抢麦，返回成功的同时，AppServer 开始计时，在计时结束前或者抢到麦的主播主动释放麦之前，其他主播请求 AppServer 抢麦返回失败。主播抢到麦后，修改会议属性，告知所有人自己抢到了，同时开始倒计时，倒计时结束后，主动重新设置会议属性，告诉所有人自己释放麦。其他人收到抢麦的会议属性变化回调后更新 UI，并开始倒计时，在倒计时结束或者收到释放麦的会议属性变化前，所有人不可以发起抢麦操作。

我们可以通过一张图，来了解抢麦模式中接口的调用逻辑：

参考

语音连麦聊天室