|導語使用企業微信跨組織間會議門檻較高，要求外部客戶或合作伙伴先建立在企業微信的線上組織才可入會，通過引入小程序入會能力，降低跨組織會議的門檻；為解決微信用戶發起會議，邀請企業微信、微信好友入會的場景，企業微信會議小程序也提供在微信側接入和發起會議的能力，實現微信用戶發起會議邀請企業成員加入會議的能力；
產品功能說明
企業微信的會議是接入了騰訊云提供的XCast SDK，騰訊會議后臺提供了Rest APi接口用于創建會議、加入會議、獲取會議信息等；
企業微信的會議是接入了騰訊云提供的XCast SDK，騰訊會議后臺提供了Rest APi接口用于創建會議、加入會議、獲取會議信息等；
企業微信app發起的會議，雖然支持邀請微信好友加入會議，但是需要用戶下載和安裝企業微信，注冊企業微信后才可以加入會議，加入會議的門檻較高；
雖然有利于企業微信引流拉新，但是對于用戶而言是不太友好的微信小程序彈出層，所以我們啟動了微信小程序可以直接加入會議的方案；
功能表現：
企業微信app發起會議后通過邀請微信好友，好友會收到小程序卡片，打開小程序可以直接加入會議；或是微信用戶發起會議，發起邀請企業微信或微信用戶入會；
視頻會議在小程序側的UI表現：
視頻會議支持美顏、會議附件、文檔共享和屏幕共享等能力：
音頻會議及會議管理：
支持企業微信發起的預約會議，邀請微信用戶參加，在會議開始時會收到微信的服務通知，提醒進入會議；
會議技術流程介紹
首先要介紹一下TRTC
TRTC：騰訊實時音視頻（ Real-Time ，TRTC）；
騰訊云提供了多人音視頻通話方案和低延時互動直播方案兩種服務，提供覆蓋手機、桌面全平臺的客戶端 SDK 以及云端 API，終端用戶還可以在微信、QQ、企業微信的小程序中使用 TRTC 服務，Web 網頁也可輕松使用。
下圖是TRTC官方的一個產品架構圖：
騰訊會議與TRTC的關系
騰訊會議基礎服務是基于TRTC的音視頻媒體服務+進房權限保護（建立私有的房間集合，與TRTC的房間是不互通的），再結合騰訊會議自己建設的會控能力、會議模式下強悍的混音模塊等，也包括騰訊會議自己擴展的一些功能；
TRTC進房權限保護機制
是 中的一個可選字段，它的作用是讓騰訊云檢查用戶是否擁有進入指定房間的權限。
是由服務器端計算提供，是在加入會議房間時騰訊會議的后臺會返回，也就是獲取時必要的字段；
小程序接入會議的整體技術方案
企業微信會議依賴模塊示意圖
騰訊會議有個自己的小程序，是建立在內部API的體系下，并不是可以對外開放的能力，而企業微信終端接入的是基于Rest API這套開放體系接入的；
之前也未提供給第三方提供過小程序的開放能力，此次企業微信啟動的小程序接入，是騰訊會議首次對外提供會議小程序入會的通道，趕上過年疫情期間的暴發，騰訊會議的后臺同學也是經常通宵，無人力支持的情況下導致項目整個過程極其漫長而又痛苦；
TRTC官方提供的小程序demo，是使用微信小程序提供的live-和live-組件實現的，小程序加入騰訊會議私有域的房間，主體技術流程如下圖所示：
會議小程序接入整體架構示意圖：
接入騰訊會議的整體流程概述：
小程序用戶通過加入騰訊會議邏輯房間；
加入成功后獲取音視頻房間信息，包括實時音視頻控制臺側媒體流動態分配的機器ip、端口等；
獲取加入音視頻媒體房間使用的用戶信息以及鑒權信息，包含音視頻房間RTMP代理的服務器及端口信息，是根據用戶的地域通過云端動態分發最優線路下發，最大限度提升用戶在會議中的音視頻和通話的流暢度；
獲取到音視頻鑒權必要的信息后，通過live-建立音視頻通道鏈接，響應音視頻通道推送的用戶音視頻流以及采集音視頻流的推送，以及音視頻混音流或輔助流的推送和收發，屏幕共享就是基于輔助視頻流的方式實現的，發起屏幕共享的人通過live-可以推送當前屏幕錄屏的數據流，騰訊會議側音視頻房間的接口機負責轉發到RTMP代理，再通過音視頻建立的通道進行數據流的分發，推送給房間其它的用戶；
同時建立企業微信會議邏輯房間的長鏈接通道，并初始化當前用戶在邏輯房間的狀態；企業微信會議擁有獨立的會控能力，包括文檔共享、屏幕共享、靈活的主持人會議控制能力等，都是基于企業微信會議的長鏈接服務；
企業微信獨立的會控制能力，具體的會控指令包括（人員上/下線、開關麥、開關視頻、主持人控制、請求上臺發言、主持人控制會議的人員進入、或靈活的管理規則等），這部分能力是企業微信后臺單獨控制，例如人員上/下線也是通過REST API通知騰訊會議側的后臺進行更新會議狀態，以保持音視頻房間的成員狀態盡可能與企業微信邏輯房間的狀態保持同步；
企業微信會議完整技術方案示意圖：
會議終端接入方案以及注意事項
企業微信App通過接入騰訊會議提供的XCast SDK，做為客戶端接入音視頻房間的基礎能力，包括音視頻采集、播放、美顏、推流控制等，同樣也建立與企業微信后臺邏輯房間層的長鏈接通道；
企業微信App通過企業微信后臺請求創建會議的接口發起會議，創建會議后會返回音視頻媒體房間的信息，企業微信App拿到音視頻房間信息后，通過XCast SDK發起推流行為，以及接收推流的事件和音視頻數據，包括媒體房間的用戶信息等；
音視頻房間用戶的列表是基于創建會議時傳入的pid生成的，這里就依賴邏輯房間層也要在用戶列表中也增加此用戶的信息，用于邏輯房間與媒體房間的用戶關聯；
接受當前同一房間用戶的音視頻流數據，使用live-渲染用戶側的畫面；
小程序發起長鏈接與企業微信后臺建立sync通道，用于會議控制指令下發和上行的交互；
企業微信app發起者可以屏幕共享，是通過TRTC的視頻流通道采集和推送能力，通過TRTC的音視頻房間為其它用戶推流，其它用戶收到的共享者的視頻畫面則更換為屏幕的畫面（TRTC支持了輔助流，也就是視頻畫面和共享屏幕的畫面都可以顯示，但微信小程序暫不支持）；
會議小程序獨立會議控制
企業微信會議過程中的會議控制，是通過單獨的邏輯房間長鏈接通道實現，會控邏輯相關的時序操作流程如下圖所示：
企業微信的會議控制包括主持人控制人員上下臺，或單獨控制開啟關閉視頻、音頻等能力；
企業微信用戶在會議中發起文檔共享，是企業微信提供的私有能力，發起者共享文檔時，通過企業微信后臺轉換為共享的數據流，通過長鏈推送到其它用戶，小程序接受共享的數據后實時更新，包括發起者共享中的翻頁、畫箭頭等行為，同步在小程序中渲染；
音視頻接入層
音視頻引擎介紹
來自騰訊會議的同學提供的引擎介紹
引擎接口層主要給上層提供啟動、停止、設置各種參數的接口，和引擎的一些事件通知回調。另外，引擎不提供實際的網絡傳輸，而是把收發數據的接口給上層來實現。
IO流是引擎很重要的一個抽象概念（有點類似響應式編程和的思想），各個數據處理模塊（比如解包、FEC、音頻解碼、混音等）通過IO流串聯成一條或者多條單向流動的樹形鏈路，各個模塊的處理按照順序分布在各節點上，IO流的拓撲結構由組織構成。
IO流是引擎很重要的一個抽象概念（有點類似響應式編程和的思想），各個數據處理模塊（比如解包、FEC、音頻解碼、混音等）通過IO流串聯成一條或者多條單向流動的樹形鏈路，各個模塊的處理按照順序分布在各節點上，IO流的拓撲結構由組織構成。
每個節點綁定一個對象，需要實現兩個函數：和，前者在數據流入本模塊的時候解析和處理數據、后者在數據流出本模塊的時候把處理好的數據交給下一個模塊。
引擎的基本處理流程，引擎有兩條主要的流：
接收流和發送流。這兩條流都在引擎啟動的時候就構建好了拓撲結構
1. 接收流
接收流從網絡收包以后再Dmx節點進行解包，然后根據uin分成若干個，每個都有單獨的IO調用鏈，分別對應FEC解碼（也包括ARQ）、QT解碼、抗抖、音頻解碼。然后所有的合并到一起，進入混音模塊，最后輸出到終端播放。
2. 發送流
發送流是從錄音設備采集開始，然后數據流經過3A、編碼、QT編碼、FEC編碼，最后送到網絡發送。
我們遇到的問題及解決方案
我們在開發會議小程序的過程中遇到了各種各樣的問題，下面記錄分享一下我們遇到的問題以及解決思路；
如果也有遇到類似的問題的同學，可以企業微信聯系一起交流經驗；
1、文檔共享/屏幕共享相關的問題
文檔共享、屏幕共享時live-臨時斷開導致數據流無法渲染；
問題：
騰訊會議提供的音視頻服務都依賴于live-建立的通道，如果在文檔共享或屏幕共享時view的切換導致live-組件有臨時中斷的情況，會導致會議音視頻中斷，只有再建立成功后才可以恢復；
解決辦法：
避免view的重新渲染，通過class控制view節點的布局調整，保持live-一直在鏈接狀態；
文檔共享的技術實現
簡企業微信app的會議主持人可以發起文檔共享時，通過標注圖標繪制在文檔上，小程序會接受文檔共享的文檔內容以及指令信息，指令信息為箭頭開始的坐標x/y，以及結束坐標的x/y；
小程序提供一個文檔共享查看的窗口，同時調整live-和live-的表現，通過長鏈接接受指令的信息后，在文檔內容的上層創建一個同樣大小的用于繪制箭頭，指令的實時變化會通過長鏈通知，實現演示中箭頭指向的問題；
目前遇到一個比較嚴重的bug是在縮放一定的比例后，會有一個超出繪制范圍的bug，導致箭頭的繪制不會被渲染（老版本 api存在的問題）；
屏幕共享的技術實現流程
會議中的屏幕共享是使用一個輔助視頻流上行推送，其它側用戶會通過live-的事件進行推送的，在推送的用戶列表信息中會出現一個用于標識屏幕共享的視頻流信息；
小程序在接收到有屏幕共享視頻流的情況下，會切換到屏幕共享的狀態下，大屏顯示屏幕共享的數據微信小程序彈出層，同時將共享人的視頻畫面使用live-中正常播放；
屏幕共享的視頻流使用live-播放；
2、音視頻控制相關的問題
音視頻上下臺時推流中斷出現畫面閃爍的問題
音視頻房間與邏輯房間不一致的問題
音量控制動畫
視頻畫面方面各個端采集方向不同（移動端、小程序、桌面端的差異性）
3、其它一些問題
騰訊會議房間鑒權的問題
前期遇到最多的問題是來自于此，首先這里存在2個概念，一個是邏輯房間，一個是音視頻房間，所需的鑒權信息不同，另外騰訊會議測試環境與正式環境不互通，導致這里出問題會比較多；
加入房間時用戶身份信息與簽名時使用的字段差異，依賴騰訊會議后臺提供必要的字段
因音視頻媒體房間所需要的簽名是騰訊會議處理的，依賴他們轉換后的以及去生成，這里同樣存在測試環境與正式環境不互通的問題；
測試環境不穩定的情況
涉及原生組件同層渲染相關的問題
一、 小程序原生組件存在的問題
小程序的原生組件的層級是最高的，所以頁面中的其他組件無論設置 z-index 為多少，都無法蓋在原生組件上。同層渲染是為了解決小程序中普通元素之間無法覆蓋的原生組件，解決特定組件下UI表現的各種異常問題；
會議小程序中使用的-組件有以下這些（查看更多原生組件，可以參考官方文檔）：
- live-
- live-
- input（僅在focus時表現為原生組件）
-
官方介紹的原生組件的使用限制：
由于原生組件脫離在 渲染流程外，因此在使用時有以下限制：
原生組件的層級是最高的，所以頁面中的其他組件無論設置 z-index 為多少，都無法蓋在原生組件上。
后插入的原生組件可以覆蓋之前的原生組件。
原生組件還無法在 -view 中使用。
部分CSS樣式無法應用于原生組件，
例如：
無法對原生組件設置 CSS 動畫
無法定義原生組件為 : fixed
不能在父級節點使用 : 來裁剪原生組件的顯示區域
原生組件的事件監聽不能使用 bind: 的寫法，只支持 。原生組件也不支持 catch 和 的事件綁定方式。
原生組件會遮擋 彈出的調試面板。在工具上，原生組件是用web組件模擬的，因此很多情況并不能很好的還原真機的表現，建議開發者在使用到原生組件時盡量在真機上進行調試。
二、Cover-View適配原生組件的方案
存在嚴重缺陷，但在不支持同層渲染的原生組件需要使用
cover-view 與 cover-image
為了解決原生組件層級最高的限制。小程序專門提供了 cover-view 和 cover-image 組件，可以覆蓋在部分原生組件上面。
這兩個組件也是原生組件，但是使用限制與其他原生組件有所不同。為了解決依賴按鈕的事件行為，cover-view中支持嵌套的view類型；
使用Cover-View覆蓋live-和live-的view元素
嚴重缺陷：
cover-view是不支持滾動列表響應滾動事件和行為的，導致有涉及滾動頁面的列表會有問題；
三、同層渲染遇到的問題及解決方法
如果發現同層渲染有無法解決的問題，可以強制關閉同層渲染
//app.json 中配置
{
"": ""
}
同層渲染是為了解決原生組件的層級問題，在支持同層渲染后，原生組件與其它組件可以隨意疊加，有關層級的限制將不再存在。
但需要注意的是，組件內部仍由原生渲染，樣式一般還是對原生組件內部無效。當前 video, map, live-, live-, (2d) 組件已支持同層渲染。
原生組件相對層級，為了可以調整原生組件之間的相對層級位置，支持在樣式中聲明 z-index 來指定原生組件的層級。該 z-index 僅調整原生組件之間的層級順序，其層級仍高于其他非原生組件。
1、 組件live-和live-不支持點擊事件，支持全屏操作的切換；
2、 同層渲染情況下view元素跳動的問題
問題表現：
覆蓋在原生組件上的普通view元素，在列表滾動時位置會跟隨變化，偶爾會跳出live-的視圖之外，無法跟隨容器的范圍變化；
解決辦法：
在普通的view的根節點下增加will-和，告知該元素會有哪些變化的方法，這里也就是會有縮放的變化，強制觸發的重新渲染；
will-: ;
: scale(1);
3、 視頻流出現黑屏
問題表現：
視頻流地址有推送的情況下，播放中并沒有視圖流信息導致播放窗口黑屏；
解決方案：
在live-的事件監聽中判斷當前視頻流的幀率是否正常，如果不正常則使用頭像顯示，覆蓋黑屏的表現；
4、 屏幕共享視頻流中斷續傳
問題表現：
企業微信app用戶發起屏幕共享過程中，如果用戶未結束共享，但是視頻流推送中斷了，導致畫面暫停或黑屏；
解決方案：
在感知用戶結束屏蔽共享行為時，我們在邏輯房間補充一個通知邏輯，告知小程序主動結束屏幕共享的狀態；
如果是用戶還在共享，騰訊會議音視頻房間推送的視頻流中斷了，則為用戶提示重新進出房間恢復畫面（同時反饋給騰訊會議修復此bug）；
5、 live-可滾動的問題（遺留）
問題表現：
當用戶點擊某個用戶頭像全屏后，再回列表，有一定概率出現小窗口可以滾動的情況；
解決方案：
初步確定的方案是在全屏視圖下把普通view節點與live-進行分離，以同層級并列關系存在，因調整較大，后續做為技術優化完善；