2018 年 React Native 现状

我们已经有一段时间没有发布关于 React Native 的状态更新了。

在 Facebook，我们比以往任何时候都更多地使用 React Native，并且将其用于许多重要的项目。我们最受欢迎的产品之一是 Marketplace，它是我们应用中顶级标签之一，每月有 8 亿人使用。自 2015 年创建以来，整个 Marketplace 都是使用 React Native 构建的，包括应用不同部分的 100 多个全屏视图。

我们还在应用的许多新部分中使用 React Native。如果您上个月观看了 F8 主题演讲，您就会认出献血、危机应对、隐私快捷方式和健康检查 - 所有这些都是最近使用 React Native 构建的功能。并且 Facebook 应用之外的项目也正在使用 React Native。新的 Oculus Go VR 头显包含 一个配套移动应用，该应用完全使用 React Native 构建，更不用说 React VR 为头显本身的许多体验提供支持了。

当然，我们也使用许多其他技术来构建我们的应用。Litho 和 ComponentKit 是我们在应用中广泛使用的两个库；两者都为构建原生屏幕提供了类似 React 的组件 API。React Native 从来没有目标要取代所有其他技术 - 我们专注于改进 React Native 本身，但我们很高兴看到其他团队借鉴 React Native 的想法，例如将 即时重载 带到非 JavaScript 代码中。

架构

当我们在 2013 年启动 React Native 项目时，我们将其设计为在 JavaScript 和原生之间拥有一个异步、可序列化和批处理的“桥梁”。就像 React DOM 将 React 状态更新转换为对 DOM API（如 document.createElement(attrs) 和 .appendChild()）的命令式、变异调用一样，React Native 被设计为返回一个列出要执行的变异操作的 JSON 消息，例如 [["createView", attrs], ["manageChildren", ...]]。我们设计了整个系统，使其永远不会依赖于获得同步响应，并确保该列表中的所有内容都可以完全序列化为 JSON 并返回。我们这样做是为了它带来的灵活性：在此架构之上，我们能够构建像 Chrome 调试 这样的工具，它通过 WebSocket 连接异步运行所有 JavaScript 代码。

在过去的 5 年里，我们发现这些初始原则使得构建某些功能变得更加困难。异步桥梁意味着您无法将 JavaScript 逻辑直接与许多期望同步答案的原生 API 集成。一个对原生调用进行排队的批处理桥梁意味着更难以让 React Native 应用调用以原生方式实现的功能。而可序列化桥梁则意味着不必要的复制，而不是在两个世界之间直接共享内存。对于完全使用 React Native 构建的应用，这些限制通常是可以忍受的。但对于在 React Native 和现有应用代码之间具有复杂集成的应用，它们令人沮丧。

我们正在对 React Native 进行大规模的重新架构，以使框架更加灵活，并更好地与混合 JavaScript/原生应用中的原生基础设施集成。 通过这个项目，我们将应用我们在过去 5 年中学到的经验教训，并逐步将我们的架构迁移到更现代的架构。我们正在重写 React Native 的许多内部组件，但大多数更改都在幕后进行：现有的 React Native 应用将继续工作，几乎无需或无需任何更改。

为了使 React Native 更加轻量级，并更好地融入现有的原生应用，此重新架构具有三个主要的内部更改。首先，我们正在更改线程模型。与其让每个 UI 更新都需要在三个不同的线程上执行工作，不如在任何线程上同步调用 JavaScript 以进行高优先级更新，同时仍将低优先级工作移出主线程以保持响应能力。其次，我们正在将 异步渲染 功能整合到 React Native 中，以允许多个渲染优先级并简化异步数据处理。最后，我们正在简化我们的桥梁，使其更快、更轻量级；原生和 JavaScript 之间的直接调用效率更高，并且将使构建像跨语言堆栈跟踪这样的调试工具变得更容易。

这些更改完成后，将能够实现更紧密的集成。如今，如果不使用复杂的技巧，就不可能整合原生导航和手势处理或像 UICollectionView 和 RecyclerView 这样的原生组件。在对线程模型进行更改后，构建此类功能将变得非常简单。

我们将在今年晚些时候发布有关此工作的更多详细信息，届时它将接近完成。

社区

除了 Facebook 内部社区之外，我们很高兴拥有一个蓬勃发展的 React Native 用户和合作者群体，他们来自 Facebook 之外。我们希望更多地支持 React Native 社区，方法是更好地为 React Native 用户提供服务，并使项目更容易参与贡献。

就像我们的架构更改将有助于 React Native 更干净地与其他原生基础设施互操作一样，React Native 应该在 JavaScript 端更精简，以更好地适应 JavaScript 生态系统，其中包括使 VM 和捆绑器可互换。我们知道破坏性更改的速度可能难以跟上，因此我们希望找到减少主要版本发布次数的方法。最后，我们知道一些团队正在寻找有关启动优化等主题的更详尽的文档，而我们的专业知识尚未记录在案。预计在未来一年中会看到其中一些变化。

如果您正在使用 React Native，那么您就是我们社区的一员；请继续告诉我们如何才能让 React Native 变得更好。

React Native 只是移动开发人员工具箱中的一个工具，但我们坚信它 - 并且我们每天都在使其变得更好，在过去的一年中，来自 500 多位贡献者的 2500 多次提交证明了这一点。