共计 2243 个字符，预计需要花费 6 分钟才能阅读完成。
【关注 融云寰球互联网通信云 】展开讨论之前，咱们先来看一段 Javascript 伪代码。
// 加⼊聊天室，获取收发音讯和信令能⼒
IMClient.shared.join(roomId, (isSuccess, error) => {if(isSuccess) {
// 加⼊ RTC Room 获取⾳频流和公布⾳频流能⼒
RTCClient.shared.join(roomId, role, (isSuccess, error) = > {
// 依据⾓⾊确定⽤户⾏为，是订阅⾳频流还是公布⾳频流
if(role == Audience) {RTCClient.subscribeStreams(streams, (error) => {})
} else {RTCClient.publishStreams(streams, (error) => {})
}
})
} else {console.log(error)
}
})
惯例语聊房解决方案
上述代码展现了业界常见的语聊房解决方案，即利用 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 是更好的解决方案，间接推动行业进入了新倒退阶段。
首先，用户上麦。
/// ⽤户被动上⻨
/// @param seatIndex ⻨位序号
/// @param successBlock 上⻨胜利
/// @param errorBlock 上⻨失败
- (void)enterSeat:(NSUInteger)seatIndex
success:(RCVoiceRoomSuccessBlock)successBlock
error:(RCVoiceRoomErrorBlock)errorBlock;这是融云语聊房 SDK 封装的上麦操作。开发者无需关注麦位的信息更新和同步，无需关怀流的订阅与公布，只有输出想要上麦的序号，所有细节都曾经在 SDK 外部实现了。
再来看看，在语聊房场景中常见的申请上麦，大抵流程如下：
（申请上麦流程）
繁琐的申请上麦、批准上麦等机制被简化为两个 API 和一个回调，简洁、高效地实现了简单的上麦机制。
想要上麦的用户调用 requestSeat，向其他人发送上麦申请；
领有审核权限的⼈，例如房主或管理员触发回调后，通过 accept 或者 reject 即可批准或回绝对方上麦。
总而言之，融云推出的第三代解决方案——场景化 SDK，外围思路是将开发者从繁琐的开发中解放出来，帮忙他们解放生产力，投入更多精力在产品翻新上，开拓新战场、吸引新客群、播种新增长。
