从语聊房 SDK 的诞生，看 PaaS 服务的演进过程

展开讨论之前，我们先来看一段 Javascript 伪代码。

1 // 加⼊聊天室，获取收发消息和信令能⼒
2 IMClient.shared.join(roomId, (isSuccess, error) => {
3 if(isSuccess) {
4 // 加⼊RTC Room 获取⾳频流和发布⾳频流能⼒
5 RTCClient.shared.join(roomId, role, (isSuccess, error) = > {
6 // 根据⾓⾊确定⽤户⾏为，是订阅⾳频流还是发布⾳频流
7 if(role == Audience) {
8 RTCClient.subscribeStreams(streams, (error) => {
9 })
10 } else {
11 RTCClient.publishStreams(streams, (error) => {
12 })
13 }
14 })
15 } else {
16 console.log(error)
17 }
18 })
19

常规语聊房解决方案

上述代码展示了业界常见的语聊房解决方案，即利用 IM 与 RTC 能力打造语聊房的过程。 

基于这个方案，开发者需要处理以下问题：

• 同时维护 IM Room 与 RTC Room
• 需要根据角色判断流的订阅与发布
• 需要处理不同的错误信息

接下来我们再来看看利用常规方案处理上麦这一语聊房常见操作的基本流程。

开发者需要处理的逻辑如下： 

• 存储麦位信息
• 在更新麦位信息后，同步房间所有用户麦位信息
• 上麦时发布音频流，下麦时取消发布
• 上麦或下麦切换订阅流的逻辑（如果角色为主播需要订阅其他主播分流，如果角色为观众需订阅主播合流）

结论是，如果开发者基于 PaaS 服务的底层 SDK 进行语聊房的开发费时费力，并且需要处理相当多的业务逻辑。

语聊房解决方案的演变过程

事实上，以上方案已经是第二代语聊房解决方案，也是目前各 PaaS 服务厂商提供的主流解决方案。

我们简单介绍一下语聊房解决方案的演变过程。

首先需要明确的一点是，语聊房的核心是如何更好的管理麦位。

语聊房解决方案经历了 3 个阶段。 

第一代，基于业务服务器管理麦位：PaaS 服务商提供后端和前端开源代码，开发者基于此进行二次开发。即，前端通过 Restful 接口调用后端接口，业务服务器来维护麦位信息的同步和更新。 

第二代，基于前端 + 示例项目二开的方式：即管理麦位通过前端 IM SDK 直接修改聊天室属性进行维护和修改麦位信息，无需业务服务器参与，可以结合 RTC SDK 实现音频流的变更与订阅。并且，厂商提供对应的开源代码，开发者可根据开源代码进行二开。 

第三代，也就是目前融云提供的解决方案，根据不同的融合场景（例如语聊房、直播等），将各种基础服务有机结合起来，提供贴近业务的 API 与回调，直接封装为特定的场景化 SDK。

我们从学习难度、开发难度、扩展性三个维度来对比各个方案的优劣。 

学习难度

第一代方案基于业务服务器维护和管理麦位信息，开发者需要自己处理多用户的麦位同步、流的管理等复杂逻辑。并且，想要从 0 到 1 实现⼀个完整的语聊房项目，需同时接入和学习前后端开源代码，难度很高。 

第二代方案，基于前端直接调用 IM SDK 的存储能力管理麦位，省去了业务服务器管理麦位的流程，相对简化，但是开发者仍然需要学习底层 SDK 的各个能力。 

第三代方案，在第二代方案的基础上，将基础能力封装为贴近业务场景的 API，让开发者无需理解底层实现，只需要理解产品概念就能快速出活，从 0 到 1 开发完整语聊房项目。 

开发难度

第一代方案需要同时接入前后端两套代码，更改难度巨大。

第二代方案需要在理解底层 SDK 使用的基础上进行更改，如果不是深入了解很难进行二次开发。 

第三代方案只需理解产品概念即可，无论是基于 SDK 开发，还是基于样例开发，都能轻松掌握。

扩展性

第一代方案由于学习成本和开发难度大，开发时束手束脚，很难拓展新的玩法与模式。 

第二代方案开发难度和学习成本都有⼀定程度的降低，扩展性局限在对开源代码的理解上。 

第三代方案的扩展性基于 SDK 提供的扩展属性是否丰富，依赖于封装的程度。

第三代方案的样例展示

俗话说：Talk is cheap. Show me the code.我们通过⼀些实例来展示为什么场景化 SDK 是更好的解决方案，直接推动行业进入了新发展阶段。

首先，用户上麦。

1 /// ⽤户主动上⻨
2 /// @param seatIndex ⻨位序号
3 /// @param successBlock 上⻨成功
4 /// @param errorBlock 上⻨失败
5 - (void)enterSeat:(NSUInteger)seatIndex
6 success:(RCVoiceRoomSuccessBlock)successBlock
7 error:(RCVoiceRoomErrorBlock)errorBlock;

这是融云语聊房 SDK 封装的上麦操作。开发者无需关注麦位的信息更新和同步，无需关心流的订阅与发布，只要输入想要上麦的序号，所有细节都已经在 SDK 内部实现了。

再来看看，在语聊房场景中常见的申请上麦，大致流程如下：

繁琐的申请上麦、同意上麦等机制被简化为两个 API 和一个回调，简洁、高效地实现了复杂的上麦机制。

• 想要上麦的用户调用 requestSeat，向其他人发送上麦请求；
• 拥有审核权限的⼈，例如房主或管理员触发回调后，通过 accept 或者 reject 即可同意或拒绝对方上麦。

总而言之，融云推出的第三代解决方案——场景化 SDK，核心思路是将开发者从繁琐的开发中解放出来，帮助他们解放生产力，投入更多精力在产品创新上，开辟新战场、吸引新客群、收获新增长。