一、什么是WebRTC

WebRTC，網(wǎng)頁即時通訊（Web Real-Time Communication），是直接在 Web 瀏覽器內(nèi)驅(qū)動實時通信（語音、視頻和任意數(shù)據(jù)）方法的API。它于2011年6月1日開源并在Google、Mozilla、Opera支持下被納入萬維網(wǎng)聯(lián)盟的W3C推薦標(biāo)準(zhǔn)，并于 2011 年標(biāo)準(zhǔn)化，是谷歌開源的一款產(chǎn)品。

WebRTC 實現(xiàn)了瀏覽器快速的實時通信，它允許網(wǎng)絡(luò)應(yīng)用或者站點在不借助中間媒介的情況下，建立瀏覽器之間點對點 (Peer-to-Peer) 的連接，實現(xiàn)視頻流和音頻流或者其他任意數(shù)據(jù)的傳輸。WebRTC 包含的這些標(biāo)準(zhǔn)使用戶在無需安裝任何插件或者第三方的軟件的情況下，使創(chuàng)建點對點 (Peer-to-Peer) 的數(shù)據(jù)分享和電話會議成為可能。

二、WebRTC架構(gòu)

從圖中可以看出整個 WebRTC 架構(gòu)設(shè)計大致可以分為以下 3 部分：

1. 紫色提供給 Web 前端開發(fā)使用的 API
2. 藍(lán)色實線部分提供各大瀏覽器廠商使用的 API
3. 藍(lán)色虛線部分包含 3 部分：音頻引擎、視頻引擎、網(wǎng)絡(luò)傳輸 (Transport)。都可以自定義實現(xiàn)

主要的工作包括：

（1）音視頻的編解碼（VP8/VP9/AV1）

（2）抗丟包和擁塞控制

（3）回聲和噪音消除

WebRTC一個很大的作用就體現(xiàn)在這里了——提供可靠的傳輸、優(yōu)質(zhì)的編解碼以及回聲問題消除，P2P連接這種實時多媒體傳輸功能直接內(nèi)嵌到瀏覽器里面，對于開發(fā)人員來說無疑大大地提高了開發(fā)效率。

1. WebRTC的主要組成

（1）getUserMedia是負(fù)責(zé)獲取用戶本地的多媒體數(shù)據(jù)，如調(diào)起攝像頭錄像等。

（2）RTCPeerConnection是負(fù)責(zé)建立P2P連接以及傳輸多媒體數(shù)據(jù)。

（3）RTCDataChannel是除音視頻數(shù)據(jù)之外的任何其它數(shù)據(jù)

三、WebRTC通話流程

首先思考的問題：兩個不同網(wǎng)絡(luò)環(huán)境的（具備攝像頭/麥克風(fēng)多媒體設(shè)備的）瀏覽器，要實現(xiàn)點對點 的實時音視頻對話，需要經(jīng)歷哪些過程呢 ？

通過上面的流程圖可以總結(jié)出一下幾點：

1. peerConnnection 建立之前必須交換兩個信息：SDP 和 iceCandidate；
2. Answer 端接收到 Offer 后才會創(chuàng)建 PeerConnection 對象；
3. Offer 端在創(chuàng)建成功本地 Offer 后才會去收集本地 iceCandidate；Answer 端在創(chuàng)建成功本地 Answer 后才會去收集本地 iceCandidate；
4. peerConnection 兩端都收到 iceCandidate 后才完成 peerConnection 的建立。

1. MediaStream

1.1 獲取音視頻設(shè)備

WebRTC獲取所有音視頻設(shè)備的API：enumerateDevices

 navigator.mediaDevices.enumerateDevices()
.then(successFunction)
.catch(failureFunction)

1.2 獲取音視頻流

使用WebRTC的getUserMedia實現(xiàn)獲取視頻和音頻，方法很簡單，如下代碼所示：

window.navigator.mediaDevices
  .getUserMedia({video: true})
  .then(mediaStream => {
  // 畫到一個video元素上面
  $('video')[0].srcObject = mediaStream;
});

1.3 獲取屏幕共享（錄制）視頻流

如果想實現(xiàn)錄屏（屏幕共享）的話，使用getDisplayMedia

navigator.mediaDevices
    .getDisplayMedia({video:true})

詳細(xì)API請查看官方文檔

2. RTCPeerConnection

peerconnection是webrtc面向外面的音視頻交互的統(tǒng)一接口，可以理解為一個功能特別強大的socket接口，里面保存了實時交互的所有信息，同時音視頻的轉(zhuǎn)發(fā)與接收也是通過peerconnection來完成，在通話的每一端都至少有一個 RTCPeerConnection 對象。在 WebRTC 中它負(fù)責(zé)與各端建立連接，接收、發(fā)送音視頻數(shù)據(jù)，并保障音視頻的服務(wù)質(zhì)量。

2.1 RTCPeerConnection 作用

我們把發(fā)起 WebRTC 通信的兩端被稱為對等端，即是 Peer。所謂點對點通信（peer-to-peer）則是說兩個客戶端直連，發(fā)送數(shù)據(jù)不需要中間服務(wù)器，建立成功的連接則稱為PeerConnection，而一次 WebRTC 通信可包含多個 PeerConnection。

RTCPeerConnection 則是創(chuàng)建點對點連接的 API，代表一個由本地計算機到遠(yuǎn)端的 WebRTC 連接。該接口提供了創(chuàng)建，保持，監(jiān)控，關(guān)閉連接的方法的實現(xiàn)。

2.2 RTCPeerConnection API

創(chuàng)建兩個連接實例

const peerA = new RTCPeerConnection()
const peerB = new RTCPeerConnection()

• pc.createOffer：創(chuàng)建 offer 方法，方法會返回 SDP Offer 信息
• pc.setLocalDescription 設(shè)置本地 SDP 描述信息
• pc.setRemoteDescription：設(shè)置遠(yuǎn)端的 SDP 描述信息，即對方發(fā)過來的 SDP 信息
• pc.createAnswer：遠(yuǎn)端創(chuàng)建應(yīng)答 Answer 方法，方法會返回 SDP Offer 信息
• pc.ontrack：設(shè)置完遠(yuǎn)端 SDP 描述信息后會觸發(fā)該方法，接收對方的媒體流
• pc.onicecandidate：設(shè)置完本地 SDP 描述信息后會觸發(fā)該方法，打開一個連接，開始運轉(zhuǎn)媒體流
• pc.addIceCandidate：連接添加對方的網(wǎng)絡(luò)信息
• pc.setLocalDescription：將 localDescription 設(shè)置為 offer，localDescription 即為我們需要發(fā)送給應(yīng)答方的 sdp，此描述指定連接本地端的屬性，包括媒體格式

2.3 適配各種瀏覽器

一般情況下，還會在顯示頁面中添加一個叫做 adapter.js 的腳本，它的作用是為各種瀏覽器都提供統(tǒng)一的、最新的 WebRTC API 接口。

<script src="https://WebRTC.github.io/adapter/adapter-latest.js"> </script>

3. RTCDataChannel

非音視頻數(shù)據(jù)都是通過 RTCDataChannel 進(jìn)行傳輸，是 WebRTC 中專門用來傳輸非音視頻數(shù)據(jù)的類，RTCDataChannel 支持的數(shù)據(jù)類型也非常多，包括：字符串、Blob、ArrayBuffer 以及 ArrayBufferView。數(shù)據(jù)通道 (DataChannel) 接口表示一個在兩個節(jié)點之間的雙向的數(shù)據(jù)通道，該通道可以設(shè)置成可靠傳輸或非可靠傳輸。

var pc = new RTCPeerConnection(); // 創(chuàng)建 RTCPeerConnection 對象
var dc = pc.createDataChannel("dc", options); //創(chuàng)建 RTCDataChannel對象 參數(shù)1: 標(biāo)簽名稱 參數(shù)2: 配置項

options 配置項

• ordered： 消息的傳遞是否有序
• maxPacketLifeTime：重傳消息失敗的最長時間
• maxRetransmits：重傳消息失敗的最大次數(shù)
• protocol：用戶自定義的子協(xié)議，默認(rèn)為空
• negotiated：如果為 true，則會刪除另一方數(shù)據(jù)通道的自動設(shè)置。這也意味著你可以通過自己的方式在另一側(cè)創(chuàng)建具有相同 ID 的數(shù)據(jù)通道
• id：當(dāng) negotiated 為 true 時，允許你提供自己的 ID 與 channel 進(jìn)行綁定

除了上面介紹的三個對象，在 WebRTC 中還有兩個重要過程，就是媒體協(xié)商和網(wǎng)絡(luò)協(xié)商。

4. 媒體協(xié)商和網(wǎng)絡(luò)協(xié)商的交換通道

1. 信令

信令是在兩個設(shè)備之間發(fā)送控制信息以確定通信協(xié)議、信道、媒體編解碼器和格式以及數(shù)據(jù)傳輸方法以及任何所需的路由信息的過程。

2. 信令服務(wù)器

客戶端協(xié)商媒體信息 (SDP) 和網(wǎng)絡(luò)信息 (candidate) 交換，就需要一個服務(wù)器，我們稱之為信令服務(wù)器，真實應(yīng)用中還會處理房間管理 、人員進(jìn)出房間等功能。

5. 媒體協(xié)商

我們首先要知道的是，不同瀏覽器對于音視頻的編解碼能力是不同的。比如: Peer-A 端支持 H264、VP8 等多種編碼格式,而 Peer-B 端支持 H264、VP9 等格式。為了保證雙方都可以正確的編解碼，最簡單的辦法即取它們所都支持格式的交集-H264。

在 WebRTC 中，有一個專門的協(xié)議，稱為Session Description Protocol(SDP),可以用于描述上述這類信息。因此參與音視頻通訊的雙方想要了解對方支持的媒體格式，必須要交換 SDP 信息。而交換 SDP 的過程，通常稱之為媒體協(xié)商。

5.1 媒體協(xié)商流程

這里以在兩個前端瀏覽器建立通訊來進(jìn)行說明，我們暫且稱“發(fā)起端”和“應(yīng)答端”。

（1）首先雙方連接信令通道，（一般由業(yè)務(wù)決定如何實現(xiàn)），并能交換信令。

（2）發(fā)起端調(diào)用 RTCPeerConnection.createOffer 創(chuàng)建一個offer，并調(diào)用 setLocalDescription 設(shè)置本地SDP。

（3）然后通過信令服務(wù)器 將含有 SDP 的 offer 設(shè)置給應(yīng)答端。

（4）應(yīng)答端拿到此 offer 以后調(diào)用 setRemoteDescription 將此 SDP 信息保存。

（5）應(yīng)答端調(diào)用 RTCPeerConnection.createAnswer 創(chuàng)建一個 answer，并調(diào)用 setLocalDescription 設(shè)置本地SDP。

（6）通過信令服務(wù)器將含有 SDP 的 answer 發(fā)送給發(fā)起端。

（7）發(fā)起端調(diào)用 setRemoteDescription 將此 SDP 信息保存。

簡單概括就是：發(fā)起端和應(yīng)答端通過 creatOffer 和 createAnswer 創(chuàng)建 offer/answerSDP，然后通過信令服務(wù)互換，最后調(diào)用 setLocalDescription/setRemoteDescription 進(jìn)行設(shè)置本地和遠(yuǎn)端的 SDP 以完成協(xié)商。

在雙方都創(chuàng)建 RTCPeerConnection 之后,它們就可以開始進(jìn)行媒體協(xié)商了。

5.2 SDP信息內(nèi)容

v=0 o=- 3409821183230872764 2 IN IP4 127.0.0.1
 ... 
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126 
...
a=rtpmap:111 opus/48000/2 
a=rtpmap:103 ISAC/16000 
a=rtpmap:104 ISAC/32000 
...

如上面的 SDP 片段所示，該 SDP 中描述了一路音頻流，即m=audio，該音頻支持的 Payload ( 即數(shù)據(jù)負(fù)載 ) 類型包括 111、103、104 等等。

在該 SDP 片段中又進(jìn)一步對 111、103、104 等 Payload 類型做了更詳細(xì)的描述，如 a=rtpmap:111

opus/48000/2 表示 Payload 類型為 111 的數(shù)據(jù)是 OPUS 編碼的音頻數(shù)據(jù)，并且它的采樣率是 48000，使用雙 聲道。以此類推，你也就可以知道 a=rtpmap:104 ISAC/32000 的含義是音頻數(shù)據(jù)使用 ISAC 編碼，采樣頻率 是 32000，使用單聲道。

6. 網(wǎng)絡(luò)協(xié)商

6.1 ICE

當(dāng)媒體協(xié)商完成后，WebRTC 就開始建立網(wǎng)絡(luò)連接，其過程稱為 ICE（Interactive Connectivity Establishment）交互式連接建立。

ICE 不是一種協(xié)議，整合了 STUN 和 TURN 兩種協(xié)議（用于 NAT 穿透）的框架。

ICE 是在各端調(diào)用 setLocalDescription() 后就開始了，其操作過程如下：

1. 收集 Candidate
2. 交換 Candidate
3. 按優(yōu)先級嘗試連接

在說完上述一些生僻的概念，我來逐一解釋下涉及到的東西

6.1.1 什么是 Candidate？
比如想用 socket 連接某臺服務(wù)器，一定要知道這臺服務(wù)器的一些基本信息，如服務(wù)器的 IP 地址、端口號以及使用的傳輸協(xié)議。只有知道了這些信息，才能與這臺服務(wù)器建立連接。而 Candidate 正是 WebRTC 用來描述它可以連接的遠(yuǎn)端的基本信息，因此 Candidate 是至少包括 IP 地址、端口號、協(xié)議的一個信息集。

6.1.2 收集 Candidate
在 WebRTC 中有三種類型的 ICE 候選者（Candidate）：

主機候選者：表示網(wǎng)卡自己的 IP 地址及端口。通過設(shè)備網(wǎng)卡獲取，優(yōu)先級最高。在 WebRTC 底層首先會嘗試本地局域網(wǎng)內(nèi)建立連接。

反射候選者：表示經(jīng)過 NAT 之后的外網(wǎng) IP 地址和端口，由 ICE（STUN）服務(wù)器獲取，根據(jù)服務(wù)器的返回情況，來綜合判斷并知道自身在公網(wǎng)中的地址。其優(yōu)先級低于主機候選者，當(dāng) WebRTC 嘗試本地連接不通時，會嘗試通過反射候選者獲得的 IP 地址和端口進(jìn)行連接。

中繼候選者：表示的是中繼(TURN)服務(wù)器的轉(zhuǎn)發(fā) IP 地址與端口，由 ICE 中繼服務(wù)器提供。優(yōu)先級最低，前兩個都不行則會按該種方式。
在新建RTCPeerConnection時可在構(gòu)造函數(shù)指定 ICE 服務(wù)器地址，沒有指定的話則意味著這個連接只能在內(nèi)網(wǎng)進(jìn)行。

每次 WebRTC 找到/收集一個可用的 Candidate，都會觸發(fā)一次icecandidate事件，為了將收集到的 Candidate 交換給對端，需要給onicecandidate方法設(shè)置一個回調(diào)函數(shù)，函數(shù)里面調(diào)用addIceCandidate方法來將候選者添加到通信中。

如下代碼，通過該回調(diào)函數(shù)就可以獲得 WebRTC 底層收集到的所有 Candidate 了。同時，還可以在該函數(shù)中將收集到的 Candidate 發(fā)送給對端。

peer.onicecandidate = (event) => {
  if (event.candidate) {
    // ...
  }
}

// 接收到信令服務(wù)器發(fā)送過來的候選信息后調(diào)用，為本機添加 ICE 代理
peer.addIceCandidate(candidate)

6.1.3 交換 Candidate
WebRTC 收集好 Candidate 后，會通過信令系統(tǒng)將它們發(fā)送給對端。對端接收到這些 Candidate 后，會與本地的 Candidate 形成 CandidatePair（即連接候選者對）。有了 CandidatePair，WebRTC 就可以開始嘗試建立連接了。這里需要注意的是，Candidate 的交換不是等所有 Candidate 收集好后才進(jìn)行的，而是邊收集邊交換。

CandidatePair，候選者對，即一個本地 Candidate，一個遠(yuǎn)端 Candidate
當(dāng) WebRTC 形成 CandidatePair 后，便開始嘗試進(jìn)行連接。一旦 WebRTC 發(fā)現(xiàn)其中有一個可以連通的 CandidatePair 時，它就不再進(jìn)行后面的連接嘗試了，但發(fā)現(xiàn)新的 Candidate 時仍然可以繼續(xù)進(jìn)行交換。

彼此要了解對方的網(wǎng)絡(luò)情況，這樣才有可能找到一條相互通訊的鏈路

先說結(jié)論：(1)獲取外網(wǎng)IP地址映射；（2）通過信令服務(wù)器（signal server）交換"網(wǎng)絡(luò)信息"

理想的網(wǎng)絡(luò)情況是每個瀏覽器的電腦都是私有公網(wǎng)IP，可以直接進(jìn)行點對點連接。

實際情況是：我們的電腦和電腦之前或大或小都是在某個局域網(wǎng)中，需要NAT（網(wǎng)絡(luò)地址轉(zhuǎn)換）打洞，顯示情況如下圖：

為了實現(xiàn)客戶端的點到點連接（數(shù)據(jù)不需經(jīng)過服務(wù)器轉(zhuǎn)發(fā)），RTCPeerConnection做了很多工作。首先需要解決的問題是局域網(wǎng)穿透。

6.1.NAT穿墻打洞

要建立一個連接需要知道對方的IP地址和端口號，在局域網(wǎng)里面一臺路由器可能會連接著很多臺設(shè)備，例如家庭路由器接入寬帶的時候?qū)拵Х?wù)商會分配一個公網(wǎng)的IP地址，所有連到這個路由器的設(shè)備都共用這個公網(wǎng)IP地址。如果兩臺設(shè)備都用了同一個端口號創(chuàng)建套接字去連接服務(wù)，這個時候就會沖突，因為對外的IP是一樣的。因此路由器需要重寫IP地址/端口號進(jìn)行區(qū)分，如下圖所示：

有兩臺設(shè)備分別用了相同的端口號建立連接，被路由器轉(zhuǎn)換成不同的端口，對外網(wǎng)表現(xiàn)為相同IP地址不同端口號，當(dāng)服務(wù)器給這兩個端口號發(fā)送數(shù)據(jù)的時候，路由器再根據(jù)地址轉(zhuǎn)換映射表把數(shù)據(jù)轉(zhuǎn)發(fā)給相應(yīng)的主機。

所以當(dāng)你在本地監(jiān)聽端口號為55020，但是對外的端口號并不是這個，對方用55020這個端口號是連不到你的。這個時候有兩種解決方法，第一種是在路由器設(shè)置一下端口映射，如下圖所示：

上圖的配置是把所有發(fā)往8123端口的數(shù)據(jù)包到轉(zhuǎn)到192.168.123.20這臺設(shè)備上。

但是我們不能要求每個用戶都這么配他們的路由器，因此就有了穿墻打洞，基本方法是先由服務(wù)器與其中一方（Peer）建立連接，這個時候路由器就會建立一個端口號內(nèi)網(wǎng)和外網(wǎng)的映射關(guān)系并保存起來，如上面的外網(wǎng)1091就可以打到電腦的55020的應(yīng)用上，這樣就打了一個洞，這個時候服務(wù)器把1091端口加上IP地址告訴另一方（Peer），讓它用這個打好洞的地址進(jìn)行連接。這就是建立P2P連接穿墻打洞的原理，最早起源于網(wǎng)絡(luò)游戲，因為打網(wǎng)絡(luò)游戲經(jīng)常要組網(wǎng)，WebRTC對NAT打洞進(jìn)行了標(biāo)準(zhǔn)化。

這個的有效性受制于用戶的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，因為如果路由器的映射關(guān)系既取決于內(nèi)網(wǎng)的IP + 端口號，也取決于服務(wù)器的IP加端口號，這個時候就打不了洞了，因為服務(wù)器打的那個洞不能給另外一個外網(wǎng)的應(yīng)用程序使用（會建立不同的映射關(guān)系）。相反如果地址映射表只取決于內(nèi)網(wǎng)機器的IP和端口號那么是可行的。打不了洞的情況下WebRTC也提供了解決方法，即用一個服務(wù)器轉(zhuǎn)發(fā)多媒體數(shù)據(jù)。

6.2. STUN

STUN（Session Traversal Utilities for NAT，NAT會話穿越應(yīng)用程序）是一種網(wǎng)絡(luò)協(xié)議，它允許位于NAT（或多重 NAT）后的客戶端找出自己的公網(wǎng)地址，查出自己位于哪種類型的NAT之后以及NAT為某一個本地端口所綁定的 Internet端端口。這些信息被用來在兩個同時處于NAT路由器之后的主機之間創(chuàng)建UDP通信。該協(xié)議由RFC 5389定 義。

在遇到上述情況的時候，我們可以建立一個STUN服務(wù)器，這個服務(wù)器做什么用的呢？主要是給無法在公網(wǎng)環(huán)境下的 視頻通話設(shè)備分配公網(wǎng)IP用的。這樣兩臺電腦就可以在公網(wǎng)IP中進(jìn)行通話。

使用一句話說明STUN做的事情就是：告訴我你的公網(wǎng)IP地址+端口是什么。搭建STUN服務(wù)器很簡單，媒體流傳輸是 按照P2P的方式。

那么問題來了，STUN并不是每次都能成功的為需要NAT的通話設(shè)備分配IP地址的，P2P在傳輸媒體流時，使用的本地帶寬，在多人視頻通話的過程中，通話質(zhì)量的好壞往往需要根據(jù)使用者本地的帶寬確定。那么怎么辦？TURN可以 很好的解決這個問題。

6.3. TURN

TURN的全稱為Traversal Using Relays around NAT，是STUN/RFC5389的一個拓展，主要添加了Relay功能。如果終端在NAT之后， 那么在特定的情景下，有可能使得終端無法和其對等端（peer）進(jìn)行直接的通信，這時就需要公網(wǎng)的服務(wù)器作為一個中繼， 對來往的數(shù)據(jù)進(jìn)行轉(zhuǎn)發(fā)。這個轉(zhuǎn)發(fā)的協(xié)議就被定義TURN。

在上圖的基礎(chǔ)上，再架設(shè)幾臺TURN服務(wù)器：

在STUN分配公網(wǎng)IP失敗后，可以通過TURN服務(wù)器請求公網(wǎng)IP地址作為中繼地址。這種方式的帶寬由服務(wù)器端承擔(dān)，在多人視頻聊天的時候，本地帶寬壓力較小，并且，根據(jù)Google的說明，TURN協(xié)議可以使用在所有的環(huán)境中。 （單向數(shù)據(jù)200kbps 一對一通話）

四、WebRTC存在的問題

WebRTC 是一個非常優(yōu)秀的項目，但如果直接拿來使用也存在以下問題。

1、WebRTC 使用的是對點對傳輸，雖然節(jié)約了服務(wù)器資源的開銷，但實際使用時也帶來了傳輸質(zhì)量的問題，比如跨國以及跨運營商網(wǎng)絡(luò)之間的傳輸質(zhì)量往往很難保證，雖然 webRTC 有優(yōu)秀的端對端質(zhì)量控制算法，但在錯綜復(fù)雜的網(wǎng)絡(luò)條件下，表現(xiàn)也很難讓人滿意。

2、WebRTC 在移動端的表現(xiàn)也很難讓人滿意。早期由于缺少對于 H.264 編解碼器的支持，使得移動端很長一段時間只能使用 VP8 軟件編解碼，導(dǎo)致在中低端手機上的表現(xiàn)較差，加上安卓自身碎片化的屬性，如果不針對不同機型做適配，很難有統(tǒng)一的用戶體驗。

3、WebRTC 是為 1 對 1 通信場景設(shè)計的，如果要實現(xiàn)多人的場景，還是需要借助服務(wù)端方案。即使當(dāng)前有很多開源的 webRTC 服務(wù)器實現(xiàn)，一個流媒體中轉(zhuǎn)服務(wù)器或者混流服務(wù)器的部署以及維護(hù)也是非常復(fù)雜的。

4、在 Web 端需要面臨不同瀏覽器之間的兼容性問題。雖然使用 AdapterJS 可以解決不同瀏覽器之間的接口適配問題，但除此之外依然要面臨不同瀏覽器行為不一致的問題?？梢哉f如果 WebRTC 如果直接拿過來商用的話，幾乎是不太可能的，當(dāng)下普遍的解決方案是自研，根據(jù)自身的業(yè)務(wù)場景進(jìn)行二次定制開發(fā)，或者更簡單一點使用第三方 SDK。文章來源地址http://www.zghlxwxcb.cn/news/detail-405303.html

到了這里，關(guān)于WebRTC音視頻原理的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！