React17新特性：启发式更新算法

左手的ㄟ右手 2022-11-27 06:57 191阅读 0赞

北京时间8月11日凌晨，`React团队`发布了`React17`第一个`RC版本`。该版本的最大特性是“无新特性”。

那么，从`v16`到`v17`这一年多时间`React团队`究竟在做什么？

遥想从`v15`到`v16`，`React团队`花了两年时间将源码架构中的`Stack Reconciler`重构为`Fiber Reconciler`，事情一定没有这么简单。

事实上，这次版本更迭确实有“新特性” —— 替换了内部使用的`启发式更新算法`。

只不过这个特性对开发者是无感知的。

本文接下来将讲述如下内容：

*  起源：为什么会出现`启发式更新算法`？
 *  现状：`React16`的`启发式更新算法`及他的不足
 *  未来：`React17`的`启发式更新算法`

# 为什么会出现启发式更新算法 #

`框架`的运行性能是`框架设计者`在设计框架时需要重点关注的点。

`Vue`使用`模版语法`，可以在编译时对确定的模版作出优化。

而`React`纯`JS`写法太过灵活，使他在`编译时优化`方面先天不足。

所以，`React`的优化主要在`运行时`。

## React15的痛点 ##

在`运行时优化`方面，`React`一直在努力。

比如，`React15`实现了`batchedUpdates`（批量更新）。

即同一事件回调函数上下文中的多次`setState`只会触发一次`更新`。

但是，如果单次`更新`就很耗时，页面还是会卡顿（这在一个维护时间很长的大应用中是很常见的）。

这是因为`React15`的更新流程是`同步`执行的，一旦开始更新直到页面渲染前都不能中断。

为了解决`同步更新`长时间占用线程导致页面卡顿的问题，也为了探索`运行时优化`的更多可能，`React`开始重构并一直持续至今。

重构的目标是实现`Concurrent Mode`（并发模式）。

## Concurrent Mode ##

`Concurrent Mode`的目的是**实现一套可中断/恢复的更新机制**。

其由两部分组成：

*  一套`协程架构`
 *  基于`协程架构`的`启发式更新算法`

其中，`协程架构`就是`React16`中实现的`Fiber Reconciler`。

我们可以将`Fiber Reconciler`理解为`React`自己实现的`Generator`。

> `Fiber Reconciler`从理念到源码的详细介绍：https://react.iamkasong.com/process/fiber-mental.html

`协程架构`使`更新`可以在需要的时机被中断，这样浏览器就有时间完成`样式布局`与`样式绘制`，减少卡顿（掉帧）的出现。

当浏览器进入下一次`事件循环`，`协程架构`可以`恢复中断`或者抛弃之前的`更新`，重新开始新的更新流程。

`启发式更新算法`就是控制`协程架构`工作方式的算法。

# React16的启发式更新算法 #

`启发式更新算法`的`启发式`指什么呢？

`启发式`指不通过`显式的指派`，而是通过`优先级`调度更新。

其中`优先级`来源于`人机交互的研究成果`。

比如：

`人机交互的研究成果`表明：

*  当用户在输入框输入内容时，希望输入的内容能实时响应在输入框
 *  当异步请求数据后，即使等待一会儿再显示内容，用户也是可以接受的

基于此，在`React16`中

输入框输入内容触发的`更新`优先级 > 请求数据返回后触发`更新`优先级

## 算法实现 ##

在`React16、17`中，在组件内执行`this.setState`后会在该组件对应的`fiber节点`内产生一种链表数据结构`update`。

其中，`update.expirationTimes`为类似`时间戳`的字段，表示`优先级`。

`expirationTimes`从字面意义理解为`过期时间`。

该值离当前时间越接近，该`update` `优先级`越高。

当`update.expirationTimes`超过当前时间，则代表该`update`过期，`优先级`变为最高（即`同步`）。

一棵`fiber树`的多个`fiber节点`可能存在多个`update`。

每次`Fiber Reconciler`调度`更新`时，会在所有`fiber节点`的所有`update.expirationTimes`中选择一个`expirationTimes`（一般选择最大的），作为本次`更新`的`优先级`。

并从`根fiber节点`开始向下构建新的`fiber树`。

构建过程中如果某个`fiber节点`包含`update`，且

update.expirationTimes >= expirationTimes

则该`update`对应的`state`变化会体现在本次`更新`中。

可以理解为：每次`更新`，都会选定一个`优先级`（expirationTimes），最终页面会渲染为该`优先级`对应`update`的快照。

举个例子，我们有如图所示`fiber树`，当前还没有`更新`产生，所以没有`构建中`的`fiber树`。

![format_png][]

当在`C`创建一个`低优先级update`，调度`更新`，本次`更新`选择的优先级为`低优先级`。

开始构建新的`fiber树`（图右侧）。

![format_png 1][]

此时，我们在`D`创建一个`高优先级update`。

这会中断进行中的`低优先级更新`，重新开始以`高优先级`生成一棵`fiber树`。

由于之前的`更新`被中断，还没有任何渲染操作，此时`视图中`（左图）还没有任何变化。

![format_png 2][]

本次`更新`选定的优先级为`高优先级`，`C`的`update`（低优先级）会被跳过。

更新完成后新的`fiber树`会被渲染到`视图`中。

![format_png 3][]

由于`C`被跳过，所以不会在`视图`（左图）中体现。

接下来我们在`E`触发一次`高优先级update`。

`C`虽然包含`低优先级update`，但随着时间的推移，他的`expirationTimes`已经过期，变为`高优先级`。

![format_png 4][]

所以本次更新会有`C` `E`两个`fiber节点`产生变化。

最终完成更新后，视图如下：

![format_png 5][]

> 关于更新`优先级`的详细解释：https://react.iamkasong.com/state/priority.html

## 算法缺陷 ##

如果只考虑中断/继续这样的`CPU操作`，以`expirationTimes`大小作为衡量`优先级`依据的模型可以很好工作。

但是`expirationTimes模型`不能满足`IO操作`（Suspense）。

在该模型下，`高优先级IO任务`（Suspense）会中断`低优先级CPU任务`。

还记得么，每次`更新`，都是以某一`优先级`作为整棵树的`优先级`更新标准，而不仅仅是某一组件，即使`更新`的源头（update）确实是某个组件产生的。

`expirationTimes模型`只能区分是否`>=expirationTimes`这种情况。

为了拓展`Concurrent Mode`能力边界，需要一种更细粒度的`启发式优先级更新算法`。

# React17启发式更新算法 #

最理想的模型是：可以指定任意几个`优先级`，`更新`会以这些`优先级`对应`update`生成页面快照。

但是现有架构下，该方案实现上有瓶颈。

妥协之下，`React17`的解决方案是：指定一个连续的`优先级区间`，每次`更新`都会以`区间`内包含的`优先级`生成对应页面快照。

这种`优先级区间`模型被称为`lanes`（车道模型）。

具体做法是：使用一个31位的二进制代表31种可能性。

*  其中每个`bit`被称为一个`lane`（车道），代表`优先级`
 *  某几个`lane`组成的二进制数被称为一个`lanes`，代表一批`优先级`

可以从源码中看到，从蓝线一路划下去，每个`bit`都对应一个`lane`或`lanes`。

![format_png 6][]

当`update`产生，会根据`React16`同样的`启发式`方式，获得如下`优先级`的一种：

export const SyncLanePriority: LanePriority = 17;
    export const SyncBatchedLanePriority: LanePriority = 16;
    export const InputDiscreteLanePriority: LanePriority = 14;
    export const InputContinuousLanePriority: LanePriority = 12;
    export const DefaultLanePriority: LanePriority = 10;
    export const TransitionShortLanePriority: LanePriority = 8;
    export const TransitionLongLanePriority: LanePriority = 6;

其中值越高，优先级越大。

比如：

*  `点击事件回调`中触发`this.setState`产生的`update`会获得`InputDiscreteLanePriority`。
 *  同步的`update`会获得`SyncLanePriority`。

接下来，`update`会以`priority`为线索寻找没被占用的`lane`。

如果当前`fiber树`已经存在`更新`且`更新`的`lanes`包含了该`lane`，则`update`需要寻找其他`lane`。

比如，`InputDiscreteLanePriority`对应的`lanes`为`InputDiscreteLanes`。

// 第4、5位为1
    const InputDiscreteLanes: Lanes = 0b0000000000000000000000000011000;

该`lanes`包含第4、5位2个`bit位`。

如果其中

// 第五位为1
    0b0000000000000000000000000010000

第五位的`lane`已经被占用，则该`update`可以尝试占有后一个，即

// 第四位为1
    0b0000000000000000000000000001000

如果`InputDiscreteLanes`的两个`lane`都被占用，则该`update`的优先级会下降到`InputContinuousLanePriority`并继续寻找空余的`lane`。

这个过程就像：购物中心每一层（不同优先级）都有一个露天停车场（lanes），停车场有多个车位（lane）。

我们先开车到顶楼找车位（lane），如果没有车位就下一楼继续找。

直到找到空余车位。

由于`lanes`可以包含多个`lane`，可以很方便的区分`IO操作`（Suspense）与`CPU操作`。

当构建`fiber树`进入构建`Suspense子树`时，会将`Suspense`的`lane`插入本次`更新`选定的`lanes`中。

当构建离开`Suspense子树`时，会将`Suspense lane`从本次`更新`的`lanes`中移除。

# 总结 #

`React16`的`expirationTimes模型`只能区分是否`>=expirationTimes`决定节点是否更新。

`React17`的`lanes模型`可以选定一个`更新区间`，并且动态的向`区间`中增减`优先级`，可以处理更细粒度的更新。

[format_png]: /images/20221124/199b3bc88e6042dc82bbf8222fe4eef3.png
[format_png 1]: /images/20221124/957ff9a465ae4f708d2162ec2456e56f.png
[format_png 2]: /images/20221124/d047b0067c3b48879e24988c69068e8c.png
[format_png 3]: /images/20221124/70eae55652e64848ab0efe9bd6047af0.png
[format_png 4]: /images/20221124/098abb372e344654903799c2dc3133e4.png
[format_png 5]: /images/20221124/4b9ead54e1d241da8e40f9212b376c82.png
[format_png 6]: /images/20221124/1a684ee3eb304a7cb717d589002f3594.png