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 优势的机会。
在过去的一年中，我们一直与微软和 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 之前，微软已经在 Office 和 Windows 10 中使用 React 构建原生桌面体验。
总结
总之，我们的愿景是将 React Native 的触角扩展到移动领域之外，并且我们已经开始与 Facebook 的桌面和 VR 团队合作。我们知道，当我们接受每个平台的平台约束、吸取机构知识并从其他参与者那里获得灵感时，它将惠及生态系统中的每个平台。最重要的是，在这样做的过程中，我们始终坚持 我们的指导原则。
我们对未来充满期待，我们将继续探索众多平台为 React Native 带来的可能性。关注我们 (@reactnative) 获取更多更新并分享您的想法！