今天我們來介紹一下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的一個運行機制，大家有任何問題的話，可以在下方評論。