如何为咱们的应用程序提供一个更小、更快的视频通话库

在研究如何使视频通话在将来更高效，更易于扩展时，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在实施方面提供了帮助，并继续提供指导和支持。