跳到主要内容

React Native 的多平台愿景

·阅读时长 9 分钟
Christine Abernathy
Christine Abernathy
Meta 开发者倡导者
Eli White
Eli White
Meta 软件工程师
Luna Wei
魏璐娜
Meta 软件工程师
Timothy Yung
Timothy Yung
Meta 软件工程师

React Native 在提升移动开发标准方面取得了巨大成功，无论是在 Facebook 内部还是在行业其他地方。随着我们以新的方式与计算机互动，以及新设备的不断发明，我们希望 React Native 能够为每个人服务。尽管 React Native 最初是为了构建移动应用而创建的，但我们相信，专注于多平台并根据每个平台的优势和限制进行开发具有共生效应。当我们将这项技术扩展到桌面和虚拟现实时，我们已经看到了巨大的好处，我们很高兴能分享这对 React Native 的未来意味着什么。

尊重平台​

我们的第一个指导原则是符合人们对每个平台的期望。Android 用户希望应用程序支持 TalkBack 无障碍功能。导航应该像其他 Android 应用程序一样工作。按钮的外观和感觉应该与 Android 上的按钮一致，而不应该像 iOS 按钮。尽管我们力求提供一致的跨平台开发者体验，但我们抵制了牺牲用户期望的诱惑。

我们相信 React Native 能够帮助开发者满足用户期望，同时也能获得更好的开发者体验。在本节中，我们将分享以下内容：

  1. 通过拥抱平台限制，我们实际上改善了其他平台上的体验。
  2. 我们可以从现有知识中学习，构建更高级的跨平台抽象。
  3. 每个平台上的其他参与者激励我们构建更好的开发者和用户体验。

拥抱平台限制​

特定的设备硬件或用户期望会带来独特的限制和要求。例如，Android 和 VR 头显的内存通常比 iOS、macOS 和 Windows 更受限制。再比如，用户期望移动应用几乎瞬间启动，但桌面应用启动时间较长时，他们却不那么沮丧。我们发现，通过使用 React Native 解决这些问题，我们可以更轻松地借鉴为一个平台学习到的经验和编写的代码，并将其应用于其他平台。

Screenshot of Facebook Dating on mobile

React Native 和 Relay 为 Android 和 iOS 上超过 1000 个 Facebook 界面提供支持。

例如，React Native 依赖于一种称为“视图扁平化”的优化，这对降低 Android 上的内存使用至关重要。我们从未为 iOS 构建此优化，因为它没有相同的内存限制。在过去的几年中，随着我们构建新的跨平台渲染器，我们不得不重新实现“视图扁平化”。但这一次，它是用 C++ 而不是特定于平台的 Java 编写的。现在，在 iOS 上尝试相同的优化只需轻点开关。在生产环境的 Facebook 应用中，我们观察到这改善了 iOS 上的性能！我们可能永远不会为 iOS 构建此功能，但我们在 Android 上的投入能够使我们在 iOS 上的投入受益。

借鉴现有知识​

React Native 最初创建的原因之一是为了减少工程部门之间的壁垒。Android 工程师往往与开发相同产品的 iOS 工程师之间存在隔阂。Android 工程师为 Android 工程师评审代码，并参加 Android 聚会和会议。iOS 工程师为 iOS 工程师评审代码，并参加 iOS 聚会和会议。在不同平台上工作的工程师带来了关于如何构建卓越产品体验的独特领域和现有知识。

像 React Native 这样的跨平台框架最好的成果之一是它们如何将具有截然不同领域专业知识的工程师聚集在一起。我们相信，通过面向更多平台，我们可以加速平台专家之间现有知识的交叉传播。

例如，React Native 中的无障碍抽象受到了 Android、iOS 和 Web 各自以不同方式处理无障碍功能的影响。这使我们能够构建一个通用接口，改进在两个移动平台上处理无障碍提示的方式。

另一个例子是，我们对用户在网络上对速度感知的研究促成了像 Suspense 这样的并发功能。在过去的一年里，这些功能通过新的 Facebook.com 网站进行了验证。现在，随着我们的新渲染器，这些功能正进入 React Native，并影响我们如何设计事件调度和优先级。React 团队为改善网络体验所做的投入正在使原生平台上的 React Native 受益。

竞争推动创新​

除了特定领域的工程师、聚会和会议，每个平台也带来了其他解决类似问题的独特参与者。在网络上，React（直接为 React Native 提供支持）经常从其他开源网络框架中汲取灵感，例如 Vue、Preact 和 Svelte。在移动端，React Native 受到了其他开源移动框架的启发，我们一直在学习 Facebook 内部构建的其他移动框架。

我们相信，从长远来看，竞争会为每个人带来更好的结果。通过研究每个平台上其他参与者的优点，我们可以吸取可能适用于其他平台的经验。例如，简化复杂网站的竞争影响了 React 的开发，并为 React Native 提供了一个先发优势，可以为移动应用提供声明性框架。对更快迭代周期和更短构建时间的需求也促成了 Fast Refresh 的开发，这极大地惠及了 React Native。同样，我们内部移动框架的性能优化——尤其是在数据获取和并行化方面——促使我们改进 React Native，这也影响了我们在构建新的 Facebook.com 网站时的 React。

Screenshot of the Facebook.com website

React 和 Relay 为 Facebook.com 网站提供支持。

扩展到新平台​

React 和 React Native 正处于一个转折点。React 已开始走向 React 18 发布，并且 新的 React Native 渲染器现在已全面支持 Facebook 移动应用。为了支持 Facebook 内部日益增长的应用，我们的团队今年大幅壮大。其他平台上的开发团队已经注意到这种应用情况，并看到了他们也能从 React Native 中获益的机会。

在过去的一年里，我们一直在与 Microsoft 和 Messenger 团队合作，为 Windows 和 macOS 创建真正的原生视频通话体验。由于我们对移动应用的启动时间要求非常严格，我们最初使用 React Native 实现的桌面视频通话完全超越了它所取代的 Electron 实现的性能。在构建此体验的最初几周，我们录制了我们调整带有多个实时视频通话的窗口的视频，并惊叹于其流畅的帧率。

桌面应用的开发对我们来说非常令人兴奋。我们借鉴了构建移动体验的知识，并将其应用于桌面，目光开阔。我们通过多个子窗口、菜单栏、系统托盘等扩展了我们的视野。随着我们继续协作开发新的桌面 Messenger 功能，我们希望找到影响我们在 Web 和移动端构建方式的机会。如果您想了解最新进展，我们的桌面协作工作正在 GitHub 上进行。

Screenshot of the Messenger app on macOS

React Native 为 Windows 和 macOS 上的 Messenger 视频通话提供支持。

我们还在与 Facebook Reality Labs 更加紧密地合作，以了解 React 如何独特地为 Oculus 提供虚拟现实体验。由于内存限制更严格以及用户对交互延迟的敏感性，使用 React Native 在 VR 中构建体验将尤其有趣。

类似于我们处理移动端 React Native 的方式，我们将在 Facebook 规模上验证我们的技术，然后才会公开分享任何内容。很多事情仍在变化中，我们仍然有很多问题。我们希望在与社区分享之前，确信该技术已可用于生产且可靠。

尽管 VR 的大部分开发仍将在内部进行，但我们希望尽快分享更多信息。我们还预计，针对 VR 的 React Native 改进将出现在开源中。例如，我们预计为 VR 用例减少内存使用量的项目也将减少移动和桌面体验中 React Native 的内存使用量。

Screenshot of Oculus Home in virtual reality

React 和 Relay 为 Oculus Home 和许多其他虚拟现实体验提供支持。

当我们回顾行业如何采用 React 时，社区中一直渴望在更多平台上使用 React。甚至在我们向社区宣布 React Native 之前，Netflix 就已经开始制作 Gibbon，这是他们用于使用 React 构建电视体验的自定义渲染器。在 Facebook 开始为桌面构建 Messenger 之前，Microsoft 就已经在使用 React 在 Office 和 Windows 10 中构建原生桌面体验。

总结​

总而言之，我们的愿景是将 React Native 的覆盖范围扩展到移动设备之外，我们已经开始与 Facebook 的桌面和 VR 团队合作。我们知道，当我们拥抱每个平台的约束，学习现有知识，并从其他参与者那里汲取灵感时，它会使生态系统中的每个平台都受益。最重要的是，这样做，我们始终忠于 我们的指导原则。

随着我们继续探索多平台为 React Native 带来的可能性，我们对未来充满期待。与我们联系 (@reactnative) 以获取更多更新并分享您的想法！