React Native 2018 年的状态
我们上次发布关于 React Native 的状态更新已经有一段时间了。
在 Facebook，我们比以往任何时候都更多地使用 React Native，并将其用于许多重要的项目。我们最受欢迎的产品之一是 Marketplace，它是我们应用中的顶级标签之一，每月有 8 亿人使用。自 2015 年创建以来，Marketplace 的所有部分都是用 React Native 构建的，包括应用不同部分的一百多个全屏视图。
我们还在应用的许多新部分中使用 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 和 bundler 可互换。我们知道破坏性更改的步伐可能难以跟上，因此我们希望找到减少主要版本发布次数的方法。最后，我们知道有些团队正在寻找更全面的文档，例如启动优化等主题，而我们在这些方面的专业知识尚未被写下来。预计在未来一年中会看到其中一些变化。
如果您正在使用 React Native，您就是我们社区的一份子；请继续告诉我们如何使 React Native 对您更好。
React Native 只是移动开发人员工具箱中的一个工具，但我们坚信它——并且我们每天都在使其变得更好，在过去一年中，有来自 500 多名贡献者的 2500 多次提交。