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 团队在改进 Web 体验方面的投入正在使 React Native 在原生平台上受益。
竞争驱动创新
除了特定领域的工程师、线下聚会和会议之外，每个平台还带来了其他独特的参与者来解决类似问题。在 Web 端，React（直接为 React Native 提供支持）经常从其他开源 Web 框架中汲取灵感，例如 Vue、Preact 和 Svelte。在移动端，React Native 受到了其他开源移动框架的启发，我们也在向 Facebook 内部构建的其他移动框架学习。
我们相信，从长远来看，竞争会为每个人带来更好的结果。通过研究每个平台上其他参与者的优点，我们可以吸取可能适用于其他平台的经验。例如，简化复杂网站的竞争影响了 React 的开发，并使 React Native 在为移动应用提供声明式框架方面抢占先机。对更快迭代周期和 Web 构建时间的需求也促成了 Fast Refresh 的开发，这极大地使 React Native 受益。同样，我们内部移动框架中的性能优化——尤其是在数据获取和并行化方面——促使我们以一种也影响 React 的方式改进 React Native，当时我们构建了新的 Facebook.com 网站。
React 和 Relay 为 Facebook.com 网站提供支持。
拓展到新平台
React 和 React Native 正处于一个转折点。React 已经开启了 React 18 版本的发布之路，并且新的 React Native 渲染器现已全面为 Facebook 移动应用提供支持。今年，我们的团队规模大幅增长，以支持 React Native 在 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 的大部分开发仍将在内部进行，但我们希望能尽快分享更多内容。我们也预计 React Native 在 VR 方面的改进将会在开源项目中出现。例如，我们预计针对 VR 用例减少内存使用的项目，也将减少 React Native 在移动和桌面体验中的内存使用。
React 和 Relay 为 Oculus Home 和许多其他虚拟现实体验提供支持。
回顾行业如何采用 React，社区一直渴望在更多平台上使用 React。甚至在我们向社区宣布 React Native 之前，Netflix 就已经在使用 React 打造 Gibbon，他们用于构建电视体验的自定义渲染器。而在 Facebook 开始为桌面端构建 Messenger 之前，Microsoft 已经在 Office 和 Windows 10 中使用 React 构建原生桌面体验。
总结
总之，我们的愿景是将 React Native 的影响力扩展到移动领域之外，并且我们已经通过与 Facebook 的桌面和 VR 团队合作开始了这项工作。我们知道，当我们拥抱每个平台的约束、从机构知识中学习并从其他参与者那里汲取灵感时，它会使生态系统中的每个平台受益。最重要的是，通过这样做，我们忠于我们的指导原则。
我们对未来充满期待，因为我们将继续探索多平台为 React Native 带来的可能性。关注我们（@reactnative）以获取更多更新并分享您的想法！