03 语聊房场景三大难题,融云如何通关
语聊房应用实现面临三大技术难关:
l 麦位状态如何进行云端存储与通知
l 如何实现邀请上麦和排麦请求机制
l 如何设计 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 解决方案,将为开发者提供快速切入新赛道和发展多元业务的下一代服务新范式。