React Native 的多平台愿景
React Native 在提高移动开发的标准方面非常成功，无论是在 Facebook 还是在行业内的其他地方。随着我们以新的方式与计算机互动，以及新的设备被发明出来，我们希望 React Native 能够为所有人服务。虽然 React Native 最初是为了构建移动应用而创建的，但我们相信，专注于多个平台并根据每个平台的优势和约束进行构建具有共生效应。当我们把这项技术扩展到桌面和虚拟现实时，我们看到了巨大的好处，我们很高兴分享这对 React Native 的未来意味着什么。
尊重平台
我们的首要指导原则是符合人们对每个平台的期望。Android 用户希望使用 TalkBack 的无障碍应用。导航应该像其他 Android 应用一样工作。按钮应该看起来和感觉起来像 Android 上的按钮。它不应该看起来和感觉起来像 iOS 按钮。虽然我们力求提供一致的跨平台开发者体验，但我们抵制牺牲用户期望的诱惑。
我们相信 React Native 使开发者能够在满足用户期望的同时，也获得更好的开发者体验的好处。在本节中，我们将分享以下内容
- 通过拥抱平台约束，我们实际上改善了其他平台上的体验。
- 我们可以从机构知识中学习，以构建更高层次的跨平台抽象。
- 每个平台上的其他参与者都激励我们构建更好的开发者和用户体验。
拥抱平台约束
特定的设备硬件或用户期望施加了独特的约束和要求。例如，Android 和 VR 头戴设备上的内存通常比 iOS、macOS 和 Windows 上更受限。再举一个例子，用户希望移动应用几乎立即启动，但当桌面应用启动时间较长时，他们不太会感到沮丧。我们发现，通过使用 React Native 解决这些问题，我们可以更容易地借鉴为一个平台学习到的经验和编写的代码，并将其应用于其他平台。
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 如何以不同方式处理辅助功能的影响。这使我们能够构建一个通用接口，从而改进了移动平台上辅助功能提示的处理方式。
再举一个例子，我们对 Web 上用户感知速度的研究导致了并发功能（如 Suspense）。在过去一年中，这些功能已通过新的 Facebook.com 网站进行了审查。现在，借助我们的新渲染器，这些功能正在进入 React Native，并影响我们如何设计事件调度和优先级。React 团队在改善 Web 体验方面的投资正在使 React Native 受益于原生平台。
竞争驱动创新
除了特定领域的工程师以及聚会和会议之外，每个平台还带来了其他独特的参与者来解决类似的问题。在 Web 上，React（直接为 React Native 提供支持）经常从其他开源 Web 框架（如 Vue、Preact 和 Svelte）中汲取灵感。在移动端，React Native 受到了其他开源移动框架的启发，并且我们一直在向 Facebook 内部构建的其他移动框架学习。
我们相信，从长远来看，竞争会为每个人带来更好的结果。通过研究每个平台上其他参与者的出色之处，我们可以学习到可能适用于其他平台的经验教训。例如，简化复杂网站的竞赛影响了 React 的开发，并使 React Native 在为移动应用提供声明式框架方面抢占了先机。对 Web 更快的迭代周期和构建时间的需求也导致了快速刷新的开发，这极大地惠及了 React Native。同样，我们内部移动框架中的性能优化（尤其是在数据获取和并行化方面）促使我们改进 React Native，这种改进也影响了我们在构建新的 Facebook.com 网站时的 React。
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 上进行。
React Native 为 Windows 和 macOS 上的 Messenger 视频通话提供支持。
我们还在与 Facebook Reality Labs 更紧密地合作，以了解 React 如何以独特的优势为 Oculus 提供虚拟现实体验。使用 React Native 在 VR 中构建体验将特别有趣，因为内存约束更严格，用户对交互延迟更敏感。
与我们处理移动版 React Native 的方式类似，我们将在 Facebook 规模上验证我们的技术，然后再公开分享任何内容。很多东西仍在变化，我们仍然有很多问题。我们希望在与社区分享之前，确信这项技术已准备好投入生产且可靠。
虽然 VR 的大部分开发仍将在内部进行，但我们希望尽快分享更多信息。我们还预计，VR 的 React Native 改进将在开源中浮出水面。例如，我们预计，为 VR 用例减少内存使用量的项目也将减少移动和桌面体验中 React Native 的内存使用量。
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) 以获取更多更新并分享您的想法！