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