React native 设计初衷

前言

这是《React native 学习之路》专栏的第一篇文章，主要想跟大家聊聊在 RN 立项之前 Facebook 团队遇到了什么问题，以及他们是如何解决的

我认为想要了解一个人最简单的方式就是去看看 ta 的来时路，人如此代码亦是如此，了解这些背景有利于我们在后续研究代码时理解 RN 团队是如何在不同的解决方案中进行权衡

那么废话少说，正文开始：

本节资料来自 RN 团队的第一篇博客：engineering.fb.com/2015/03/26/...

2013 年 Facebook 的团队第一次发布了 React。React 的成功极大提升了研发的效率，使得 Facebook 网站得以两天发一次版本，并以极快的速度验证 A/B 实验的结果。

但是在原生 APP 的场景下，情况有些变化：在更丝滑的手势交互、更丰富的原生控件、多线程支持下带来更好用户体验的背后，是双倍的研发投入，更长的研发与发版周期

在更好的用户体验与更好的研发体验之间，React 团队选择了全部都要😂

在尝试了 Webview 以及 componentkit 的方案之后，React 团队最后回到了他们最熟悉的领域：Javascript

他们的想法就是：使用 JS 调用原生的 APIs（Scripting native）

JS 应该跑在哪里？

这个想法特别美好，如果成功了既可以直接套用现有的 JS 基建，又可以通过 JS 调用所有原生的能力

紧随其后的第一个问题是：JS 应该跑在哪里？

最直接的想法是主线程（又称 Main thread，是 IOS 与 Android 系统启动应用时开启的第一个线程，负责 UI 渲染与用户输入事件的处理）

不难想象，如果一个应用在主线程同时存在大量 JS 与原生语言的同步调用，最终的结果只会是卡到完全无法响应用户输入

所以我们需要让 JS 运行在一个独立线程中（后文称之为 JS thread）

独立线程之后的问题

将 JS 线程独立出来之后，我们还需要考虑到两个问题：

0. 资源争夺：当两个线程需要同时读写一块内存（一个特定资源，比如当前某个 View 的长宽）的时候，线程锁会导致线程之间的等待，进而导致用户可感知的卡顿
1. 跨语言跨线程通讯开销：在 JS 与原生语言之间通讯会产生固定的开销，随着通讯频率的增加，这块开销也会线性增长

通讯开销这个问题我们留在后面讨论 RN 旧架构的时候再来展开聊，我们先来看看资源争夺这个问题 RN 团队是如何解决的

在正常的多线程编程模型下，资源争夺一直都是让开发者非常头疼的问题，但是 React 的编程模型在特定场景下给出了一个完美的解决方案：

 declarative -> async -> responsive

React 的组件有一个特点，就是他们每一个都是纯函数，并且每个组件都描述了一组元素

在浏览器中，React 的组件最终会被解析为一个个 dom 元素，但实际上，React 通过抽象解开了组件与 dom 之间的耦合关系

说白话就是，React 只负责定义 组件是什么样子的，至于后面组件被解析（响应） 为 div、View、UIView 都无所谓

由于 React 已经帮我们完成了大部分的工作，我们实际上只需要搞定通信的部份，然后把组件渲染成与原生平台相关的 UI 元素就好了

于是，RN 的初版就在 2015 年发布了

题外话：RN 的增量迁移

上文我们说到，RN 是通过在原生系统中开启了一个 JS 线程，然后通过主线程解析 JS 线程传来的组件而渲染出 UI

这么做还有另外一个好处：主线程除了渲染 JS 线程的组件之外，还可以渲染自己原生系统的 UI，因为主线程对 APP 依然拥有绝对的控制权

这意味着 RN 不只能从 0 到 1 构建一个原生 APP，还能够在现有的 APP 上添加 RN 来运行 JS 代码渲染跨端的 RN 组件