React Native：前端工程师也能创建真正的本地移动 APP

今年三月份， Facebook 开源了 React Native 。下面是 Tom Occhino 在博客上介绍 React Native 的文章。

一切都是从 React 开始

两年前 Facebook 发布了 React ，从那以后，React 不管是在 Facebook 的内部还是外部都在高速的成长。其实没人强制我们使用 React，不过今天在 Facebook 里创建的新的 Web 项目，通常都会用到 React 去创建。在整个行业内，React 也是被广泛的使用。工程师们爱用 React，是因为它可以让工程师更多的去关注自己的产品。一段时间以后，我们才开始意识到是什么让 React 如此的强大。

React 强制我们要把应用分割成一些小的组件，每个组件都代表单独的视图，也就是应用里的某个部分的显示。这样我们就不再需要把整个系统都装到脑袋里才能修改其中的一小部分，这些小组件可以让我们更容易迭代自己的产品。而且在使用 React 开发的时候，代码变得可预测，这就让我们也更有自信的去快速迭代，应用也会更可靠。React 不仅让我们更容易去扩展应用，也更容易去扩大整个团队。

在 Web 上的快速迭代，让我们可以使用 React 创建牛 x 的产品，Facebook.com 上有很多组件也都是用 React 创建的。另外我们也在 React 之上创建了一些不错的框架，比如 Relay，它会让提取数据变得更容易一些。当然，Web 只是其中一部分，Facebook 也有大量的 Android 还有 iOS 应用，这些各种不同的平台，让我们很难去组织工程师团队，这也只是在开发移动应用的时候遇到的其中一个问题。

为什么本地应用很难

开发本地移动应用要比 Web 难很多。比如你想把东西放到屏幕上显示就不那么容易，我们经常要手工的去计算出视图的显示尺寸还有位置。还不能用到让扩展应用还有团队更容易的 React 与 Relay 这些东西。更难的是过渡到移动端的过程拖慢了我们的开发速度。

在创建 Web 的时候，简单的保存一下文件，然后再刷新一下浏览器就能立即看到修改的结果了。在移动端，你每回修改一个地方还得重新去编译一下，简单的比如让文字移动几个像素这种事你也得重新编译。这让我们的工作效率降低很多，特别是在代码库很大的时候，编译绝对是个特别难的事。

你想在本地应用上测试新功能会非常困难。在 Facebook 我们可以在一天提供两个版本的新网站，所以几乎是可以立即得到试验的结果。不过在移动端，我们通常得花一个礼拜或者一个月才能得到试验的结果，因为新版本 App 发布的没那么勤快。“快速行动” 是 Facebook 的 DNA，在移动端上，我们不能像在 Web 上一样跑的那么快。创建本地化的移动应用又是必须要做的事，因它会带来更好的用户检验。

为什么本地应用是必须的？

虽然创建本地的移动应用要花更多的时间。不过它还是必须要做的，因为它比 Web 有更好的用户体验。在本地应用上我们可以使用平台专有的一些界面组件，比如 maps，data pickers，switches，navigation stacks ... 虽然这些东西你也可以在 Web 上造出来，不过那个感觉是不一样的，很难有本地组件的体验，还有自己造的这些组件也不能随着平台的变化而自动的更新。在 Web 上还不能更好的使用手势。暂时还没有东西可以改善遇到的这些问题。

在 Web 上也没有更好的线程模型，就是你不能在多个线程上同时的工作。我们到是可以使用 Web Workers 在后台去处理应用里的一些逻辑，不过还是不能执行大量的计算，比如图像解码，文字测量等等，这些很难有效的从浏览器的主线程里面分离出来。这也可能是创建响应式高性能的 Web App 最大的难题。

两全其美

我们想要的是，本地移动应用的用户体验，还有在 Web 上使用 React 的开发体验。有几种方法大致可以实现：

使用 WebViews

把应用装到一个浏览器里，再加上一个本地应用的外壳。几年前我们用过这样的方法，也觉得这也是很棒的想法。不过在在实施的时候，它还是不能给我们想要的性能与扩展。这种方法到是非常灵活，因为你可以使用 Web 技术去开发，可以得到在 Web 上开发的快速迭代的好处，也可以使用 React 。不过，问题是所有的显示都是用的 Web 技术，这并不能得到真正的本地化的用户体验。

把 React 移植到本地

把 React 移植成本地的代码也是个挺好的想法，其实我们在 iOS 平台上做了这件事，ComponentKit 已经开源了，使用它你可以得到所有的在 React 上的好处，比如可预测的 UI ，同时也能得到在本地环境上的好处，比如平台专有的界面组件，手势的控制等等。而且 ComponentKit 还用了 flexbox 来布局，这样你就不需要手工计算应用里的视图的尺寸还有位置了。所以代码会更统一，也更容易维护。

不过还是也有几个不好的地方，比如它只能用在 iOS 平台上，想用在 Android 上还得再实施一次，并且还要教会工程师这玩意怎么用。另外我们也不能使用在 Web 上基于 React 创建的其它的一些东西，比如 Relay ，它解决了扩展提取数据的问题。更重要的是，我们并没有解决开发速度的问题，每回修改项目还是得重新再编译一下。

JavaScript

使用 JavaScript 去调用本地的 API，可以得到所有在本地环境上的东西，而且还可以更快的去迭代，还能使用我们在 JavaScript 上已有的一些基础设施。因为是 JavaScript，我们有可能会做到跨平台开发。听起来这就是我们想要的，也有很多框架已经在这么做的。不过有些问题必须要先解决，比如线程的管理。

React Native

React 组件是没副作用的纯函数，它会在任何时候返回视图需要的显示，而且不需要关心其它的事。在浏览器环境里，React 会遵守 DOM 的规则，不过又不限制于 DOM，React 牛 x 的是它的抽象层。React 可以用在任何视图系统上，比如 iOS 的 UIKit 。

这也就是，我们只需要花点功夫，就能让 React 用在真正的本地移动应用上面。在浏览器上运行 React 让它去显示 div 或者 span 这些东西。在移动环境上，我们可以让它运行在一个 JavaScriptCore 的嵌入实例里，把它再放到我们的应用里，去显示高级别的平台特有的组件。

而且使用 React Native，我们可以逐步去实施，你可以基于它去创建新的应用，或者可以在合适的时间与地方去改造已有的产品。就像我们，不可能一气重写 Facebook.com 上的所有的东西，我们可以一小块一小块的去使用 React Native 。

我们在 Facebook 使用 React Native 创建应用已经有一段时间了，虽然还是有很多要做的，不过从目前来看效果还是相当不错。我们追求的不是 “write once，run anywhere” ，因为不同平台有不同的风格，感觉，功能，所有我们还是需要单独去为不同的平台去开发应用。不过我们希望同一组工程师可以马上开始在他们创建的平台上去开发，不再需要单独为每个平台去学习不同的技术。我们管这种方法叫做 “learn once, write anywhere” 。

开源

Facebook 的目标就是连接世界并且开放，我们想通过开源不断的贡献达到这个目标。React Native 也不例外，我们意识到，作为一个工程师组织，自己遇到的问题别人也可能会遇到，我们想尽可能开放的去开发，跟其他人合作去解决遇到的挑战。