RSYS SDK – 跨平台实时系统库

Rsys简介

目前已经有很多视频电话用例，例如Instagram和Oculus，我们认为我们目前需要的是一些真正通用且可扩展的东西，以服务于所有这些不同的用例。在我们构建 RCS 的同时受到了 COVID 大流行的打击。在那段时间里，视频通话的所有用例都超出了比例。就在那时，我们意识到我们还需要对开发人员真正友好和易于理解的东西，以及他们可以快速制作原型和混合解决方案的东西，以便快速发布功能并满足不断变化的环境。因此，一方面我们有 Messenger light 等产品,大多数呼叫用例是在真正的发展中国家和低带宽和内存受限的设备中;但另一方面，我们也有一些用例，例如门户网站，他们想在真正的高端设备和具有功能的企业场景中进行呼叫，比如屏幕共享。

我们需要一些方案来满足所有这些不同设备的用例，这也是我们决定要踏上建立RSYS的旅程的原因，并且我们甚至想把他扩展到不同的操作系统，例如Windows和Linux，这也是我们选择主要使用C/C++来写RSYS的原因。它是高性能的，并且可以跨各种平台和操作系统扩展的。我们选择使用WebRTC作为RSYS的底层媒体引擎，因为WebRTC是Google的开源库并且被广泛应用于业内。此外，我们甚至有一个自定义信号协议，我们用它来协商通话中所有参与者的共享状态。最后，RSYS的结构是真正可扩展的并且有一个开发者模式允许开发人员在跨平台中编写功能。它也支持应用程序选择他们需要的功能，可以只为这些需要的功能提供内存大小和CPU开销，这一方法使得我们的呼叫功能可以在真正低带宽和内存有限的设备中运行。

结构

首先来看主状态循环。RSYS的核心组成部分是主状态循环。大家可能会发现它很眼熟，因为他借鉴了雷达模式，雷达模式被广泛应用于网页应用的开发。调度动作然后驱动状态变化。这些状态变化会产生影响通话体验的副作用。要么在外部例如驱动 UI，要么在内部例如改变或修改连接和媒体逻辑。

总的来说应用程序和一个API交互并触发一个动作，然后 reducers 与所有状态一起采取该动作以产生新状态。最后，这些新状态或模型被传递给应用程序和内部组件以驱动行为改变。

为了解决跨平台拒绝问题，我们使用 genie 作为 IDL 或接口定义语言，它允许我们以语言不可知的方式编写模型或接口类型。上图展示了呼叫模型和呼叫 api 的片段作为 IDL 的示例。可以自动生成C++或Java代码。这让应用程序可以通过他们自己熟悉的语言来编写SDK。

该功能是在应用程序中公开呼叫体验的主要构建块。它使开发人员能够在 RSYS 中编写新的呼叫体验，然后可以在不同的应用程序中重复使用。这是一个一次编写的模型，他们可以在任何需要它的地方重复使用。例如，相机或全息图逻辑作为功能提供，然后任何应用程序想要使用这些功能，他们都可以将其包含在他们的应用程序中。它使应用程序可以灵活地选择他们所关心的功能，而无需担心或为 CPU 或二进制大小付出代价。这使其可以在内存有限的设备中运行，例如messenger light 和可穿戴设备。

接下来深入到特征中。图中是特征与周围环境相互作用的方式，功能不会在真空中运行，他们需要数据来运行和产生新的状态。有些来自其他功能，例如通话中的参与者，而另一些则来自应用程序，例如相机拍摄画面。

该功能还将公开一个允许应用程序与之交互的 API。另一方面，该功能将通过代理与应用程序交互。代理实现应用程序特定的功能行为并让功能产生副作用。例如，要求应用程序打开相机。最后，该功能发出代表新状态的模型。

综上所述，RSYS 的主要入口点是 SDK，它提供平台本地接口，即我们在多种语言中讨论的投影。它还封装了呼叫管理器和信令组件。签名组件或我们称为核心的组件处理在开始呼叫之前发生的信号。它帮助我们将信号逻辑与系统和 WebRTC 库的其余部分隔离开，它还允许我们推迟加载重组件，即 WebRTC 和来自信号路径呼叫管理器的其他逻辑，为每个呼叫生成一个呼叫容器和呼叫的其他功能。在底部，我们有协调媒体和信号之间的连接(将在下一张幻灯片中介绍)，最后media是包装 WebRTC 的东西。

调用应用程序需要发信号与SFU服务器通信。信令的核心是一个状态机，它以声明的方式捕获该协议的语义。这不仅使我们能够在几行代码中整合所有用于发信号的业务逻辑，而且使我们能够拥有协议的多种不同含义，只要底层语义根本不同。因此，很容易学会使用。协议并更改有线格式设计信令以使其与传输无关，实际传输实现最好由应用程序完成。这使产品能够为其用例使用最佳实施。最后，所有信号都与 RSYS 一起打包为一个单独的库。这创造了一个与媒体相关代码分离的强大结构。

RSYS Media 是Google开源库WebRTC的一个封装，和信号相似，利用一个状态机结构传递WebRTC的语义。上述设计让我们能在不知道底层路径的情况下，将过去切换的责任委托给更高级别的组件。信号和media的通信使用另一个状态机。

测试，调试性和实用性

我们对RSYS进行了比较全面的测试，测试项目包括上图所示的四类：单元测试，集成测试，端到端测试和压力测试。

我们还公开了上图所示的不同机制来帮助发现问题或帮助开发人员编写他们的功能或与 RSYS 集成。

我们提供对所有类型线指标的监控，发出警报，检测到所有应用程序的攻击，我们有仪表板，还跟踪性能，无论它实际上是在系统内部还是在调用延迟。

未来展望

让我们看看从这里我们下一步要如何发展，以及我们如何使用它来扩展各种 RTC 场景,并为现实世界中的连接用户带来大量价值。

我们一直致力于的主要项目之一是端到端加密，感谢 RSYS 的模块化设计者，我们能够以一种方式构建此功能，以便只有需要此功能的应用程序才能使用它.端到端加密不仅需要对信令协议进行根本性的改变，还需要对媒体在 RSYS 中的流动方式进行根本性的改变，而且由于我们在开发人员效率方面进行了投资，开发人员能够可视化整个系统并以模块化方式构建此功能。这一项的实现不需要太长时间。

RSYS也被广泛应用于Oculus设备，我们认为支持元宇宙并且将其应用到RTC是一项关键技术，在元宇宙场景下的应用超过了传统的视频通话，我们有设计AR场景的用例，需要传输海量任意数据，与传统音视频通话传输的数据很不同。RSYS的设计和稳定的架构很快就可以告诉我们，什么能实现什么不能。

现在，我们还在 RSYS 的可靠性方面投入了大量资金，因为我们每天为数百万次呼叫提供支持，这要求我们确保我们所有的核心呼叫场景都能在数百万台设备和所有不同市场的各种用例中正常工作。

最后，我们正在探索将我们的库扩展到传统视频通话之外的用例的方法，例如使用 Web 程序集在浏览器应用程序中使用 RSYS。