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 各自处理无障碍的不同方式的影响。这使我们能够构建一个通用接口，从而改善了移动平台上无障碍提示的处理方式。
又例如，我们对用户在网络上感知速度的研究促成了诸如 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 的方式改进了 React Native，尤其是在我们构建新的 Facebook.com 网站时。
React 和 Relay 为 Facebook.com 网站提供支持。
扩展到新平台
React 和 React Native 正处于一个转折点。React 已经开始了 React 18 版本的发布之路，而新的 React Native 渲染器现在已完全为 Facebook 移动应用程序提供支持。今年，我们的团队规模大幅增长，以支持 Facebook 内部不断增长的采用率。在其他平台上进行开发的团队也注意到了这种采用，并看到了他们也能从 React Native 中获益的机会。
在过去的一年里，我们一直在与 Microsoft 和 Messenger 团队合作，为 Windows 和 macOS 创建真正的原生视频通话体验。由于我们对移动应用启动时间的严格要求，我们最初使用 React Native 实现的桌面视频通话完全超越了它所取代的 Electron 实现的性能。在构建这种体验的最初几周里，我们录制了我们调整带有多个实时视频通话的窗口的视频，并惊叹于其流畅的帧速率。
为桌面平台开发一直让我们非常兴奋。我们带着开阔的视野，将我们所知的移动体验构建知识应用到桌面平台。我们拓展了视野，实现了多个子窗口、菜单栏、系统托盘等等。随着我们继续协作开发新的桌面 Messenger 功能，我们期望找到影响我们在网络和移动端构建方式的机会。如果您想了解最新信息，我们的桌面协作工作正在 GitHub 上进行。
React Native 为 Windows 和 macOS 上的 Messenger 视频通话提供支持。
我们还与 Facebook Reality Labs 开展更密切的合作，以了解 React 如何独特地定位以在 Oculus 上提供虚拟现实体验。
与我们处理移动端 React Native 的方式类似，我们将在 Facebook 范围内验证我们的技术，然后再公开发布任何内容。许多事情仍在变化，我们仍有许多疑问。我们希望在与社区分享之前，确信该技术已可用于生产环境且可靠。
尽管 VR 的大部分开发仍将在内部进行，但我们希望尽快分享更多信息。我们还预计，对 VR 版 React Native 的改进也将以开源形式出现。例如，我们预计针对 VR 用例减少内存使用的项目也将减少移动和桌面体验中 React Native 的内存使用。
React 和 Relay 为 Oculus Home 和许多其他虚拟现实体验提供支持。
当我们回顾行业如何采用 React 时，社区中总是渴望在更多平台上使用 React。甚至在我们向社区宣布 React Native 之前，Netflix 就已经开始打造 Gibbon，他们用于使用 React 构建电视体验的自定义渲染器。在 Facebook 开始为桌面版 Messenger 构建之前，微软就已经在使用 React 构建 Office 和 Windows 10 中的原生桌面体验。
总结
总而言之，我们的愿景是扩展 React Native 的影响力，使其超越移动端，我们已经通过与 Facebook 的桌面和 VR 团队合作来实现这一目标。我们深知，当我们拥抱每个平台的约束、学习机构知识并从其他参与者那里汲取灵感时，生态系统中的每个平台都会受益。最重要的是，通过这样做，我们忠于我们的指导原则。
随着我们继续探索多平台为 React Native 带来的可能性，我们对未来充满期待。请关注我们 (@reactnative) 以获取更多更新并分享您的想法！