webrtc学习笔记五：Webrtc运行机制

一、首先看两个概念：轨与流。

1.轨：Track。比如一路音频就是一路轨，一路视频也是一路轨，这里的轨就是采取了轨道的概念，两条轨道是永远不相交的，音频与视频是不相交的，单独存放。两路音频其实也是两路轨，也是不相交的。
2.媒体流MediaStream。借鉴了传统的媒体流的概念，在传统的媒体流里也包括了音频轨、视频轨、字母轨。这里主要有一个层级的概念。在媒体流里包含了很多轨，这样形成一个层级的概念之后，后续的知识就比较好理解了。

二、Webrtc重要类：

1.MediaStream类，媒体流。
2.RTCPeerConnection类，是整个webrtc里最终要的一个类，因为这个类是一个大而全的一个类，里面包含了很多的功能。那么这样设计有什么好处呢？对于应用层来说就特别的方便，在应用层只需要创建了一个RTCPeerConnection，也就是创建这一个连接，将MediaStream流塞到这个连接里去就不用管其他的了，其他所有的底层传输、寻路等等，全都会由RTCPeerConnection内部去执行了。所以对于应用层来说非常方便，当然在底层它肯定做了很多的工作。我们知道Webrtc主要采用的是P2P的传输，包括p2p的类型、检测、p2p是否能够打通、是否能够穿透成功，如果穿透不成功还需要通过TURN服务器去进行中转，等等这一系列的操作都是在RTCPeerConnection类里面做完了。所以，这就是为什么去看webrtc源码的时候发现非常复杂，而在应用层去使用的时候反而非常容易非常方便的原因。
所以在后续看webrtc源码的时候，或者局部逻辑的时候，可以首先从RTCPeerConnection这个类着手进行不断的深入。
3.RTCDataChannel类。这个类是非音视频数据都通过这个RTCDataChannel类进行传输，实际上RTCDataChannel是通过RTCPeerConnection获取的，所以他们之间是有关系的。像文本、二进制文件、二进制数据都可以通过RTCDataChannel进行传输，所以只需要拿到RTCDataChannel这个对象，将数据塞给RTCDataChannel对象，对于上层应用来说已经完成了。RTCDataChannel它在底层又走了很多的逻辑，对于上层应用来说是无需关心的。

所以，总结来说：RTCPeerConnection类是核心，MediaStream类里包含了很多轨，将这些轨添加到这个MediaStream类对象之后，将MediaStream类对象添加到RTCPeerConnection类对象之中去，底层就不用管了，它就会自动的传递到对端去了。
对于普通数据来说，比如传输二进制数据。首先通过RTCPeerConnection类对象获取RTCDataChannel类对象，然后其他也就不用管了，通过这个RTCDataChannel类就可以把非音视频数据的二进制数据传递到对端去了。

三、最核心的，RTCPeerConnection的调用过程：

能够从webrtc的官网找到这张调用流程图。

分析流程图：

看到Stream流，也就是MediaStream包含了很多轨，包括音频轨、视频轨等等，当然也可以只有一路音频一路视频。
接下来看PeerConnection,它内部有两个线程，一个是Worker thread，一个是Signaling thread，通过PeerConnectionFactory会创建这两个线程，PeerConnectionFactory实际上就是一个连接工厂，可以创建出很多PeerConnection，这个工厂会创建PeerConnection，还会创建LocalMediaStream和LocalVideoTracker/LocalAudioTracker。
这些创建流程里，首先是创建一个个的轨LocalVideoTracker/LocalAudioTracker通过AddTrack将这些轨添加到LocalMediaStream类媒体流对象中，当然这里可能有多个LocalMediaStream媒体流，但是，最终都通过AddStream将这些流添加到PeerConnection连接对象中，这里如果有多个流，这些流复用的是同一个PeerConnection连接对象。
需要注意的是，什么是多个流的状况呢？1:1的通讯只有1个流，流里面包含音频轨和视频轨。那多个流呢，就是可能有与多个人在通讯，与多方通讯，每一方实际就是一个stream，就会存在多个流。比如有一个音视频会议中， 同时又3方在进行通讯，那么每一方就是一个stream。

分析方法调用的时序图：

首先是application应用层会触发CreatePeerConnectionFactory；这样就创建出一个PeerConnectionFactory工厂；这个PeerConnectionFactory工厂又触发了CreatePeerConnection，然后创建了一个PeerConnection连接；这个PeerConnectionFactory还会去调用CreateLocalMediaStream,CreateLocalVideoTrack,CreateLocalAudioTrack，然后通过AddTrack将CreateLocalVideoTrack,CreateLocalAudioTrack这些轨添加到CreateLocalMediaStream中去；添加完之后再触发AddStream将这个流添加到PeerConnection这个连接中去；流添加完之后会提交流的变化，当流发生变化的时候，会提交触发一个事件，也就是CommitStreamChanges，触发的这个事件干什么呢？会创建一个offer的SDP的描述信息；有了这个offer SDP描述信息之后，就会在应用层通过信令发送到了远端了，在对端就会收到这个offer SDP描述信息。这个描述信息都包含哪些信息呢？包含有哪些音频、有哪些视屏、音频格式是什么、视屏格式是什么、传输地址是什么，这些信息就会全部收到了。根据这些信息，远端会回复一个answer 的SDP给这个信令。信令与媒体流信息其实是两条路，一个（也就是信令）是通过TCP传输的，一个（也就是媒体流）是通过UDP传输的，这两条信路。信令收到answer之后就会传给PeerConnection连接对象；这个时候，这个PeerConnection连接就拿到了对方媒体流的信息以及它的传输端口、传输地址，这样他们之间就打通这个通道了。就可以相互的传递数据了，当远端的数据过来之后，这个PeerConnection连接会将远端的流添加到application中去，也就是OnAddStream。Application本身也是一个Connection Observer一个观察者，就是随时要知道这个Connection连接都发生了哪些事件。
通过这个时序图，就可以了解到一个api的完整调用过程。
以上就是webrtc的整个运行机制。