30分钟搭建语聊房，融云场景化SDK是怎么做到的？

一个拥有 1－2 年经验的开发者，从 0 到 1 上线应用只要 7 天。一个刚起步的程序员，可以 30 分钟内完成一个 Demo。

这不是天方夜谭，而是融云场景化 SDK 带给行业的创变。

商业社会兵贵神速，特别是以 Z 世代人群为目标用户的语音社交类应用。国家统计局的数据显示，1995 年到 2009 年出生的 Z 世代人口接近 2．6 亿。而相比“前辈”，他们的偏好更加个性、悦己、多变，社交上更讲究圈子、同好。

语音社交因沉浸式的情感交互而被 Z 世代 pick，但应用要不断围绕主流模式尝试突破，依靠玩法创新抢占先机，否则产品也就是“类卿”尔。

今天，我们就来详细了解一下，融云语聊房 SDK，是如何实现全面覆盖语聊房业务场景，支持开发者快速出活的。

01 语聊房了解一下

带大家拆解这款“行业利器”之前，咱们先重新认识一下语聊房。

语聊房，从字面上看就是语音聊天房，核心是多人实时语音交互。疫情之下，随着 Clubhouse 的大火，语聊房业务迎来爆发期，语音社交成功出圈。

（融云语聊房 Demo）

从上图看，语聊房 APP 的界面基本上由两部分组成。

上半部分主要是用户和麦位，对比生活中的场景，像一个有一位主持人和八位发言者的讲座，台下有若干听众；听众若有兴趣发言，走上讲台，拿起麦克风就可以变成发言人。

下半部分则是一些常规的聊天室模式，承担发送信息、发送礼物等功能。

开发这样一款产品，一般会面对什么问题呢？

首先是麦位信息同步。一个语聊房可能会有几千人在线，任何一个人上麦都需要在极短时间内把麦位信息同步给房间内所有人，这是第一个挑战。

其次是麦位管理。

上麦，意味着用户拥有了发布音频流的能力，角色从观众切换为主播。

下麦则意味着主播变成普通用户，失去了发布音频流的能力。

锁麦，就是锁定麦位，任何人都不可以上麦。

闭麦，顾名思义，该麦位上的用户无法发言。

邀请上麦，由房主邀请听众上麦互动。

还有一些音频类的常规操作，比如静音、混音、播放音乐等。

语聊房产品的核心是麦位管理，融云的语聊房解决方案，就是通过上麦、下麦等一系列麦位管理来对用户和流进行同步管理的 SDK。

02 语聊房业务流程

经过多年发展，融云的 IM 和 RTC 已经是行业基建。开发者使用 PaaS 服务商的这些能力，可以很方便地实现即时通讯和实时音视频的业务应用。

但是，把 RTC、IM 能力和场景玩法相结合的复杂业务，实现起来依然面临不小的困难。基于对行业的深厚积累和前瞻判断，融云推出下一代场景化 SDK 解决方案，首发场景聚焦与 Z 世代深度黏合的语聊房业务，满足开发者快速实现业务的需求。

那么在语聊房业务上，为开发者提供类似行业基建的 SDK，要处理哪些业务逻辑呢？

（房主端流程）

房主端流程：如图，单主播情况下，房主需要调用接口加入一个房间，然后邀请观众上麦或者处理观众的上麦请求。同时，房主还拥有闭麦、锁麦等麦位管理权限。

多主播情况下，首先要处理麦上人员的语音互动，这意味着主播需要互相订阅流来听到彼此的声音；房主可以调用接口关闭连麦者麦克风，或让连麦者下麦；通过聊天室属性，所有人都可以监听到房间内状态的变化，然后做出响应处理。

（观众端流程）

观众端流程：如图，观众浏览直播间列表，选择感兴趣的加入。加入后，语聊房自动订阅直播流；监听语聊房状态，更新房间 UI 和麦位 UI；收到直播结束消息，调用语聊房接口退出房间。

03 语聊房场景三大难题，融云如何通关

语聊房应用实现面临三大技术难关：

1）、麦位状态如何进行云端存储与通知

2）、如何实现邀请上麦和排麦请求机制

3）、如何设计 API

首先，麦位状态的云端存储与通知。

答案是——利用融云的聊天室属性管理能力。

每个聊天室提供 100 个 key－value 的键值对，特殊需求也可以申请扩容。

聊天室用户新增，更新，删除某个键值对，其他用户都会毫秒级速度收到 update 回调，保持一定的持续性，不会造成乱序等问题。

稳定、可靠，同时更改多个键值对也能保证每个更新都触发聊天室所有用户回调。

这样，语聊房的麦位状态存储和同步就可以比较顺畅地实现了。

（加入房间逻辑）

以加入房间这一动作为例：

用户加入房间只需传递一个 RoomId，语聊房 SDK 自动帮用户加入 IM Room 和 RTC Room，获得收发消息和音视频传输的能力。在加入这些房间后，用户就会收到一个回调，以回调的方式获得当下最新的房间信息和麦位信息。

如图所示，融云语聊房 SDK 隐藏加入房间需要的多个操作，融合成传递 RoomId 一个步骤，为开发者节省大量的研发工作。

在这个环节，用基础类 IM 和 RTC 能力开发需要 2 到 3 天，使用融云语聊房 SDK 只需 10 分钟。

其次，如何实现邀请机制和申请机制。

要实现顺畅的邀请和申请机制，有两点基础。第一，邀请的发送和接收信令必须是有序、准确的。第二，信令不能丢失。基于融云 IM 通讯服务安全、可靠、高效的信令通道，在这方面有天然优势。

（上麦逻辑）

以申请上麦为例，开发者自己实现需要先设计和实现一套自己的信令服务。使用融云语聊房 SDK，只需要一句 RequestSeat（请求麦位），房主端或有管理权限的成员，会收到一个回调，选择 accept 或 reject，观众端随即收到相应回调。

这一业务逻辑上，融云语聊房 SDK 为开发者简化了百分之八十的操作。

最后，如何设计 API。

这是整个 SDK 中最复杂的部分，也直接决定了它的实用性。功能做得再强大，如果无法以简单易懂的方式呈现，也会因为学习成本太大而让人望而却步。

在这方面，融云希望降低开发者的学习成本，让他们只通过文件的注释和命名就基本了解使用办法。

为了达到这个目标，融云的语聊房 SDK 在设计 API 时，首要原则是贴近业务。与传统的依赖倒置原则正好相反，特定场景的 API 设计，不能特别依赖于抽象接口，而要特别贴近具体的场景。

在语聊房 SDK 的使用中，开发者只要了解语聊房的基本模式，就能通过接口的命名，了解接口的功能，几乎可以零学习成本掌握。

比如，enterSeat（index： Int）接口，index 设置为麦的序号，就完成了这一麦位上角色转换、流的订阅等一系列操作。muteSeat（index： Int）接口则可以关闭某个麦位上的声音；kickUserFromSeat（userId： String）接口就可以把某个用户踢下麦。

其次要可扩展，无论是房间的属性，还是麦位的属性，SDK 都提供强大的可扩展性，自定义程度高，覆盖所有语聊房的场景，即便是语聊房中形式和内容最复杂的狼人杀场景也可以满足。

最后是简洁易用，语聊房 SDK 核心接口只有 20 个，大部分场景只需要其中 10 个基本上就可以实现业务。核心功能回调只有 23 个，对于不太关注性能或不需要兼容低端手机的业务，开发者只需关心麦位信息和房间信息的变更两个回调就可以。

而且，融云提供结构清晰的文档指南，紧贴语聊房场景，每部分都包含简洁易懂的视频示例，并提供一个全功能的线上开源 Demo，接入时有充足的参考资源。

此外，在内容安全要求趋严的背景下，融云还提供安全审查等关乎语聊房业务生死的通信周边能力。开发者只需在后台设置中一键开启安全审查，即可接入数美等在线业务风控解决方案提供商提供的安全审查服务，为开发者的业务开展保驾护航。

结合 IM ＋ RTC ＋ X“全”通信解决方案和对具体场景的业务逻辑抽取，融云的场景化 SDK 解决方案，将为开发者提供快速切入新赛道和发展多元业务的下一代服务新范式。