React Native 2018 年状态

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

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

我们还在应用的许多新部分中使用 React Native。如果您观看了上个月的 F8 主题演讲，您会认出 Blood Donations、Crisis Response、Privacy Shortcuts 和 Wellness Checks——所有最近使用 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 内部的社区外，我们很高兴在 Facebook 之外拥有蓬勃发展的 React Native 用户和协作者群体。我们希望更多地支持 React Native 社区，既要更好地服务 React Native 用户，也要使项目更容易贡献。

正如我们的架构更改将帮助 React Native 与其他原生基础设施更清晰地互操作一样，React Native 在 JavaScript 方面也应该更精简，以便更好地适应 JavaScript 生态系统，其中包括使 VM 和 bundler 可互换。我们知道重大更改的步伐可能难以跟上，因此我们希望找到减少主要版本发布次数的方法。最后，我们知道一些团队正在寻找更全面的文档，例如启动优化等主题，我们在这些主题中的专业知识尚未编写下来。预计在未来一年中会看到其中一些变化。

如果您正在使用 React Native，您就是我们社区的一份子；请继续告诉我们如何使 React Native 对您更好。

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