共计 3391 个字符，预计需要花费 9 分钟才能阅读完成。
上周，鱼哥和几个挪动开发者吃饭闲聊，都聊到现在开发音视频产品，门槛较之前大大降低。在守业公司打拼的老马，始终做的 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() {
@Override
public void onSuccess() {// 创立胜利, 主动退出房间}
@Override
public 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 不是事儿。