正文字數：2848 ?閱讀時長：4分鐘

在研究如何使視頻通話在未來更高效，更易于擴展時，Facebook意識到，最好的方法是從頭開始重新設計庫并重寫整個庫，也就是Rsys。

作者 /?Ishan Khot

原文鏈接 / https://engineering.fb.com/2020/12/21/video-engineering/rsys/

• 我們將在我們的應用程序和服務的所有相關產品上推出一個新的視頻通話庫，包括Instagram、Messenger、Portal、Workplace chat等。

• 通過創建一個通用類庫足以支持所有這些不同的用例，但我們需要從頭重寫現有庫使用最新版本的開源的WebRTC庫。這是一個非常令人難以置信的任務，以至于我們整個公司的工程師都參與到了其中。

• 與前面的庫相比,Rsys能夠支持多個平臺,包括Android, iOS, MacOS, Windows和Linux。它的大小大約小了20%，這使得它很容易集成到大小受限的平臺中，比如Messenger Lite。Rsys擁有大約90%的單元測試覆蓋率和一個完整的集成測試框架，它涵蓋了我們所有的主要調用場景。

• 為此，我們通過將庫和體系結構的大小優化為二進制大小來實現這一目標，方法是將調用所需的部分分成獨立的獨立模塊，并利用不依賴于操作系統和環境的跨平臺解決方案。

Facebook的視頻通話初始版本是在一個已有7年歷史的WebRTC分支上編寫的，專門用于在Messenger中啟用本機音頻通話。當時，我們的目標是為我們的用戶提供功能最豐富的體驗。從那時起，我們添加了視頻通話，群組通話，視頻聊天引擎和交互式AR效果。每月有數百萬人使用視頻通話，這個功能齊全的庫表面上看起來簡單，但在幕后卻變得復雜得多。我們有大量特定于Messenger的代碼，這使得我們很難支持像Portal和Instagram這樣的應用程序。對于組調用和對等調用，我們有單獨的信令協議，這要求我們編寫兩次特征，并在代碼庫中造成很大的不一致。我們還花費了更多的時間來更新WebRTC的分支，并使用開源的最新改進功能。但最后，我們發現我們在為低功耗設備和低帶寬場景提供可靠服務方面落后了。

在研究如何使視頻通話在未來更高效，更易于擴展時，我們意識到，最好的方法是從頭開始重新設計庫并重寫整個庫。結果就是Rsys，這是一個視頻通話庫，它讓我們能夠利用自2014年編寫原始庫以來在視頻通話領域取得的一些重大進步。與以前的版本相比，Rsys縮小了約20％，并且可在所有開發中使用平臺。通過這一新的迭代，我們將重新構想我們對視頻通話平臺的看法，并從頭開始使用新的客戶端核心和可擴展性框架。這有助于我們提升自己的最先進技術，新的代碼庫旨在在未來十年保持可持續性和可擴展性，為跨應用程序的遠程存在和互操作性奠定基礎。

更快更小

無論設備類型或網絡條件如何，使用較小的代碼庫可以為其用戶實現更快地加載、更新和啟動。相比之下，小型庫也更易于管理、更新、測試和優化。當我們開始考慮準備新的版本時，我們的峰值二進制大小已高達20 MB。盡管我們可以通過編輯一些代碼段來減少一些內容，但是要達到我們想要的效果，我們意識到我們需要從頭開始重寫整個代碼庫。

想要獲得較小的庫，最簡單方法是去掉多年來我們添加的許多功能特征，但是對我們來說，保留所有最常用的功能（如AR效果）很重要。因此，我們退后一步，研究了如何應用過去十年中所學到的知識以及我們對如今使用我們產品的用戶的需求了解。探索完我們的這些選擇之后，我們決定需要越過接口，并深入研究庫本身的基礎結構。

我們做了幾個架構選擇來優化大小，引入了一個即插即用的框架，使用selects有選擇地將特征編譯到需要它們的應用程序中，并引入了一個通用框架來編寫基于Flux架構的新特性。我們也從Folly這樣的模板化通用庫轉向了像Boost這樣規模更優的庫。SML在所有應用程序中實現大小增益。

最后，我們將核心二進制文件的大小減少了大約20%，從大約9MB減少到大約7MB。我們通過重新構建我們的特征以適應簡化的體系結構和設計來實現這一點。雖然我們保留了大部分特性，但隨著時間的推移，我們將繼續引入更多可插入特性。更少的代碼行數使代碼庫更輕、更快、更可靠，而精簡的代碼庫意味著工程師可以更快地進行創新。

這項工作的主要目標之一是最小化代碼復雜性和消除冗余。我們知道，一個統一的體系結構將允許全局優化（而不是讓每個特性都集中在局部優化上），并允許代碼重用。為了構建這個統一的體系結構，我們做了一些主要的更改：

• 信令：我們為信令棧提出了一種狀態機架構，它可以統一對等調用和組調用協議語義。我們能夠從庫的其余部分抽象出任何特定于協議的細節，并提供一個信令組件，該組件將全權負責在調用參與者之間協商共享狀態。通過減少重復代碼，我們可以一次編寫特性，并允許輕松更改協議，并為對等調用和組調用提供統一的用戶體驗。

• 媒體：我們決定重用我們的狀態機架構，并將其應用到媒體堆棧中，但這次我們捕獲了開源WebRTC API的語義。同時，我們還致力于用最新版本替換我們的分支版本WebRTC，同時保留所有針對產品的特定優化。這使我們能夠在狀態機下更改WebRTC版本，只要API本身的語義沒有明顯變化，我們就可以從開放源碼代碼庫中設置定期常規拉取。這使我們能夠輕松地更新到最新的功能，而不會出現任何停機或延遲。

• SDK：為了具有特定于功能的狀態，我們使用Flux架構來管理數據，并為調用產品提供API，這些API的工作原理類似于web開發人員熟悉的基于React js的應用程序。每個API調用都會導致通過中央調度程序路由的特定操作。然后，這些動作由特定的reducer類處理，并根據動作的類型發出模型對象。這些模型對象被發送到包含所有特定于功能的業務邏輯的網橋，并導致更改模型的后續操作。最后，所有的模型更新都被發送到UI，在那里它們被轉換成特定于平臺的視圖對象進行渲染。這使我們能夠清晰地定義一個包含減速器、橋接器、動作和模型的特性，從而使我們能夠在運行時為不同的應用程序配置特性。

• OS：為了使我們的平臺具有通用性和可擴展性，我們決定抽象出直接依賴于OS的所有功能。我們知道，對于某些功能（例如創建硬件編碼器，解碼器，線程抽象等），必須具有針對Android，iOS等的特定于平臺的代碼，但是我們嘗試為這些功能創建通用接口，以便MacOS和Windows等平臺可以通過代理對象提供不同的實現來輕松插入。我們還大量使用Buck中的cxx_library來以簡便的方式配置特定于平臺的庫，以用于編譯器標志，鏈接器參數等。

用于調用的Rsys架構

下一步的計劃

如今，我們的調用平臺明顯要小得多，并且能夠在許多不同的用例和平臺上擴展。我們支持每天都有數百萬人使用的電話。我們的庫是我們所有主要通話應用程序的一部分，包括Messenger，Instagram，Portal和Workplacechat。構建Rsys需要一個很長的過程，但是，對于使用這些應用程序的人們來說，它的感覺并沒有太大不同。它將繼續為人們提供出色的通話體驗。但這僅僅是開始。

我們在Rsys中所做的工作將使我們在邁向未來的過程中能夠繼續創新和擴展我們的通話體驗。除了構建可在未來十年或更長時間保持可持續發展的庫之外，這項工作還為我們所有應用的跨應用調用奠定了基礎。它也為我們建立以遠程存在為中心的環境奠定了基礎。

這項工作得益于與客戶平臺團隊合作。我們感謝所有為Rsys做出貢獻的人，特別是Ed Munoz，Hani Atassi，Alice Meng，Shelly Willard，Val Kozina，Adam Hill，Matt Hammerly，Ondrej Lehecka，Eugene Agafonov，Michael Stella，Cameron Pickett，Ian Petersen和Mudit Goel在實施方面提供了幫助，并繼續提供指導和支持。

LiveVideoStackCon 2021 ShangHai

這個世界沒有準備好這一說

機會和技術不會主動敲開你的門

LiveVideoStackCon 2021?上海站

北京時間：2021年4月16日-4月17日

點擊【閱讀原文】了解大會詳情

總結

以上是生活随笔為你收集整理的如何为我们的应用程序提供一个更小、更快的视频通话库的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。