搭积木一样实现语音社交软件开发

上周，鱼哥和几个移动开发者吃饭闲聊，都聊到如今开发音视频产品，门槛较之前大大降低。在创业公司打拼的老马，一直做的 Android 应用开发。老板希望把类似 Clubhouse 的玩法，作为他们新业务线。他开始了漫漫选型路。

其实，在国内得益于通信云服务商的底层建设，即使没有相关垂直经验，想要做一款语聊房产品切入这个市场也不是天方夜谭。难的是，怎么能达到老板对速度的要求。

语聊房产品要用到 IM（即时通讯） 和 RTC (实时音视频) 两大能力，面对的是几百个语焉不详的 API。光是集成这两个模块，就已经耗尽了心力、掉光了头发。

不过，老马还能出来跟我们侃大山，是因为他已经找到了捷径，他正对接一家服务商，顺利的话一周就能“完成 KPI，奖金到手来”了。

鱼哥以为他吹牛，因为我印象中的音视频业务总体还是很复杂，各种麦位管理，声音实时性，低延时等要求。其实并不怎么相信~

详细追问下，我才了解到是选择了 PaaS 厂商融云的 SDK。说起融云，我是很有印象的，他的创始团队都是以前开发“飞信”的核心人物，在通信领域那是杠杠的。融云基于强大的 IM 和 RTC 优势，很早就推出了封装基础通信能力的 SDK，并且在持续打磨精进。为了降低广大开发者的使用难度，融云投入大量资源，开发了针对热门场景的一揽子解决方案。把复杂的事情简单化。

融云语聊房 SDK，就是老马选用的解决方案，满足了语聊房场景绝大多数的需求，还覆盖一系列衍生场景的实际需求。

“11 月初时，融云基于场景化的语聊房 Demo & SDK 2.0 正式上线，新增了连麦 PK 和语音电台二大主流场景，以及房间浮窗显示、滑动切换房间、发送语音消息、礼物全服广播和设置房间屏蔽词等实用功能，覆盖时下所有热门语聊房场景。”

我去他们官网研究了下，的确非常简单，大大降低了开发的时间成本和资金成本。能快速实现业务需求。

比如，第一步直接集成语聊房 SDK 就行，不用单独集成 IM 和 RTC；

再比如，核心 API 不超过 20 个，核心回调不超过 5 个；

又比如：可以直接在融云的开发者后台找到“开启审核”配置，点击配置，意味着一键接入第三方专业内容审核平台，从根本上杜绝了恶意传播非法内容的可能。

功能强大对开发者来说只是满足了最基本的需要。而最引起鱼哥关注的是“7 天上线”。这个速度，简直不可想象。

为此，鱼哥与融云场景化研发负责人臧其龙深入地聊了聊。

臧其龙介绍说，融云可以帮助开发者抢跑赛道的关键点在于，不仅开放源码，还在这之上将混杂无章的源码按语聊房场景的业务逻辑封装成 SDK，并提供直观的 API 接口。

这样，开发者无需理解底层技术逻辑，只要对这个业务有基本了解，知道什么是创建房间，离开房间；什么是上麦、什么是下麦，就能够快速完成开发。

鱼哥调看了下融云的开发文档，创建房间的代码是这样的，的确简洁易懂。示例代码如下：

/// 创建一个 RCVoiceRoomInfo 实例RCVoiceRoomInfo rcVoiceRoomInfo = new RCVoiceRoomInfo();/// 设置房间名称rcVoiceRoomInfo.setRoomName(roomName);/// 设置麦位数量rcVoiceRoomInfo.setSeatCount(9);///设置上麦模式（ture是自由上麦 false为申请上麦）rcVoiceRoomInfo.setFreeEnterSeat(false);///设置全麦锁座rcVoiceRoomInfo.setLockAll(false);///设置全麦锁麦rcVoiceRoomInfo.setMuteAll(false);// roomId 是您的业务服务器返回的RCVoiceRoomEngine.getInstance().createAndJoinRoom(roomId, rcVoiceRoomInfo, new  RCVoiceRoomCallback() {@Overridepublic void onSuccess() {//创建成功,自动加入房间}
@Overridepublic void onError(int code, String message) {    //创建失败}

});

对于开发者最为关心的，一款语聊房如何实现，以及功能的好坏，其关键技术点有三个：KV 聊天室属性、信令 SDK 和 API 设计，鱼哥也请臧其龙进行了详细解答。

KV 聊天室属性

KV 聊天室属性，提供麦位状态的云端存储和通知的同步能力，可在 20-40 毫秒内，快速同步任何数据库的增删改查，满足包括直播室连麦、语音聊天室连麦、游戏连麦等各种语聊场景中，不同麦位对应不同角色的同步能力，以及随时切换的时序能力。

信令 SDK

信令 SDK，保证有序性。在邀请和请求上麦场景中，既能避免因频繁上下麦所产生的杂乱，也能保证申请上麦的先来先上，后到后上，使用户体验更顺畅。

这两点，对自研开发者来说难度都较大，却是一个语聊房产品能否研发成功的关键技术点。

而语聊房产品研发出来，到底好不好用，API 设计是第三个关键技术点，臧其龙称其为“产品门面”。

API 设计

API 设计：核心在于符合用户的使用习惯，最自然的才是最合理的。例如：上麦就应该可以发语音，而下麦则只能听语音。

为了方便使用，融云一方面精简 SDK，将 API 总数控制在 20 个以内，从而降低用户的学习成本。另一方面，在模型的设计上给予了用户极大自由度的扩展属性，从而满足用户的各种创意十足的需求，使功能的强大性和覆盖场景的多样性，二者兼得。

鱼哥发现，自今年 6 月融云语聊房 1.0 推出以来，市场上已经开始出现不同名称，但本质趋同的产品形态，比如 voice Demo、k 歌房 Demo 等。

对于开发者来说，又该如何评判和选择呢？融云还有优势吗？鱼哥仔细查看了这些 Demo 的实现逻辑，发现融云还是有一定优势的。

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

意思就是说，融云的场景化语聊房 SDK 是第三代解决方案，最大的特点就是：将与场景相关的所有能力集合封装，不用再分别调用 IM 和 RTC SDK。

而第二代解决方案，是目前其他厂商在用的方式，开发难度上，是需要开发者先理解 IM 和 RTC 的底层逻辑，然后还要面对几百个 API，在源码基础上再进行二次开发。

在实现逻辑上，第三代比第二代更简单，省去了大量的对底层逻辑学习的过程。

鱼哥还了解到一个真实的小案例:

“开发者先用某厂提供的第二代方案进行二开，过程中发现很多问题难以解决。切换成融云语聊房 SDK 2.0，之前将近三个月都没搞定的项目，只用两周就完成了产品上线。”

臧其龙说，语聊房 1.0 上线以来，短短 5 个月的时间里，对接的 20 家客户中，就有 10 款 APP 应用交付上线。他自己每天都在技术支持群里与开发者交流，最大的欣慰是开发者的反馈：

“只阅读注释和 API 名字，就能基本掌握用法，学习成本低，开发效率高。”

语聊房 3.0 还将有哪些新功能？

接下来，融云语聊房 3.0 还将有哪些新功能？大家搬好小板凳坐好，鱼哥现在可以“透露”下~ 与上半界面麦位用户相关的发送礼物、发送表情、聊天室信息接收等相关功能，会进一步完善，推出一系列高性能的 Kit 组件，比如礼物 Kit、异步渲染的聊天室 Kit。

这里重点可以关注下融云自研的聊天室全异步渲染框架，利用这个框架，可以保证在非常低端的手机上也能跑满帧，带给用户非常流畅的 APP 使用交互体验。

出海的开发者要考虑不同区域的终端用户手机的差异会非常大，如果在不发达国家，低端手机占有率比较高，那么全异步渲染框架会是一个很好的选择。

未来 6 个月内，融云还将开源 8-10 个高性能的 UI 框架，同时满足 iOS 端和 Android 端，让开发者可以更方便地对接场景化 SDK，快速构建高质量的产品。

除了语聊房 3.0 之外，会议 Meeting、1V1 在线陪聊、在线教育的场景化 SDK 都在融云下一阶段的产品路线图上。

最后，如果让鱼哥用一个词总结这样的开发体验，那就是“搭积木”。融云提供源码及之上封装好的 SDK，相当于提供的积木，让开发者可以真正实现“开箱，即插即用”，从 0 到 1，最短 7 天，一般三周也可以上线一款功能完整的语聊房产品。

开发者，尤其是中小企业的开发者，不必自建，不再为复杂的逻辑架构绞尽脑汁，更无需把时间耗费在反复的写代码、改 Bug 中。一句话，天空飘来五个字，coding 不是事儿。