5.11.Webrtc接口的设计原理

在上节课中呢,我向你介绍了web rtc的接口宏,那有很多同学会产生疑问啊,那觉得web rtc为什么要把接口设计的这么复杂?还非要通过宏来实现一个代理类,再通过代理类来调用到web rtc内部。

那为什么要这么设计呢?实际上它的这样一种设计啊,它是有一定理论的,那下面呢,我们就来详细看一下web rtc为什么要这么做?那这张图呢,就是web rtc它设计接口的一个架构。

那在中间层呢,就是通过接口宏来实现的,代理层在代理层之上是应用层,比如我们前面向你介绍的peer connection client就是应用层。而在proxy之下呢,是y8r7c的核心库,那所有的比如信令线程工作线程网络线程以及对于音视频的采集编码传输等等的。这些都是在外边儿tc的核心库中实现的,那么通过这个代理层做一层代理之后,那就将应用层与核心库之间做了一层隔离。那这样做有什么好处呢?那我想呢,至少有以下几点好处,那第一点呢,就是只输出必要的接口儿。

也就是说,我们迈达tc可能提供了几百个甚至上千个接口儿,但是这些接口儿呢,对于应用层来说,不必要全都知道。我们只需要暴露,必须暴露给外层的接口就可以了,比如说只有五个或者十个应用层,只要调用这些接口就可以满足它的需求。而对于其他的几百个或者上千个接口,都是我们内部需要的接口,那这些呢?是不应该暴露给用户的。如果我们把这些接口也暴露给用户,那实际上是增加了用户的使用成本,

他要将上千个接口把他们都捋出来。那要花费大量的学习时间,那不如我们就给它暴露一些必要的接口,那这样呢,用户学起来就非常的容易。所以这是一个非常好的设计方式,这样一种设计还是非常灵活的,当我们需要把y八二七c的某些接口释放出来的时候。我们只要在这个代理类中增加相关的接口,那用户呢,就可以直接调了,当我们不需要让用户了解这些接口的时候呢?还可以把它从代理类中取消掉,用户就没法再访问这些接口了。那这样一种设计其实是非常灵活的,

这是第二点。那第三点呢,就是当我们使用了代理类之后,就将应用层与web rtc核心库进行了一层隔离。防止了应用层去污染这个web rtc核心层所有的调用,必须通过代理类进行调用。而且在调用的过程中呢,要进行线程的切换,假如说我们在应用层创建了五个线程,那如果我们不使用代理类的话,很可能这五个线程就会与y八二tc内部的线程。产生一些冲突或者说应用层的线程会注入到y八二tc的核心库中去,那这样呢,就会造成发生错误的时候。我们很难判断,

具体是由于外边儿,室内核儿引起的原因,还是说我们应用层由于创建了一些线程?这些线程呢,进入到了web rtc核心层引起的问题,你就不好把这件事说清楚,但是通过这个代理层之后,那我们很容易就能确定你到底是应用层的问题,还是web rtc核心库的问题。所以对于web rtc这种设计来说,它是有效的,防止了应用层对web rtc核心库的污染。好,这是使用代理类的几点好处?当然,

它同时也带来一些麻烦,就是我们在定义我们自己接口的时候,你必须按照它的步骤一二三,这样去定义。之后呢,才可以进行调用,所以这是增加了我们一些这个学习成本,但是对于你研发web rtc部的核心开发人员来说呢,那这就不算什么了。但是对于从外层理解外边儿tc来说,确实是增加了一些难度,所以这是鱼和熊掌不可兼得的一个东西。那就是为了更好的防护外部rtc,就要将接口架构设计的复杂一些,但同时带来好处就是我们可以有效的将外部rtc库与应用层进行一个隔离。

而且接口的放出与隐藏都是非常方便的,好,那接下来呢?我们来看看接口类的关系图。

那实际上我们在上节课中,在介绍实现自己接口的这个方案的时候呢,已经向你做过介绍了,它需要三大步,那第一步呢,我们要实现一个接口类。也就是以你的类的名字,后边加一个interface后缀为接口类的名字,那有了这个接口类之后呢?我们需要在外边rtc内核中去实现。

这个接口也就是说要生成一个类,继承自某某某interface这个接口类,并且呢,将其中的方法都实现了。之后,我们需要通过y8 tc的接口宏来定义一个代理类,那这个代理类最终转换成一个真实的类名呢,就是某某某proxy with internal。这样一个类名,由于这个类名啊,比较长。所以在接口宏中呢,还给它起了一个别名儿,就是某某某proxy,当我们把这个类展开之后呢,

你会发现它有几个方法?那第一个方法呢,就是create它是一个静态方法,就是通过create可以创建出某某某proxy with internal代理类对象。之后呢,我们就可以使用这个代理类了,那么在这个代理类中呢,包括了很多的method的方法,当然method它是可重载的,有不同的输入参数。在method内部,它使用了method后来生成一个后对象,那这个后对象呢,就是为了调用我们web rtc内部的这个真实的实现类。它是这个作用,

那么在这个q对象创建成功之后呢,再调用它的marshal方法,那最终呢,经过一系列的里边儿的运转,就可以调到这个时间类了。那这个还是比较有意思的一个过程,那在后边的课程中呢,我会向你做详细的介绍,那现在我们只要知道通过接口宏之后进行宏展开,就会生成这样一个代理类。以及代理类中有哪些方法,那当然它还有一个重要的成员,就是实现类的一个指针。通过这个成员来指向实现类,那这样呢,

它才能在内部去调用实现类中的方法。这就是接口类的一个类关系图,那下面呢?我们就来看看具体它这红是如何展开的,还是以我们上节课中的peer connection factory这个类为例。

为一个例子,我们来看一下刚才定义的peer connection factory这个代理类,它展开之后是什么样子?

展开的第一步呢就是将peer connection factory proxy with internal给它起一个别名,因为这个名字太长了。那我们在写代码的时候呢,就非常的费劲,所以它会怎么做呢?会将前面的这个类名后边加一个proxy的后缀。作为它的别名,

这样我们书写起来会方便一些,少写很多字母,那对于类的定义呢?它还是先要写一个proxy with internal这样一个类名。之后呢,让它继承自interface,也就是我们自己手工编写的这个接口类,当它继承了这个接口之后,后边它再调用具体的实现类的时候,就会非常方便。因为他知道都有哪些方法了,这是它继承自interface的一个主要作用,那在这个类的内部,它会实现很多方法。比较重要的呢是有两个,

第一个呢是create,这个create是一个静态方法,也就是说通过代理类的create方法就可以发现出某某proxy with internal这样一个代理类的对象。那有了这个对象之后就可以调用它里边的method方法,当然method方法呢,它是一个重载的。可以通过不同的参数进行区分,这刚才我们已经介绍过了,那在method内部呢?会创建method q对象。之后呢,调用marshal方法,最终调用到实现类的具体方法,那这些呢,我们都会在后边儿向你做详细介绍整个过程,

它是怎么运转起来的?除了这两个重要的方法之外,那它还有几个重要成员,其中signaling thread和worker thread是关于线程的两个成员。那除此之外呢,最为关键的是peer connection factory指针,也就是说通过c下划线指向了它具体实现类的对象。那所以这个c下划线是非常关键的,那么在method方法中只有通过指向实现类的这个指针才能调到实现类中的相应方法。否则的话,我们是没法找到具体的实现方法的,那这个呢,就是peer connection factory代理类的一个展开。那么展开之后,我们看这个代码就比较亲切了,

当然这与我们手写的代码还是有一定的差别,这个名字特别的长。但由于是机器产生的,为了防止与人血的发生冲突,所以它就使用了这样一个非常长的名字来减少这个冲突。那了解了这个红展开之后,后面我们再介绍整个它调用的过程的时候你就不会觉得很晕了。否则的话,如果我们不了解这个宏定义,不了解宏展开,不了解它在整个编译过程中是在预编译时进行宏展开的。你对web rtc接口的调用理解起来就会非常困难,那以上呢,就是我们这节课所要介绍的内容。那这节课中呢?

主要是向你介绍web rtc,为什么要这样设计接口?这样设计接口的好处是什么?以及当我们使用接口宏,定义好代理类之后,它展开之后的样子是什么样的?了解了这些之后呢,才能让我们更好的理解外拔接口它的调用过程是怎样的?那我们今天的课呢?就到这里,谢谢。

相关推荐
红米饭配南瓜汤3 小时前
WebRTC服务质量(09)- Pacer机制(01) 流程概述
网络·音视频·webrtc
玩电脑的辣条哥2 天前
aioice里面candidate固定UDP端口测试
python·网络协议·udp·webrtc
玩电脑的辣条哥3 天前
本地部署webrtc应用怎么把http协议改成https协议?
http·https·webrtc
m0_748235613 天前
WebRTC搭建与应用(一)-ICE服务搭建
webrtc
m0_748230944 天前
websocket 局域网 webrtc 一对一 多对多 视频通话 的示例
websocket·音视频·webrtc
dualven_in_csdn4 天前
【zlm】 webrtc源码讲解三(总结)
webrtc
web147862107234 天前
【WebRTC】视频发送链路中类的简单分析(上)
websocket·音视频·webrtc
红米饭配南瓜汤6 天前
WebRTC服务质量(05)- 重传机制(02) NACK判断丢包
网络·音视频·webrtc
红米饭配南瓜汤6 天前
WebRTC服务质量(06)- 重传机制(03) NACK找到真正的丢包
网络·音视频·webrtc·媒体
m0_748233367 天前
深入浅出WebRTC—ULPFEC
webrtc