如何真正讓小程式,WebRTC和APP互通連麥直播
2017年12月，微信小程式向開發者開放了實時音視訊能力，給業內帶來廣闊的想象空間。連麥直播技術在2016年直播風口中成為視訊直播的標配，然而只有在原生的APP上才能保障良好的使用者體驗。那時候，在微信小程式中無法連麥直播。微信小程式在去年12月宣佈開放實時音視訊能力，再加上去年6月蘋果宣佈將支援WebRTC，業內一下子千樹萬樹梨花開，前途一片光明。連麥直播技術和微信小程式以及WebRTC能產生怎麼樣的化學作用？開發者在微信小程式或者瀏覽器WebRTC上實現連麥直播技術的時候，需要知道什麼和考慮什麼？
連麥直播的技術難點和解決思路
我們先回顧一下連麥互動直播技術，這個要從應用場景說起。
第一類應用場景就是最常見的視訊直播中的多主播連麥場景。
第二類應用場景是線上抓娃娃，或者叫直播抓娃娃，也是視訊直播的一個產品形態，視訊直播和物聯網的結合。線上抓娃娃技術除了包含視訊直播以外，還加上了信令的控制，可以實現遠端看著娃娃機並且控制抓娃娃的天車，同時主播和觀眾之間可以通過文字互動，還有語音視訊連麥互動。這是2017年年末的一個風口，把連麥互動直播技術帶到視訊直播和物聯網結合的場景中，相信今年會有更多視訊直播和物聯網結合的應用場景湧現。
第三類應用場景是直播答題，這是2018年1月份湧現的一股熱潮，是答題節目類在視訊直播場景中的探索。在低延遲、流暢和高清的基礎需求上，這個應用場景還要求答題題目和視訊畫面必須要同步。另外，花椒直播的直播答題房間內的使用者數量一度超過五百萬，因此直播答題技術必須要支援百萬級別的併發。雖然春節期間因為監管的原因增加了准入門檻，但是我相信後面還會有別的新的玩法出現。行業裡討論的一些新玩法在這裡也和大家分享一下：主持人可以邀請嘉賓連麥進行答題，參加直播答題的使用者可以建子房間組團答題。這些創新的玩法在技術上都是可以做到的，本質上這就是直播答題技術和連麥互動直播技術的結合。
這三個應用場景對視訊直播技術有什麼要求呢？
第一個是延遲要足夠低。如果單向延遲不能低於500毫秒的話，視訊通話的互動體驗就無法保障。
第二個是回聲消除。因為使用者A和使用者B之間進行視訊通話時，使用者A的聲音在傳到使用者B端時被採集並反饋回來，使用者A在一定的延遲後會聽到回聲，這個對通話的體驗是十分有影響的，因此必須做回聲消除。
第三個是要流暢不卡頓。為什麼流暢性很必要呢？因為有超低延遲的要求，流暢和延遲本身就是一對相互矛盾的技術要求，如果延遲足夠低的話就要求抖動緩衝區足夠的小，這樣網路抖動就很容易顯現出來，導致出現畫面過快、過慢，或者卡頓的情況。
下面我們來具體看看怎麼解決這三個視訊直播的核心技術要求。
一、超低延遲架構
市面上做連麥直播解決方案的系統架構普遍大概這個樣子，左邊是低延遲網路，為需要低延遲的使用者提供連麥互動直播服務，成本較高。右邊是內容分發網路，為圍觀使用者提供視訊直播服務，雖然延遲稍微高一點，但是成本比較低而且支援更高的併發。中間通過一個旁路服務連線。旁路伺服器從低延遲的實時網路中把音訊流和視訊流拉出來，有選擇地進行混流、格式轉換或者協議轉換等處理，然後轉推到內容分發網路，然後通過內容分發網路分發給圍觀使用者。
要構建超低延遲的實時系統架構，需要考慮以下幾個要點：
1、負載均衡- 超低延遲架構必須要做到負載均衡，也就是說任何一個網路節點都必須均衡地負載使用者。如果某一個網路節點的使用者訪問量超過了它能夠承載的上限，容易出現大量丟包的情況，這樣會觸發網路擁塞，從而引起更多的丟包，導致使用者體驗不好。
2、就近接入- 網路上的“近”和我們理解的直線上的近是不一樣的。這個可以類比為交通網路，假設開車的時候看到另外一個點離你近，但實際上可能不一定近，要考慮一下兩點：第一點是連通性，儘管A、B兩點看起來很近，但是從A點到B點是沒有直通的道路，這就相當於網路的不連通。第二點是擁堵狀況，如果道路很短，但出現擁堵，那也不見得近。比如說，迪拜使用者和北京的使用者連麥，看起來直接從迪拜推流到北京是最近的，可是實際上這個直接的路徑可能是不通的，那麼需要繞道香港進行中繼續傳，走一個彎路，在網路上的距離可能會“更近”。
3、質量評估- 質量評估中的靜態方法是事後評估，具體是回顧過去的資料，分析某一個地區的使用者在各個時間點推流到某個地區的資料，總結出哪個時間點走哪個路徑比較好的方案，然後人為地將相關資料配置到實時傳輸到網路，可以提高傳輸質量。
4、動態路由- 質量評估的另外一個方法是動態評估，也就是根據歷史資料動態地進行質量評估。傳輸網路在運作一段時間後會積累很多使用者資料，比如說深圳的使用者在早上、中午、晚上不同的網路情況下推流到北京的最優路徑，這些資料積累下來，可以為動態地制定路由策略作依據，這就是動態路由。
5、演算法流控- 在實時傳輸網路中，我們要選出一條最優的路徑進行推流。如果這個最優路徑還達不到超低延遲的要求，這個時候我們要在演算法上做一些補償，例如通道的保護，通過增加冗餘，保護信道里的資料。還有在推流時做一些流控策略，上行網路中，如果檢測到網路抖動，或者說弱網情況的話，就降低位元速率，網路情況變好的話，就把位元速率提高。下行網路中，可以通過分層編碼為不同網路環境的使用者選擇不同位元速率的視訊流。
二、回聲消除
什麼是回聲？舉個例子，假如你是近端的使用者，接收到遠端使用者的聲音，這個聲音通過喇叭播放出來，會在房間裡面發生傳播，被天花板、地面和窗戶等反射後，連同你的聲音一起被麥克風採集進去，再傳到遠端。遠端使用者在一兩秒的延遲後，會再次聽到自己的聲音，這對遠端使用者來說就是回聲。為了保障使用者體驗，必須要做回聲消除。對於音視訊引擎來講，麥克風採集進來的聲音裡包含了遠端使用者的回聲和近端使用者真實的聲音是很難區分的：這兩個聲波都是從空氣中採集進來的沒有差別的聲音，有點像藍墨水和紅墨水混在一起，很難分開一樣。
那就沒辦法了嗎？其實我們還是有一些辦法的。遠端傳過來的原音是參考訊號，它和回聲訊號雖然相關，但是並不完全一樣。如果直接把麥克風採集進來的聲音減去原音是不對的。因為回聲是參考訊號播放出來以後，在空氣中經過反彈和疊加以後形成的，和參考訊號有相關性，但不等同。我們可以理解為回聲訊號和參考訊號有一定函式關係，而我們需要做的就是把這個函式關係求解出來。通過參考訊號作為函式的輸入，模擬出回聲訊號，再把麥克風採集到的聲音訊號減去模擬回聲訊號，最終達到回聲消除的目的。我們是通過濾波器來實現這個函式，濾波器會不斷的學習和收斂，模擬回聲訊號，使模擬回聲儘量逼近回聲訊號，然後將麥克風採集進來的聲音訊號減去模擬回聲訊號，達到回聲消除的目的。這個步驟也稱為線性處理。
回聲有三種場景型別：靜音，單講和雙講。對於單講（也就是一個人講話）來說，線性處理後抑制的效果會比較好，回聲消除得比較乾淨。對於雙講（也就是多人同時講話）來說，線性處理後抑制的效果就不是那麼好，這時就需要採取第二個步驟：非線性處理，把剩餘的回聲消除乾淨。非線性處理沒有太多開源的東西作為參考，要靠各家廠商自己去研究，十分能體現各家廠商的技術積累。
三、抖動緩衝
網路存在擁塞、丟包、亂序和抖動，因此網路傳輸會帶來資料損傷。特別是使用基於UDP的私有協議來傳輸語音視訊資料的時候，需要做抖動緩衝。以WebRTC為例，對音訊資料的抖動緩衝叫NetEQ，對視訊資料的緩衝叫做JitterBuffer，都是WebRTC開源專案中十分有價值的部分。抖動緩衝就是對資料包進行緩衝排序，對丟包和亂序這些網路情況進行補償，來保障流暢性。抖動緩衝的佇列長度本質上就是佇列延遲時間，如果太長的話延遲就很大，太短的話抖動就會被顯現出來，使用者體驗就不好。有關抖動緩衝區長度的設定，每一個廠商做法不一樣，有的是將網路報文的抖動時間的最大方程作為緩衝佇列的長度。這是一個開放的話題，需要各家廠商自己去思考。
我們在這裡做一個階段小結，從推流端到拉流端，整個流程包括了七個環節：採集、前處理、編碼、推流、拉流、解碼和渲染。那我們一起來看看上面三個技術難點分別在哪些環節？
1)低延遲，基本上引入延遲的有三類環節：採集和渲染、編解碼、網路傳輸。第一類是採集和渲染環節，帶來的延遲比較大，尤其是渲染，幾乎沒有任何移動端系統可以保證百分之百做到50毫秒的延遲，這是一些硬體上的限制造成的。第二類是編解碼環節，特別是音訊編解碼器是往前編碼的，這個本身就會帶來延遲，甚至有些音訊編解碼器能帶來200毫秒的延遲。第三類是網路傳輸，在即構科技的實時傳輸網路裡，往返的傳輸延遲分別都可以做到50毫秒以下。其中，採集和渲染、編解碼都是在終端實現的。
2)回聲消除，屬於語音前處理3A，需要在前處理環節進行，也就是在終端實現的。
3)抖動緩衝，是在接收端實現的，通過接收端的抖動緩衝來決定傳送端要以多大的時間間隔來發送資料包。
綜上所述，剛才說的三個技術難點都是在終端實現的，因此終端非常重要。下面我們重點比較連麥直播技術在各種終端上的實現。
連麥直播在各種終端的比較
連麥直播的終端主要包括：原生APP、瀏覽器H5、瀏覽器WebRTC、微信小程式。瀏覽器上的應用包括H5和WebRTC，前者可以拉流觀看，後者可以實現推流和拉流。
連麥直播移動終端-Native APP
原生APP終端音視訊引擎畫的結構框圖如下，基本包括了音訊引擎、視訊引擎和網路傳輸，合稱實時語音視訊終端引擎。這裡還包含底層的音視訊採集和渲染，還有網路的輸入輸出能力，這是作業系統開放的能力。
原生APP有個天然的好處，它是直接和作業系統打交道的，作業系統開放的資源和能力它都可以直接用，比如說音視訊的採集渲染，還有網路的輸入輸出。套用一句時髦的廣告語：“沒有中間商賺差價”，直接和作業系統對接，可以獲得比較好的使用者體驗。
在原生APP上實現連麥直播的優勢是，對上面所說的七個環節有較好的把控，可以獲得比較低的延遲，能自研實現語音前處理3A演算法，包括回聲消除，還有對抖動緩衝策略和位元速率自適應的策略都有比較好的把控。另外，可以自主選擇使用RTMP協議還是基於UDP的私有協議，對抗弱網環境更加有保障。
市面上比較流行的前處理技術，比如美顏、掛件、變聲等，原生APP都可以通過開放前處理介面讓開發者實現或者對接這些技術。為什麼要強調這個呢？因為瀏覽器WebRTC和微信小程式都沒有開放前處理介面，開發者沒有辦法自行實現或者對接第三方的美顏或者掛件等技術模組。
在原生APP上，開發者可以得到全面的把控能力，讓使用者可以獲得更好的體驗。主流的視訊直播平臺都有自己的原生APP平臺，而瀏覽器和微信小程式相對來說是輔助的。原生APP的使用者體驗是最好的，而且對開發者來說也是最可控的。
在原生APP上實現連麥直播的劣勢是什麼呢？開發門檻高，開發週期長、人力成本高。另外，從獲取使用者和傳播的角度來講，也沒有瀏覽器和微信小程式那麼便利。
連麥直播移動終端-瀏覽器（H5）
瀏覽器H5就像一個硬幣有兩面，有好處也有劣勢，好處是開發成本低，容易傳播，劣勢是隻能拉流，不能推流，不能做到多個使用者連麥直播。另外，在瀏覽器H5上延遲也是比較大。如果使用RTMP或者HTTP-FLV，延遲會在1秒到3秒之間，如果用HLS延遲會大於8秒甚至10秒，這麼大的延遲就根本就不允許實現連麥直播。
使用這三種協議都是通過瀏覽器H5中的播放器來播放的。在多主播連麥互動的場景中，一個播放器裡面只能播一路視訊流，三個主播就得三個播放器，因此看不到多個主播同框連麥互動的情形。如果要看到多個主播同框互動的畫面，就必須把多路流混合成一路流，在單個播放器裡面播放。
另外，瀏覽器H5的原始碼是開放的。如果在瀏覽器上把音視訊終端引擎實現了，相當於對外公開了所有核心的原始碼。因此，還沒有見過哪個廠商在瀏覽器H5上完整地把音視訊引擎真正做出來。即使你願意做出來，瀏覽器也不會允許你這樣做，開發者和作業系統之間隔著瀏覽器，如果瀏覽器不把作業系統的核心能力開放給開發者，開發者就不能自主採集和渲染，不能掌控網路輸入輸出，類似流控碼控等功能無法實現。
在瀏覽器H5中也可以通過websocket來傳輸，用jsmpeg來播放，視訊編解碼的格式用mpeg1。mpeg1是一個比較老的媒體格式，所有瀏覽器都支援。在瀏覽器中使用jsmpeg播放器播放mpeg1，所有瀏覽器也可以支援。這麼做可以獲得比較低的延遲，但是還是無法推流，沒辦法實現連麥直播。
例子：線上抓娃娃H5版
下面使用即構線上抓娃娃H5版本為例，簡單介紹一下websocket在瀏覽器H5上的應用。從下圖左上角可以看到，在瀏覽器H5終端接入即構實時傳輸網路時，我們加入了一個視訊接入伺服器，右邊是即構實時傳輸網路，使用基於UDP的私有協議。通過接入伺服器實現協議的轉換和媒體格式的轉換：websocket和基於UDP的私有協議的轉換，mpeg1和H.264的轉換。如果原生APP接入就不需要做轉換，雖然有接入伺服器，但是不會做轉換。
另外，線上抓娃娃的H5版本是沒有聲音的，除了應用場景的特點要求外，也要用H5實現了音訊引擎才能有聲音。如果在瀏覽器H5上實現了音訊引擎，就相當於把技術開源了，目前還沒有看到哪個廠商這麼做。
連麥直播移動終端-瀏覽器（WebRTC）
大家可能會覺得很遺憾，瀏覽器H5雖然很容易傳播，開發簡單但是體驗欠佳，不能連麥直播。那麼在瀏覽器上能不能推流，能不能實現連麥直播呢？答案是可以的，那就要用到WebRTC。
這裡說的WebRTC是指已經被內嵌到瀏覽器裡面，被瀏覽器支援的WebRTC，而不是WebRTC的原始碼。部分主流瀏覽器內嵌了WebRTC，對開發者開放了瀏覽器的實時音視訊能力。
上圖是WebRTC的結構圖。我們可以看到WebRTC包括了音訊引擎，視訊引擎、傳輸引擎等，最底層的虛線框表示可以過載，也就是說瀏覽器把最底層的音視訊渲染和網路傳輸的底層能力開放給開發者，開發者可以根據自己的需求選擇是否進行過載。音訊引擎中，包括了兩個編解碼器：iSAC和iLBC，前者針對寬頻和超寬頻的音訊編解碼，後者針對窄帶音訊編解碼。音訊引擎還包括了音訊抖動緩衝，回聲消除和噪音抑制模組等。抖動緩衝中的NetEQ演算法可以說是WebRTC裡面的精華之一。視訊引擎中，包括了VP8和VP9的視訊編解碼器，甚至是即將到來的AV1。視訊引擎還包括視訊抖動緩衝和影象質量增強等模組。傳輸引擎，WebRTC使用的是SRTP（Secured Realtime Transport Protocol）安全實時傳輸協議。最後，WebRTC採取P2P的通訊方式，沒有媒體伺服器等後端的實現。以上是WebRTC的簡單介紹。
瀏覽器WebRTC一般的優勢和劣勢這裡就不再重複，請大家自行百度，這裡只說重點。瀏覽器WebRTC的好處就是實現了相對完整的音視訊終端引擎，允許在瀏覽器上推流，可以實現連麥直播。然而，瀏覽器WebRTC也有不足：
1）沒有開放前處理介面，美顏和掛件這些模組沒辦法接入第三方的或者自研方案。
2）媒體伺服器後端沒有實現，開發者要實現媒體伺服器，然後通過開源WebRTC閘道器（比如說janus）接入。
3）編解碼器、抖動緩衝和語音前處理3A等能力只能依靠WebRTC，不能自行定製化。
4）部分主流瀏覽器是不支援WebRTC的，特別是蘋果的瀏覽器。雖然說去年蘋果宣佈支援WebRTC,但是目前iOS Safari最新版本對WebRTC的支援並不好，iOS Safari的主流版本並不支援WebRTC，在iOS上面微信瀏覽器也是不支援WebRTC的。
如上圖所示，由於WebRTC不提供媒體伺服器的實現，因此需要把瀏覽器WebRTC接入到媒體伺服器後端，這個可以是自研的，也可以是第三方的服務。瀏覽器WebRTC和媒體伺服器後端之間的協議和媒體格式是不一樣的，因此要做協議和格式的轉換。WebRTC用的基於UDP的SRTP，需要把它轉換成媒體伺服器的基於UDP的私有協議。另外，媒體格式也需要轉換，因為WebRTC中語音視訊格式預設用的是VP8或者VP9。同時實時傳輸網路中有關信令排程也需要做一些調整。瀏覽器WebRTC和媒體伺服器後端之間的接入層也可以採用開源的WebRTC Gateway（比如說janus）來實現。
瀏覽器是類似作業系統的一種超級應用，它坐擁重要的流量入口，然而它也是開發者和作業系統之間的“中間商”。開發者通過WebRTC獲得瀏覽器開放的實時音視訊能力，然而也必須要承受WebRTC帶來的痛苦。
連麥直播移動終端-微信小程式
這次演講的標題是《連麥互動直播X微信小程式》, 為什麼直到這裡才開始討論小程式？請允許我解釋一下原因。微信小程式是什麼？是跑在微信上面的輕型應用。微信是什麼？是類作業系統的超級應用。這些特徵和瀏覽器以及H5是不是很接近？H5是瀏覽器支援的輕型應用，而瀏覽器是類作業系統的超級應用。瀏覽器背後是各大國際科技巨頭，不像微信這樣背後只有騰訊一個網際網路巨頭。因此，從這個角度來看，微信小程式、瀏覽器WebRTC和H5是有相通之處的。
微信小程式可以類比為瀏覽器H5那樣的客戶端和伺服器的結構。其中HTML對應微信小程式的WXML，CSS對應小程式的WXSS，小程式的指令碼語言和JS是一樣的，只是框架不一樣。微信小程式提供了兩個標籤，一個是<live-pusher>，一個是<live-player>。<live-pusher>就是推流，<live-player>就是拉流，可以實現單向直播或者連麥直播。小程式提供兩種模式：LIVE和RTC，LIVE支援單向直播，RTC支援低延遲的連麥直播。目前微信小程式推流採用RTMP協議，如果要和私有協議互通，需要進行協議轉換。
微信小程式開放了實時音視訊能力，對業界來說是重大利好。然而，根據上面的資訊和邏輯，我們也看到採用微信小程式實現連麥互動直播的好處和不足。
好處有三點：
1）開發成本低，開發週期短，基本和H5的開發難度差不多；
2）很容易傳播和獲客，充分利用好微信的優質流量；
3）可以推流和拉流，允許實現連麥直播和實時語音視訊通話。
不足有四點：
1）你會受制於微信小程式的實時音視訊能力，比如說，如果它的回聲消除有某些問題，你只能等微信團隊按照自己的節奏來優化，而自己沒有任何辦法去優化。
2）小程式沒有開放前處理介面，只能使用小程式自帶的美顏或者變聲功能（如果有），不能對接自行研發或者第三方的美顏或者變聲模組。
3）通過RTMP協議推流和拉流，不能和基於UDP的私有協議互通連麥。如果要實現和基於UDP的私有協議互通連麥，就必須要增加接入層來轉換協議格式甚至媒體格式。
4）沒有實現後端媒體伺服器，開發者必須要自行實現媒體伺服器，或者把微信小程式接入到第三方的實時通訊網路。
瀏覽器通過WebRTC開放了瀏覽器的實時音視訊能力，而微信通過小程式開放了微信的實時音視訊能力，在兩個類作業系統的平臺上允許開發者去實現連麥直播和實時音視訊通話。然而，無論WebRTC還是小程式只是在終端上帶你入門，對開發者來說，要真正實現整套系統，還有很多工作需要做的。
下圖展示了微信小程式如何接入到實時音視訊傳輸網路。微信小程式的音視訊終端引擎也包含了音訊引擎，視訊引擎還有傳輸引擎。音訊引擎要負責採集和渲染，音訊抖動緩衝，語音前處理和編解碼。視訊引擎要負責採集和渲染、視訊抖動緩衝，視訊前處理和編解碼。關於傳輸引擎，微信小程式採用RTMP協議來推拉流，尚不清楚它的RTMP協議下層是TCP協議，還是通過QUIC來使用基於UDP的私有協議。如果RTMP的下層是基於UDP的私有協議，那麼在弱網環境下的抗性會相對比較好一些，而TCP協議是一種面對公平的協議，對各個環節的可控性不強，在弱網環境下體驗就相對差一些。
如果要將微信小程式接入實時音視訊傳輸網路，中間得有接入伺服器，我們叫接入層。在接入層我們需要做協議的轉換，比如說，如果實時音視訊傳輸網路是使用基於UDP的私有協議，那麼要把RTMP協議轉為基於UDP的私有協議。還有媒體格式的轉換，如果和實時傳輸網路的媒體格式不一樣，還需要進行轉換。
連麥直播移動終端-WebRTC通過WebView接入小程式
還有別的方法在小程式上做連麥直播互動嗎？必須要使用微信小程式開放的語音視訊能力嗎？也不一定。下圖展示了我在市面上看過的一個技術方案，它繞過了微信小程式實時語音視訊能力，通過微信小程式WebView元件實現了連麥直播的方案。這裡和大家分享一下。
這個方案的基本思路是利用WebView的瀏覽器特點，在WebView內使用WebRTC的Web API，從而在小程式上獲得實時音視訊能力。上圖是這個方案的拓撲圖。最底層是微信小程式的基礎能力。上一層是WebView，WebView是微信小程式的一個控制元件，可以簡單看作一個類似瀏覽器的元件，提供了瀏覽器的一部分特性，但並不是完整的瀏覽器。微信小程式的WebView類似瀏覽器，那麼就可能會支援WebRTC。然而必須要注意到，微信小程式的WebView在安卓平臺上支援WebRTC，但在iOS平臺上面不支援WebRTC。雖然這個方案理論上也能在微信小程式上實現連麥直播，但是它有以下的侷限性：
1）在iOS平臺上，微信小程式不支援這個方案，上面已經說過。
2）小程式WebView不是完整的瀏覽器，要比普通瀏覽器表現差而且有很多的限制。
3）開發者和作業系統之間隔了好幾層：微信底層，小程式，WebView，WebRTC，然後才是開發者的小程式應用。每一層的抽象都會帶來效能上的消耗，都會影響到最終的體驗。
這個方案本質上還是一個基於WebRTC的解決方案，沒有用到微信小程式開放的實時音視訊能力，而是快速地藉助WebView元件，劍走偏鋒，十分討巧地在微信小程式裡使用了WebRTC。
連麥直播在各種終端的互通
隨著連麥互動直播技術在各種終端上逐步實現，那麼我們就會面臨一個問題：在各種終端上可以連麥互通嗎？比如說，使用者A在微信小程式上可以和使用者B在原生APP上連麥互通嗎？
我們從上面提到的場景說起。使用者A在微信小程式上推流和拉流使用的是RTMP協議，如果使用者B在原生APP推流和拉流都是使用RTMP協議，那麼兩者天然就是可以連麥互通的。如果原生APP推流和拉流都是使用基於UDP的私有協議，那麼就不能直接地連麥互通，必須要經過接入層進行協議和格式的轉換才能互動連麥。這個場景還可以延伸：使用者A在微信小程式上可以和使用者C在瀏覽器WebRTC上連麥互通嗎？背後的邏輯是一樣的。
以即構科技的方案為例，即構ZEGO的原生APP SDK有兩個版本：支援RTMP協議和基於UDP的私有協議，如果用的是支援RTMP協議的原生APP SDK，那麼直接就可以和小程式互動連麥，如果用了基於UDP的私有協議的原生APP SDK，那麼就要經過接入伺服器進行協議和格式的轉換。
基於UDP的私有協議在弱網環境下會有更好的表現，而RTMP協議在非弱網的情況下表現也相當好，而且能夠很好地相容CDN內容分發網路。舉個例子，花椒直播的連麥直播方案一直都是使用即構科技提供的RTMP版本的技術方案，在線上執行兩年了，一直都保持良好的使用者體驗。
結語
連麥直播技術逐步在原生APP, 瀏覽器H5，瀏覽器WebRTC，微信小程式上延伸，衍生出更加豐富的生態，提供更加便捷和良好的使用者體驗，對視訊直播平臺和使用者來說是好訊息。然而，欲帶皇冠，必承其重。特別是在瀏覽器WebRTC和微信小程式上，開發者要充分理解這些型別終端的特點和侷限，才能更好地在上面利用連麥直播技術進行創新，服務使用者。