React Native: 把现代web技术带向移动端(二)

翻译

Why native is necessary

为什么 react 成为必须了呢

platform-specific UI component 特定于平台的UI组件
reimplemen 重新实现
sophisticated 负杂的
execute 执行
numeric computation 数值计算
efficiently 有效的
high-performance 高性能
remarkably 异常
Porting 移植
asynchronous 异步
more concise and easier to maintain. 更简洁，更易于维护。
minor downsides 轻微的负面影响
fundamentally 从根本上

虽然开发本地应用需要花费更长的时间，和 web 相比，为什么我们能生产用户体验更好的移动皮平台的应用产品，有很多的原因。期中之一就是我们访问了特定于平台的UI组件,例如地图，时间选择，按钮，以及分页栈。

It's possible to reimplement these components on the web, but our reimplementations never feel exactly like their native counterparts, and they also don't get updated automatically with changes to the platform.

在 web 端重新实现这些组件已经成为可能，但是，我们的重新实现和本地的组件不太一样，当平台改变时，他不会自动的更新。

We also don't have anything as sophisticated as the native mobile gesture recognizers on the web, and we don't yet have the proper tooling or the developer discipline needed to build a system that gets this right.

没有比在 web 端，实现本地移动的手势识别更复杂的事情了，而且，我们合适的工具或则是有这样能力去建立一个系统的开发规则。

在 web ，我们没有负责的线程模型，所以我们不能在多个线程里并行多个任务。

We can try to make use of web workers to execute some of our application logic in the background, but we can't yet perform highly numeric computation like image decoding or text measurement

我们尝试用 web 任务去后台执行应用逻辑，但是我们至今不能很好的进行像照片解码或是浏览器的主线程的高性能文本测量这样的数值基计算。

这是创建高性能的响应式web app 的巨大调战之一。

能两全其美么？

我们真正想要的是是我们在用 react 在 web 上开发的经验和本地移动平台的用户体验。这里有几个方法能让我们实现这样：
Using WebViews
使用 webViews

One possibility is to use WebViews inside simple native wrapper applications. We tried this a few years back, and we actually think it's a great idea.
期中一个可行的方法就是使用 webViews，包括简单的本币包装应用。我们几年前就开始尝试这个方法，并且我们觉得这个真是一个不错的主意。

While our implementation didn't give us the performance and scaling we wanted, this approach is remarkably flexible and comes with all the positives associated with the developer experience of the web, like the ability to take full advantage of React and the web's rapid iteration cycle. Unfortunately, because all the rendering is done using web tech, we can't produce a truly native user experience.

当我们的主键没有给我们预期的效果和规模时，这个方法就特别的灵活，并且negotiations和 web 开发经验能很好的关联在一起。就像是集合了react 的所有优点和 web 开发的快速迭代周期。不幸运的是，所有这些渲染都是通过 web 科技实现的，我们不能生产一个真正的本地用户体验。

Porting React to native

把 react 向本地 移植

Porting React to native code is also a great idea, and in fact, we built this for iOS! This project is called ComponentKit, and we just open sourced it yesterday at F8.

把 react 向本地编码 移植也是一个好注意，事实上，我们用这个方法创建 ios 应用。这个项目叫做 ComponentKit ，我们也在昨天将他开源。
With ComponentKit, we get all the benefits of React, especially declarative, predictable UIs, but we can also take advantage of the power of the native environment, with platform-specific components and sophisticated gesture handling, as well as asynchronous image decoding, text measurement, and rendering.

ComponentKit 项目里，我们集合了 react 的所有优点，特别是声明的可预测的ui，我们也获得了本地开发环境的特定平台ui 和负责的手势操作以及异步图像解码，文本测量和绘制。优势

Additionally, since ComponentKit uses flexbox for layout, you don't need to manually position and size the views in your application, so your code ends up being more concise and easier to maintain.

此外，自从ComponentKit 使用 flexbox 进行布局，你不再需要人工计算你的ying'y视图的定位和大小了。所以你的代码更简洁，更易于维护。

There are a couple of minor downsides to this approach, though. First, it's iOS-only, so if we want to take advantage of it on Android, we'd have to build a separate implementation, and teach engineers how to use it. Additionally, we don't have access to any of the stuff we've built for the web on top of React, like Relay, which helps us solve real problems we've faced scaling our data fetching. Most important, though, is that we haven't fundamentally improved our developer velocity challenge — we still need to recompile after every change.

这种方法有一些轻微的负面影响，首先，这仅限制于 ios 系统，所以如果我们想在安卓上也使用这些优点，我们需要建立一个单独的执行，然后教工程师们如何去使用他，此外，我们不需要获得我们用react建立的web 的任何东西，像 Relay 一样，这种技术能帮助我们解决我们测量数据规模的问题。更重要的是，虽然我们没有从根本上提高开发人员的速度，在每次改变之后我们还是需要进行编译。