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 内部的社区之外，我们也很高兴看到 Facebook 之外蓬勃发展的 React Native 用户和贡献者群体。我们希望通过更好地服务 React Native 用户并使项目更易于贡献来更多地支持 React Native 社区。
正如我们的架构更改将帮助 React Native 与其他原生基础设施更清晰地互操作一样，React Native 在 JavaScript 方面也应该更轻量，以更好地适应 JavaScript 生态系统，这包括使 VM 和打包器可互换。我们知道破坏性更改的速度可能难以跟上，因此我们希望找到方法来减少主要版本发布。最后，我们知道有些团队正在寻求更详尽的文档，例如启动优化等主题，而我们的专业知识尚未记录下来。预计在未来一年内会看到其中一些变化。
如果您正在使用 React Native，您就是我们社区的一员；请继续告诉我们如何才能让 React Native 为您做得更好。
React Native只是移动开发人员工具箱中的一个工具，但我们坚信它——而且我们每天都在让它变得更好，去年有500多名贡献者提交了2500多次提交。