共计 5908 个字符,预计需要花费 15 分钟才能阅读完成。
图片起源:https://699pic.com/tupian-401…
作者:AirLand
什么是 RTC?
RTC 即 Real-Time Communication 的简称是一种给行业提供高并发、低延时、高清晦涩、安全可靠的全场景、全互动、全实时的音视频服务的终端服务。下面是比拟官网的解释,艰深的来讲就是一种可能实现一对一、多对多音视频通话等泛滥性能的服务。目前提供该项服务的服务商有很多例如:声网、云信、火山引擎、腾讯云等。
背景
目前云音乐旗下 APP 泛滥,其中波及到 RTC 业务的不在少数,例如:常见的音视频连麦、PK、派对房,1v1 聊天等。因为业务线不同,性能不同,开发者也不同,大家各写一套,一直的反复造轮子,因而为了防止反复的开发工作晋升开发效率,须要有一套通用的 RTC 框架。
设计思路
在讲具体的方案设计之前,先讲一下我的设计思路:
- 性能内聚 :须要将性能都封装在一个容器里,对外通过接口提供办法调用
- 业务隔离 :不同的业务须要有不同的性能容器
- 对立调用 :所有性能容器须要有对立的调用入口
- 状态保护 :须要对状态进行精准保护
- 切换无感 :进行性能容器切换时候,无感知
- 外围可控 :对外围链路可监控,故障预警
基于以上 6 点,大抵的架构设计如图所示,这里先不必深究图中的模块示意什么,前面会讲到,这里只是先理解一下大抵的架构:
接下来我就来讲讲具体的实现过程。
方案设计
前言:
RTC 的业务场景尽管很多,但实质上却相差无几,都是用户退出到一个独特的房间,而后在房间内进行实时的音视频通信。具体到理论我的项目中大抵又可分为两种:全场景 RTC 和局部场景 RTC。
- 全场景 RTC:整个业务都是通过 RTC 技术实现例如:1v1 音视频通话、派对房等。
- 局部场景 RTC:即整个业务链路中只有一部分应用了 RTC 技术,往往这种业务会波及到引擎的切换。
不论是哪一种场景,承载外围性能的引擎都是必不可少的,因而咱们首先就从引擎开始着手,另外为了不便形容,后续便将引擎对立称作 Player。
1、Player 的封装
在与 RTC 相关联的业务中会波及到不同类型的 Player,例如:主播开播(推流 Player),观众观看直播(拉流 Player)以及 RTC Player 等。它们的性能尽管各不相同,但用法却有相似之处,例如都有启动 start,终止 stop 等。因而咱们能够将不同的 Player 形象出一个独特的接口 IPlayer 相干代码如下:
interface IPlayer<DS : IDataSource, CB : ICallback> {fun start(ds: DS)
fun stop()
fun <T : Any> setParam(key: String, value: T?)
......
}
其中 IDataSource 和 ICallback 别离是启动 Player 所须要的数据源和回调,前面的文章中也会屡次提到,特地是 IDataSource 它是 Player 启动的源头就好比打电话时的电话号码。
在这里遇到的一个问题点就是因为 Player 内聚了所有的性能除了有一些通用办法外,也有着属于本人特有的办法,例如:静音,音量调节等。这些办法泛滥而且各不相同无奈在 IPlayer 接口中全副列出,即便能全副列出,但随着业务的迭代 Player 中的办法必定会一直变动,不可能每更改一个办法就改一下接口,这显然不合乎程序设计准则。那么如何将不同的办法抽象化,让下层通过调用同一个办法来执行不同的操作呢?这里通过:
fun <T : Any> setParam(key: String, value: T?)
来实现,其中 key 示意办法的惟一标记,value 示意办法的入参。这样下层只须要通过调用 setParam 传入相应的办法标记和办法入参即可调用到对应的办法了。那么如何做到呢?答案也很简略通过一个中间层建设起一一映射关系。然而 Player 的类型泛滥,要是每写一个 Player 都要写一个映射逻辑就太麻烦了。所以这里通过 APT 编译时注解再联合 [javapoet](https://github.com/square/jav…
) 主动生成这个中间层并给它命名为 xxxPlayerWrapper 其外部生成一个 convert 办法,在这个办法外部实现一一映射逻辑。接下来咱们看看具体实现过程:
-
首先定义了两个注解别离作用于具体的 Player 和对应的办法例如:
@Retention(RetentionPolicy.CLASS) @Target({ElementType.TYPE}) public @interface PlayerClass { } @Retention(RetentionPolicy.CLASS) @Target({ElementType.METHOD}) public @interface PlayerMethod {String name(); } @PlayerClass open class xxxPlayer : IPlayer<xxxDataSource, xxxCallback>() {@PlayerMethod(name = "key1") fun method1(v: String) {.... 具体实现} }
- 一一映射关系建设:
xxxPlayer 和 xxxPlayerWrapper 之间是一个相互依赖关系,互为彼此的成员变量。当调用 xxxPlayer 的接口办法 setParam(key: String, value: T?) 时,会间接调用到 xxxPlayerWrapper 的 convert 办法,convert 办法会依据 key 来找到其所对应的办法名,最初间接调用到 Player 的具体方法。
因为所有的 Player 都有这个逻辑因而能够将这部分再形象成一个 AbsPlayer:
abstract class AbsPlayer<DS : IDataSource, CB : ICallback>
: IPlayer<DS, CB>{
var dataSource: DS? = null
private val wrapper by lazy {
val ret = kotlin.runCatching {val clazz = Class.forName(this::class.java.canonicalName + "Wrapper")
val signature = arrayOf(this::class.java)
clazz.constructors.find {signature.contentEquals(it.parameterTypes)
}?.newInstance(this) as? PlayerWrapper
}
ret.exceptionOrNull()?.printStackTrace()
ret.getOrNull()}
override fun <T : Any> setParam(key: String, value: T?) {wrapper?.convert(key, value)
}
//...... 省略其余无关代码
}
最初整个 Player 的类图如下所示:
这里咱们不关注 Player 的性能具体是如何实现的,比方如何推流,如何拉流,如何进行 RTC 等。毕竟每个我的项目底层所用的服务商 sdk 各不相同,技术实现也不同,因而这里咱们只从架构的层面去探讨。
2、Player 的切换
Player 的切换针对的就是局部场景 RTC,这里咱们引入 SwitchablePlayer 的概念专门用于此种场景,而其自身也继承自 AbsPlayer,具备 Player 的所有性能。只不过这些性能是通过装璜者模式由其外部真正的 Player 来实现,同时减少了 Switch 的能力。再讲到 Switch 能力之前先来思考几个问题。
- 何时触发 Switch?
- 如何进行 Switch?
- Switch 的指标对象 Player 从何而来?
第一个问题何时触发 Switch:咱们晓得只有触发 Switch 就意味着须要启动另外的 Player,而启动 Player 又须要下面提到的 IDataSource,因而咱们只须要判断启动 Player 所传入的 IDataSource 类型和以后 Player 的 IDataSource 类型是否雷同,如果不同便可触发。判断的具体逻辑是比照以后 Player 泛型参数的 IDataSource 类型(AbsPlayer<DS : IDataSource, CB : ICallback> 第一个范型参数 )和传入的 IDataSource 类型来实现。
private fun isSourceMatch(
player: AbsPlayer<IDataSource, ICallback>?,
ds: IDataSource
): Boolean {if (player == null) {return false} else {
val clazz = player::class.java
var type = getGenericSuperclass(clazz) ?: return false
while (Types.getRawType(type) != AbsPlayer::class.java) {type = getGenericSuperclass(type) ?: return false
}
return if (type is ParameterizedType) {
val args = type.actualTypeArguments
if (args.isNullOrEmpty()) {false} else {Types.getRawType(args[0]).isInstance(ds) && isSameSource(player, ds)
}
} else {false}
}
}
第二个问题如何进行 Switch:这个就比较简单了只须要进行掉以后的 Player 再启动指标 Player 即可。
第三个问题 Switch 的指标对象 Player 从何而来 :SwitchablePlayer 并不分明业务须要哪些 Player,只是对 Player 性能的一层包装以及保护 Switch 性能,因而具体的 Player 创立须要由业务层来实现,SwitchablePlayer 只提供一个获取 Player 的形象办法例如:
abstract fun getPlayer(ds: IDataSource): AbsPlayer<out IDataSource, out ICallback>?
另外因为进行 Switch 的时候会进行掉以后的 Player,而被进行的 Player 是否能复用,如果能复用则能够将其缓存起来,下次应用优先从缓存中取得。整个 SwitchablePlayer 对应的流程如图所示:
在应用时调用者能够依据本人的业务定义相干 Player, 例如在直播 -> PK 的业务中,波及到两个 Player 的切换即:LivePlayer 和 PKPlayer
class LivePKSwitchablePlayer : SwitchablePlayer(false) {override fun getPlayer(ds: IDataSource): AbsPlayer<out IDataSource, out ICallback> {return when (ds) {
is LiveDataSource -> {LivePlayer()
}
is PKDataSource -> {PKPlayer()
}
else -> LivePlayer()}
}
}
3、流程封装
对于整个 RTC 流程的封装须要搞清楚两件事件:
- RTC 的主体流程是怎么的
- 业务调用方须要的是什么,关注的又是什么
因为 RTC 的主体流程和日常打电话类似,所以笔者以此类比,这样大家更容易了解。下图所示即为整个通话过程。
搞清楚整个流程后,接下来就是搞清楚第二件事件,业务调用方须要的是什么,关注的又是什么。联合上图来看关注的大略有三点:
- 第一就是须要具备拨打和挂断的入口;(Player 的 Start 和 Stop)
- 第二就是要能晓得以后的通话状态比方是否正在连通,是否曾经接通,是否通话完结;(Player 的 状态保护 )
- 第三就是一些反馈比方对方未接通,对方不在服务区,手机号是空号等。(Player 的 外围事件回调即之前提到的 ICallback)
而至于它是如何连通的,底层做了哪些操作,拨打电话的人对此毫不关心。基于上述咱们的整体功能设计所要关注的点就有了。
1、通过设计一个 manager 来治理 Player 并对外裸露 Start 和 Stop 办法。
2、对 Player 进行状态保护,并让其状态可被下层监听。
3、Player 的一些外围事件回调也可被下层监听。
其中第一点和第三点比较简单,这里就不做过多的赘述。第二点状态保护,笔者应用了 StateMachine 状态机来实现,在不同的状态执行不同的操作,同时每一种状态都对应一个状态码,下层能够通过监听状态码来感知状态变动。
状态码和外围事件的设置这里应用了 LiveData 去解决
class RtcHolder : IRtcHolder {private val _rtcState = MutableLiveData(RtcStatus.IDLE)
private val _rtcEvent = MutableLiveData(RtcEvent.IDLE)
val rtcState = _rtcState.distinctUntilChanged()
val rtcEvent = _rtcEvent.distinctUntilChanged()
private val callBack = object : IRtcCallBack {override fun onCurrentStateChange(stateCode: Int) {_rtcState.value = stateCode}
override fun onEvent(eventCode: Int) {_rtcEvent.value = eventCode}
//...... 省略其余代码
}
init {
// 下层状态监听
rtcState.observeForever {when (it) {
RtcStatus.CONNECT_END -> {ToastHelper.showToast("通话完结")
}
}
}
}
//...... 省略其余代码
}
到这里整个脚手架的方案设计就完结了,其中服务商 SDK 封装局部以及监控局部,笔者筹备放到下期再来解说。
总结
本文介绍了 RTC 脚手架产生的背景,并以通俗易懂的形式一步步论述设计过程以及最终实现。在此期间发现问题,解决问题,引出思考。因为受限于篇幅,不能将每一个点都进行详尽的介绍,有趣味的同学如有疑难,能够留言,一起探讨学习。
本文公布自网易云音乐技术团队,文章未经受权禁止任何模式的转载。咱们长年招收各类技术岗位,如果你筹备换工作,又恰好喜爱云音乐,那就退出咱们 grp.music-fe(at)corp.netease.com!