大到一个经济时代，小到一个行业周期，生产工具的每次创新升级，势必带来生产力的显著提升。
在 WICC 广州的“社交分论坛”上，融云场景化研发负责人臧其龙带来《融云社交场景化 SDK 探索》主题演讲，分享融云在通信云服务方面的创新探索。融云第三代场景化 SDK 的服务模式创新将给开发者提供全新的生产工具，带来生产效率的极大提升，也必将重塑产业格局。
但是，随着时间的推进，市场需求不断演变。我们会发现，单一场景需求越来越少，更多的时候，我们要面对的是场景的融合。
以语聊房这个时下语音社交热门场景为例来说，这类产品主要有两部分组成：一是麦位管理部分，用户上麦后角色发生变化，从观众切换成主播，可以发布音频流被观众和其他主播听到。二是聊天室部分，也就是公屏消息的部分，房间内所有成员都可以发送文字在公屏区域沟通。
实现这两个部分，就要同时接入 RTC 和 IM，也就是融合场景。这种融合需求也出现在直播等等场景中。随之而来，棘手的问题出现了。
问题并非出于服务能力不足，反而是大部分行业供给都已经非常强大造成的。一个 SDK，基本上有 200+ 甚至 300+个 API。当开发者接触到一个功能强大的 SDK，首先面对的难题是学习成本特别高，其次是它的学习曲线也比较陡峭。
比如 RTC 会涉及到很多非常专业的音视频领域知识，要了解流的定义与发布，学习一些编码知识，掌握了基础知识后，才能让 SDK 发挥应有的作用。
以语聊房场景为例，我们可以更加直观地感受三代服务模式的升级核心。
语聊房产品的核心是麦位管理，语聊房解决方案，就是通过上麦、下麦等一系列麦位管理来对用户和流进行同步管理的 SDK。
第一代解决方案，使用业务服务器管理每个房间的麦位。前端只负责调用后端的接口，后端管理麦位，不单要更改麦位，还要负责整个状态的刷新和发布，非常复杂。
第二代解决方案，也就是目前其他厂商普遍使用的方式。把管理麦位的能力放在 IM SDK 里，通常是聊天室属性，拥有麦位的增、删、改、查同步能力。服务模式是，开发者下载 Demo，自行研究实现逻辑，再利用开源代码二开实现。也就是说，开发者还是需要理解厂商提供的开源代码，上手难度比较高。
第三代解决方案，也就是融云行业首推的 SDK。开发者无需研究代码，也不需要单独集成 IM 和 RTC，只需要对这个产品有了解，就可以调用接口实现应用。而且这个接口数量只有不超过 20 个。
第二代解决方案，只需要关注前端开源代码，但是也要面临残酷的现实问题。首先，原封不动上架产品面对很大的审核被拒风险；其次，新增功能需要学习底层机制再改代码，难度大，易出 Bug。
融云的第三代 SDK 解决方案，学习难度非常低，只需要对基础的上麦、下麦、锁麦等有了解，甚至根据 20 个 API 的注释就能成功调用。无需理解底层代码，无需研究实现逻辑，无需管理流的订阅，极大提升开发速度，7 天就能上线一个语聊房。
以最常见的三个功能为例，enterSeat(index: Int) 接口，index 设置为麦的序号，就完成了这一麦位上角色转换、流的订阅、UI 的同步和刷新等一系列操作。muteSeat(index: Int) 接口，Mute 是静音，Seat 是某个麦位，后面会带一个麦位的序号，可以关闭某个麦位上的声音；kickUserFromSeat(userId: String) 接口就可以把某个用户踢下麦。都说细节是魔鬼，第三代 SDK 可以说是已经把魔鬼封在黑盒中了，开发者可以无忧开发。
可扩展性：语聊覆盖的场景非常多，比如非常火的狼人杀业务，需要麦位体现特殊身份——平民、法官、狼人，接口设计得足够可拓展，就可以覆盖所有热门场景，也方便开发者去做不同业务的尝试。
简洁易用：语聊房 SDK 核心接口只有 20 个，大部分场景只需要其中 10 个基本上就可以实现业务。核心功能回调只有 23 个，对于不太关注性能或不需要兼容低端手机的业务，开发者只需关心麦位信息和房间信息的变更两个回调就可以。
直播场景通常用户感知最强烈的就是两个步骤，唤起摄像头做直播前美颜等准备 ➡ 开始直播。
融云直播 SDK 把这两步封装成 API，第一步是 Prepare，封装了融云开源的 BeautyKit 美颜等能力；第二步是 Live Video，把所有直播流程实现逻辑隐藏掉，开发者只需要调用接口就可以实现业务。
接下来，融云还会把会议、教育等场景进行完整封装提供给开发者，帮开发者一一攻克场景难关。
同时，在 SDK 组成的“骨骼”、“肌肉”之外，融云还将开源一系列含 UI 体系的 Kit，作为配套使用的“皮肤”。比如，ChatKit、GiftKit、BeautyKit、MusicControlKit 等等。搭配开发者可在后台一键配置的“内容审核”能力，真正为开发者提供一站式的完整解决方案服务。
