React Native发布重构路线图

React Native做为时下最热门的跨平台开发方案，在这两年的移动跨平台方案中可谓一枝独秀，在不少的移动产品中均可以看到它们的影子，相比国内的Weex，RN的迭代更加频繁，性能上也无限的接近原生应用。不过，RN从性能上来讲仍是有提高的可能，因此，在今年的6月份，也便是Facebook刚刚发布了 React Native 0.56后，React工程经理 Sophie Alpert 在其官方博客上宣布他们将要重构 React Native，使其更轻量，更适应 JavaScript 生态圈的发展。

React Native宣布重构

React Native应用现状

Sophie Alpert 说，在 Facebook 内部，他们比以往任什么时候候都重视 React Native，它已经被用于 Facebook 许多重要的项目上。包括他们最受欢迎的产品之一 Marketplace，每个月有 8 亿人使用。

React Native 也开始被应用在应用程序的其余地方，若是读者上个月观看了 F8 主题演讲，就会发现 Blood Donations、Crisis Response、Privacy Shortcuts 和 Wellness Checks 的全部新功能都是使用 React Native 构建的。

Facebook 主应用之外的项目也在使用 React Native。新的 Oculus Go VR 头戴式设备对应的移动应用程序就彻底使用 React Native 构建。

Sophie Alpert 表示，React Native 的目标历来都不是替代其余技术，他们专一于 React Native 自身，努力使之变得更好，但他们但愿看到其余团队从 React Native 中获得一些想法或灵感，例如将即时从新加载技术运用到非 JavaScript 代码中。

React Native采用的架构

React Native 项目的设计初衷是成为 JavaScript 和原生应用之间的桥梁。React DOM 将 React 的状态更新变成了命令式、可变的 DOM API 调用，如 document.createElement(attrs) 和.appendChild()，而 React Native 则返回一个单独的 JSON 消息，它列出了要执行的一些操做，如 [["createView", attrs], ["manageChildren", ...]]。

他们将整个系统设计为永不依赖获取同步响应，并确保列表中全部的内容均可以彻底序列化为 JSON，并能够反序列化回来。

这样作是为了提升灵活性：在这个架构之上，能够构建像 Chrome 调试器之类的工具，这些工具能够经过 WebSocket 链接异步运行全部的 JavaScript 代码。

在过去的 5 年里，他们发现最初的设计原则加大了某些特性的开发难度。异步桥接（asynchronous bridge）意味着不能直接将 JavaScript 逻辑与不少原生 API 集成在一块儿，由于这些原生 API 是同步的。

批量桥接（本地调用队列）意味着 React Native 应用程序调用本地函数会更加困难。并且串行化的桥接意味着没必要要的复制，由于它不是直接在两个世界之间共享内存。对于彻底使用 React Native 构建的应用程序，这些限制一般是可承受的。但对于在 React Native 与现有应用程序代码之间进行复杂集成的应用程序，就很糟糕了。

所以，Facebook 正在对 React Native 进行大规模重构，让框架变得更加灵活，并更好地与 JavaScript / 原生混合应用中的原生基础设施集成。

经过这个项目，他们将应用在过去 5 年中学到的知识，逐步让架构走向现代化。他们正在重构 React Native 内部，大部分工做都是在底层进行的，现有的 React Native 应用程序几乎不须要作出更改。为了使 React Native 更轻量化并能更好地适应现有的原生应用，这次重构主要从三个方面进行。

首先，改变线程模型。UI 更新再也不须要在三个不一样的线程上执行，能够在任意线程上同步调用 JavaScript 进行优先更新，同时将低优先级工做推出主线程，以便保持对 UI 的响应。

其次，将异步渲染功能引入 React Native 中，容许执行多个渲染并简化异步数据处理。

最后，简化桥接，让它更快、更轻量。原生和 JavaScript 之间的直接调用效率更高，而且能够更轻松地构建调试工具，如跨语言堆栈跟踪。

完成以上工做以后，就有可能带来更紧密的集成。如今，若是不经过复杂 hack 的手段就没法让原生导航和手势处理或原生组件（如 UICollectionView 和 RecyclerView）一块儿工做。在对线程模型作出更改以后，就能够直接构建这样的功能。

React Native重构线路

重构的细节

最近，Facebook官方公布了一些RN项目重构上的细节，主要会从如下一些方面来推进项目的进行。

1. 让 RN 的 GitHub 存贮库更健康，issues 和 pull 请求将及时获得处理；

• 提升测试覆盖率

• 从 Facebook 代码存储库同步的 Commits 不能违背开源测试的准则

• 提高社区的贡献量

2. 稳定 API，使之更容易与开源依赖项交互；

• Facebook 使用与开源相同的公共 API

• React Native 将遵循语义版本标准

3. 让生态系统更加有活力，社区将提供高质量的 ViewManagers、native modules、多平台支持；

4. 文档优化，专一于帮助用户建立高质量的体验，以及最新的 API 参考文档。

RN 团队的目标是经过删除非核心和无用的组件来简化 RN，将非核心组件转移到社区，让开发者使用更加便捷，他们目前已经决定将这些组件的全部权为社区所拥有：github.com/react-nativ…

例如，WebView就是其中的一个实例： WebView组件剥离

同时，为了更好的服务React Native，React Native官方将从如下几个方面进行优化。

开源内部开发工具

因为 Facebook 内部开发人员用的是内部开发工具，开发体验与开源的彻底不一样，在开源社区受欢迎的那些工具可能并无被 Facebook 开发人员使用，在某些状况下，Facebook 团队已经习惯使用仅限 Facebook 内部使用的工具，这种内外差别可能会很大程度影响他们接下来的重构工做。

为此，他们作了以下改进：

• 开源 JSI，使社区可以使用本身的 JavaScript VMs，从 RN 的初始版本中替换现有的 JavaScriptCore，有关 JSI 的信息，他们将来会公布，如今你能够先经过 React Conf 大会上的演讲视频了解：www.youtube.com/watch?v=Ucq…

• 支持 Android 上的 64 位库；

• 新架构下支持调试；

• 改进对 CocoaPods、Gradle、Maven 和新 Xcode 构建系统的支持。

改善测试基础设施

当 Facebook 工程师发布代码时，若是经过全部测试，则认为代码能够上线了，这些测试能够判断某些改动是否会破坏 React Native，因为 Facebook 使用 React Native 的方式与外部存在差别，他们可能在不知不觉中破坏了开源环境中的 React Native。

为此，Facebook 将支持内部测试，确保它们在尽量接近开源的环境中运行。这将有助于防止被破坏的代码开源。同时，他们还将致力于建设测试基础设施，以便在 GitHub 上更好地测试核心存储库，使将来的 pull 请求可以包含在测试里。

公共 API

Facebook 将经过公共 API 使用 React Native，和开源同样，以减小无心间的破坏性更改，他们的目标是融合稳定的公共 API，并在 v1.0 中采用语义版本控制标准。

反馈交流

React Native 是 GitHub 上贡献者数量最多的开源项目之一（排名第二），将来，Facebook 将继续致力于贡献者相关的举措，例如提升透明度和公开讨论。对新手来讲，文档将是一个大问题，为此，RN 将建立自动生成的 API 参考文档，改善用户体验。

RN 团队称，这些项目将在明年完成，其中，JSI 项目已经在进行中，其余的一些改进如简化 RN，还须要更多的时间去完成，开发者有任何问题能够在提案中讨论，如下是连接地址。

注，本文来自于《React Native官网》。若是你对RN有兴趣，或者还停留在观望和入门的边缘，能够看一些我以前的书《React Native移动开发实战》，若是有任何技术问题，也能够进群交流：515980159。