02 语聊房业务流程
经过多年发展,融云的 IM 和 RTC 已经是行业基建。开发者使用 PaaS 服务商的这些能力,可以很方便地实现即时通讯和实时音视频的业务应用。
但是,把 RTC、IM 能力和场景玩法相结合的复杂业务,实现起来依然面临不小的困难。基于对行业的深厚积累和前瞻判断,融云推出下一代场景化 SDK 解决方案,首发场景聚焦与 Z 世代深度黏合的语聊房业务,满足开发者快速实现业务的需求。
那么在语聊房业务上,为开发者提供类似行业基建的 SDK,要处理哪些业务逻辑呢?
(房主端流程)
房主端流程:如图,单主播情况下,房主需要调用接口加入一个房间,然后邀请观众上麦或者处理观众的上麦请求。同时,房主还拥有闭麦、锁麦等麦位管理权限。
多主播情况下,首先要处理麦上人员的语音互动,这意味着主播需要互相订阅流来听到彼此的声音;房主可以调用接口关闭连麦者麦克风,或让连麦者下麦;通过聊天室属性,所有人都可以监听到房间内状态的变化,然后做出响应处理。
(观众端流程)
观众端流程:如图,观众浏览直播间列表,选择感兴趣的加入。加入后,语聊房自动订阅直播流;监听语聊房状态,更新房间 UI 和麦位 UI;收到直播结束消息,调用语聊房接口退出房间。
03 语聊房场景三大难题,融云如何通关
语聊房应用实现面临三大技术难关:
l 麦位状态如何进行云端存储与通知
l 如何实现邀请上麦和排麦请求机制
l 如何设计 API
首先,麦位状态的云端存储与通知。
答案是——利用融云的聊天室属性管理能力。
每个聊天室提供 100 个key-value 的键值对,特殊需求也可以申请扩容。
聊天室用户新增,更新,删除某个键值对,其他用户都会毫秒级速度收到update 回调,保持一定的持续性,不会造成乱序等问题。
稳定、可靠,同时更改多个键值对也能保证每个更新都触发聊天室所有用户回调。
这样,语聊房的麦位状态存储和同步就可以比较顺畅地实现了。
(加入房间逻辑)
以加入房间这一动作为例:
用户加入房间只需传递一个 RoomId,语聊房 SDK 自动帮用户加入 IM Room 和 RTC Room,获得收发消息和音视频传输的能力。在加入这些房间后,用户就会收到一个回调,以回调的方式获得当下最新的房间信息和麦位信息。
如图所示,融云语聊房 SDK 隐藏加入房间需要的多个操作,融合成传递 RoomId 一个步骤,为开发者节省大量的研发工作。
在这个环节,用基础类 IM 和 RTC 能力开发需要 2 到 3 天,使用融云语聊房 SDK 只需 10 分钟。
其次,如何实现邀请机制和申请机制。
要实现顺畅的邀请和申请机制,有两点基础。第一,邀请的发送和接收信令必须是有序、准确的。第二,信令不能丢失。基于融云 IM 通讯服务安全、可靠、高效的信令通道,在这方面有天然优势。
(上麦逻辑)