二、第三节 webrtc运行机制

今天我们来介绍一下WebRTC的运行机制，首先我们来看两个基本概念

轨与流

Track

MedisStream

我们此前介绍的一路音频就是一路轨，一路视频也是一路轨，这里的轨就是采取了轨道的概念，两条轨之间是永远不相交的，那么音频与视频是不相交的，单独存放。两路音频也是两路轨，也是不相交的。

第二个是流，借鉴了以前传统的媒体流的概念，在传统的媒体流里面也包括了音频轨、视频轨还有字幕轨，所以这里主要有个层级的概念，在媒体流里面包含了很多轨，这样形成一个层级的概念之后，我们再往下看的时候就比较好理解了。

我们再来看一下几个重要的类，第一个和我们刚看到的是同一个名字，也就是MediaStream，就是把它在WebRTC里面单独写了一个类，这里我们就不过多介绍了。

第二个是RTCPeerConnection，RTCPeerConnection是整个WebRTC里面最为重要的一个类，因为这个类是一个大而全的一个类，它里面包含了很多的功能，这样设计有什么好处呢？对于应用层来说，就特别的方面，在应用层我只要创建了一个PeerConnection,也就是创建了一个连接，我们将MediaStream也就是流设置到连接里去，那他所有底层的传输和寻路都由PeerConnection自己在内部执行了，其实对应用层来说，是一个非常好的消息。但是它在底层它做了很多工作，因为我们知道WebRTC主要采用的是P2P的传输，那包括你P2P的类型和检测，P2P是否能够打通，是否能穿透成功，如果穿透不成功，我门还需要通过turn服务器进行中转，这一系列的操作都是在PeerConnection的下面完成了。

所以我们在看WebRTC内部的代码的时候，其实非常的复杂，对于应用层的开发者来说，利用WebRTC去开发，其实会方便很多。

我们只要知道这个重要的一个类，还有一个我们自己的一个重要方法，就能完成我们自己的一个应用程序，所以PeerConnection是我们要重点要掌握的一个类，对应用层来说我们要知道它都有哪些功能。我们可以用哪些方法去增加我们应用的功能。

对于我们后面学习WebRTC底层代码的时候，我们也要重点关注这个PeerConnection，因为他是一个总的点，要去分析每一块的逻辑的时候都可以通过这个点一步一步的往下深入，当我遇到困难的时候，我们可以在回来在重新往下屡。

第三个是RTCDataChannel,DataChannel就是我们非音视频的数据，都通过DataChannel,进行传输，实际上DataChannel,是通过PeerConnection获取的，所以他们之间是有关系的，那像我们的文本、文件、二进制数据，都可以通过DataChannel进行传输，所以当我们拿到DataChannel这个对象之后，将数据塞给他，上层应用就算完成了。实际上在底层，它也走了很多的逻辑。

那么通过这个三个类，我们知道PeerConnection是核心，MediaStream包含了很多轨，将这些轨添加到一些Stram之后呢，将它添加到PeerConnection当中去，那么底层的就不用管了，他就自动传输到对应端去了，对于普通的数据来说 也是一样，我将二进制数据，首先我通过PeerConnection获取这个DataChannel，再把二进制数据塞到DataChannel中去，那么我们的非媒体数据非音视频数据也能正常的传输出去，传送到对端，这就是桑重要的类。4.41

下面我来看最核心的类也就是PeerConnection它的调用过程是怎么样的；

上图是从WebRTC官网截的，首先的是Stream流，也就是Media Stream，它包括了很多轨，包括了视频、音频……，当然也可以只有一路音频或者一路视频；接下来就是PeerConnection, Connection内部是有两个线程，一个 是Worker线程一个是Signaling线程，就是通过PeerConnectionFactoryInterface来创建两个线程，PeerConnectionFactory实际上就是个连接工厂了，他可以创造很多的PeerConnection，他不仅可以创建PeerConnection还可以创建MediaStream还可以创建LocalVideoTrack或LocalAudioTrack,创建之后首先是创建一个一个的轨，然后通过AddTrack将他们添加到MediaStream媒体流中去，那么可能有多个媒体流，最终都通过AddStream添加到PeerConnection中去，他们复用的是同一个连接，同一个Connection，当然在底层的话有可能是不同的路，那么在这里要注意的是什么是多个Stream，那么我们都清楚在我本机有可能有音频和视频，我塞到一个Stream里面去，那这个就是为什么一路会有多路Stream，那就是有可能是与多方通讯，那么每一方实际就是一个Stream，想想一下在一个音视频会议中，能有三方进行视频通讯，那么每一方就是一个Stream。

下面我们再来看看这几个方法的调用关系， 

首先是应用层会触发CreatePeerConnectionFactory,这样就创造出了PeerConnectionFactory这个工厂，那么这个工厂呢又触发了CreatePeerConnection，然后又创建了一个PeerConnection连接，这个工厂还会创建CreateLocalMediaStream、CreateLocalVideoTrack、CreateLocalAudioTrack这个轨，然后在通过AddTrack将这些 轨添加到Stream中去，添加完了之后在调用这个AddStream将这个流添加到PeerConnection连接中去，流提交好了之后会提交这个流的变化CommitStreamChanges，当这个流触发变化的时候，就会触发这个事件创建一个offer 的SDP的描述信息，有了这个描述 信息之后呢，通过应用层通过信令发送到远端，在这一端 收到这个offer SDP，SDP里面包括的信息有包括哪些视频哪些音频以及音频格式是什么视频格式是什么？你的传输地址是什么？这些信息实际就度过来了，根据这些信息远端会回一个answer给这个信令，信令与 我们媒体流的信息实际上是两条路，并不是通过TCP传输的，他是通过UDP传输的，那么这个信令收到这个answer之后就会传给这个connection，那这个连接就拿到了对方这个媒体流信息以及它的传输端口、传输地址，那么这样他们之间就打通这个通道了，可以相互的传这个媒体数据了，当远端的数据来了之后，这个Connection还会将远端的这个流添加到这个APP中去，那么APP它本身也是一个ConnectionObserver,这是一个观察者，其实要知道这个连接发生了哪些事件，那么通过这样一个时序图我们就了解了整个API的一个调用过程，那么以上呢就是我们整个webRTC的一个运行机制，大家有任何问题的话，可以在下方评论。