如何爲咱們的應用程序提供一個更小、更快的視頻通話庫

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

做者 / Ishan Khot

原文連接 / https://engineering.fb.com/20...

• 咱們將在咱們的應用程序和服務的全部相關產品上推出一個新的視頻通話庫，包括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在實施方面提供了幫助，並繼續提供指導和支持。