跳至主内容

React Native 的多平台愿景

· 1 分钟阅读
Christine Abernathy
Christine Abernathy
Developer Advocate @ Meta
Eli White
Eli White
Software Engineer @ Meta
Luna Wei
Luna Wei
Software Engineer @ Meta
Timothy Yung
Timothy Yung
Software Engineer @ Meta
非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →

React Native 在提升移动开发标准方面取得了巨大成功，无论是在 Facebook 内部还是整个行业。随着我们以新方式与计算机交互以及新设备的不断涌现，我们希望 React Native 能够服务于所有人。尽管 React Native 最初是为构建移动应用而创建的，但我们相信聚焦多平台开发、针对每个平台的优势和约束进行构建能产生共生效应。当我们将这项技术扩展到桌面和虚拟现实领域时，已经看到了巨大收益，我们非常期待分享这对 React Native 未来的意义。

尊重平台特性​

我们的首要指导原则是匹配用户对每个平台的期望。Android 用户期待使用 TalkBack 的无障碍应用，导航方式应符合 Android 应用惯例，按钮的外观和触感应保持 Android 原生风格——而非 iOS 风格。尽管我们追求提供一致的跨平台开发体验，但绝不牺牲用户期望。

我们相信 React Native 能让开发者在满足用户期望的同时，获得更优的开发体验。本节将分享以下观点：

  1. 拥抱平台约束实际上能提升其他平台的体验

  2. 通过借鉴机构知识可构建更高级的跨平台抽象层

  3. 各平台的其他实践者启发我们打造更优的开发与用户体验

拥抱平台约束​

特定设备硬件或用户期望带来独特的约束与需求。例如 Android 和 VR 头显的内存限制通常比 iOS/macOS/Windows 更严格；用户期望移动应用近乎瞬时启动，但对桌面应用的启动延迟容忍度更高。我们发现通过 React Native 处理这些问题时，能更便捷地复用跨平台经验与代码。

Screenshot of Facebook Dating on mobile

React Native and Relay power over 1000 Facebook surfaces on Android and iOS.

例如 React Native 依赖"视图扁平化(view flattening)"优化来降低 Android 内存占用。由于 iOS 不存在同等内存约束，我们从未为其实现此优化。但在构建新型跨平台渲染器时，我们使用 C++（而非平台特定的 Java）重新实现了该功能。现在只需轻触开关即可在 iOS 启用此优化——在 Facebook 生产环境中，我们观察到 iOS 性能因此提升！若非在 Android 的投入带来技术迁移，我们可能永远不会为 iOS 构建此优化。

学习机构知识​

创建 React Native 的初衷之一是打破工程壁垒。开发同款产品时，Android 工程师往往与 iOS 工程师形成信息孤岛：前者相互评审代码、参加 Android 技术会议，后者亦然。不同平台工程师各自掌握构建卓越产品体验的领域知识与机构经验。

React Native 等跨平台框架最显著的成果，就是将拥有迥异领域专长的工程师凝聚起来。我们相信通过覆盖更多平台，能加速平台专家间的知识交叉融合。

典型案例是 React Native 的无障碍抽象层：它融合了 Android/iOS/Web 的不同实现方式，最终构建出改进移动平台无障碍提示处理的通用接口。

另一案例来自我们对 Web 速度感知的研究：由此诞生的并发特性（如 Suspense）经过新版 Facebook.com 验证后，正通过新型渲染器融入 React Native，并影响着事件调度与优先级的设计。React 团队改进 Web 体验的投入，正在反哺原生平台的 React Native。

竞争驱动创新​

除了特定领域的工程师、行业会议和活动外，每个平台还有独特的参与者解决着相似问题。在 Web 领域，React（直接赋能 React Native）经常从其他开源框架如 Vue、Preact 和 Svelte 汲取灵感。在移动端，React Native 受到其他开源移动框架启发，同时我们也持续学习 Facebook 内部构建的其他移动框架。

我们相信长期来看，竞争最终会让所有人受益。 通过研究各平台优秀参与者的成功要素，我们可以获取适用于其他平台的宝贵经验。例如：简化复杂网站的需求竞赛推动了 React 的发展，使 React Native 得以快速为移动应用提供声明式框架；Web 领域对快速迭代周期和构建速度的需求催生了 Fast Refresh 功能，该功能显著提升了 React Native 的开发体验；同样地，我们内部移动框架的性能优化（尤其在数据获取和并行处理方面）促使 React Native 改进，这些改进最终也影响了 React 在构建新版 Facebook.com 网站时的设计决策。

Screenshot of the Facebook.com website

React and Relay powers the Facebook.com website.

向新平台扩展​

React 和 React Native 正处于转折点。React 已启动 React 18 的发布进程，而全新的 React Native 渲染器现已全面支撑 Facebook 移动应用。今年我们团队大幅扩充，以支持 Facebook 内部日益增长的应用需求。其他平台的开发团队也注意到这一趋势，看到了采用 React Native 可能带来的技术红利。

过去一年，我们与微软和 Messenger 团队深度合作，在 Windows 和 macOS 上打造了真正原生的视频通话体验。 由于我们对移动应用启动速度的极致要求，基于 React Native 的桌面视频通话初始实现就全面超越了其替代的 Electron 方案性能。在开发初期的几周里，我们反复录制多路实时视频通话的窗口缩放过程，惊叹于其流畅的帧率表现。

桌面端开发令我们倍感振奋。在充分认知差异的基础上，我们将移动端开发经验迁移到桌面领域，同时拓展了多子窗口、菜单栏、系统托盘等新视野。随着桌面版 Messenger 新功能的持续开发，我们预期这些经验将反哺 Web 和移动端的构建模式。若您想了解最新进展，我们的桌面协作项目正在 GitHub 持续推进。

Screenshot of the Messenger app on macOS

React Native powers Video Calling in Messenger for Windows and macOS.

我们也正与 Facebook Reality Labs 紧密合作，探索 React 在 Oculus 平台实现虚拟现实体验的独特优势。 使用 React Native 构建 VR 体验将面临内存限制更严格、用户对交互延迟更敏感等特殊挑战。

与移动端 React Native 的推进策略类似，我们将先在 Facebook 内部验证该技术的规模适用性，再向社区公开。当前仍有许多变化和待解问题，我们希望确保技术达到生产级可靠标准后再与社区分享。

虽然 VR 领域的大部分开发仍将保持内部进行，但我们期待尽快分享更多成果。同时，React Native 在 VR 方向的改进预计将陆续在开源版本中呈现。例如：针对 VR 场景的内存优化项目，同样会降低移动端和桌面端 React Native 的内存占用。

Screenshot of Oculus Home in virtual reality

React and Relay power the Oculus Home and many other virtual reality experiences.

回顾 React 技术的行业应用历程，社区始终对多平台扩展充满热情。早在 React Native 正式发布前，Netflix 就已开发了基于 React 的 TV 体验定制渲染器 Gibbon；而 Facebook 启动桌面版 Messenger 项目前，微软已在 Office 和 Windows 10 中使用 React 构建原生桌面体验。

总结​

总之，我们的愿景是将 React Native 的应用范围扩展到移动端之外，目前已经通过与 Facebook 的桌面和 VR 团队展开合作迈出了第一步。我们深知：当拥抱每个平台的约束、学习机构知识并从其他实践者处汲取灵感时，整个生态系统的所有平台都将受益。最重要的是，在此过程中，我们始终恪守指导原则。

在继续探索多平台为 React Native 带来的可能性时，我们对未来的发展充满期待。请通过 @reactnative 与我们联系，获取最新动态并分享您的想法！