北京时间8月11日凌晨,React团队
发布了React17
第一个RC版本
。该版本的最大特性是“无新特性”。
那么,从v16
到v17
这一年多时间React团队
究竟在做什么?
遥想从v15
到v16
,React团队
花了两年时间将源码架构中的Stack Reconciler
重构为Fiber Reconciler
,事情一定没有这么简单。
事实上,这次版本更迭确实有“新特性” —— 替换了内部使用的启发式更新算法
。
只不过这个特性对开发者是无感知的。
本文接下来将讲述如下内容:
起源:为什么会出现启发式更新算法
?
现状:React16
的启发式更新算法
及他的不足
未来:React17
的启发式更新算法
框架
的运行性能是框架设计者
在设计框架时需要重点关注的点。
Vue
使用模版语法
,可以在编译时对确定的模版作出优化。
而React
纯JS
写法太过灵活,使他在编译时优化
方面先天不足。
所以,React
的优化主要在运行时
。
在运行时优化
方面,React
一直在努力。
比如,React15
实现了batchedUpdates
(批量更新)。
即同一事件回调函数上下文中的多次setState
只会触发一次更新
。
但是,如果单次更新
就很耗时,页面还是会卡顿(这在一个维护时间很长的大应用中是很常见的)。
这是因为React15
的更新流程是同步
执行的,一旦开始更新直到页面渲染前都不能中断。
为了解决同步更新
长时间占用线程导致页面卡顿的问题,也为了探索运行时优化
的更多可能,React
开始重构并一直持续至今。
重构的目标是实现Concurrent Mode
(并发模式)。
Concurrent Mode
的目的是实现一套可中断/恢复的更新机制。
其由两部分组成:
一套协程架构
基于协程架构
的启发式更新算法
其中,协程架构
就是React16
中实现的Fiber Reconciler
。
我们可以将Fiber Reconciler
理解为React
自己实现的Generator
。
Fiber Reconciler
从理念到源码的详细介绍:https://react.iamkasong.com/process/fiber-mental.html
协程架构
使更新
可以在需要的时机被中断,这样浏览器就有时间完成样式布局
与样式绘制
,减少卡顿(掉帧)的出现。
当浏览器进入下一次事件循环
,协程架构
可以恢复中断
或者抛弃之前的更新
,重新开始新的更新流程。
启发式更新算法
就是控制协程架构
工作方式的算法。
启发式更新算法
的启发式
指什么呢?
启发式
指不通过显式的指派
,而是通过优先级
调度更新。
其中优先级
来源于人机交互的研究成果
。
比如:
人机交互的研究成果
表明:
当用户在输入框输入内容时,希望输入的内容能实时响应在输入框
当异步请求数据后,即使等待一会儿再显示内容,用户也是可以接受的
基于此,在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树
。
当在C
创建一个低优先级update
,调度更新
,本次更新
选择的优先级为低优先级
。
开始构建新的fiber树
(图右侧)。
此时,我们在D
创建一个高优先级update
。
这会中断进行中的低优先级更新
,重新开始以高优先级
生成一棵fiber树
。
由于之前的更新
被中断,还没有任何渲染操作,此时视图中
(左图)还没有任何变化。
本次更新
选定的优先级为高优先级
,C
的update
(低优先级)会被跳过。
更新完成后新的fiber树
会被渲染到视图
中。
由于C
被跳过,所以不会在视图
(左图)中体现。
接下来我们在E
触发一次高优先级update
。
C
虽然包含低优先级update
,但随着时间的推移,他的expirationTimes
已经过期,变为高优先级
。
所以本次更新会有C
E
两个fiber节点
产生变化。
最终完成更新后,视图如下:
关于更新
优先级
的详细解释:https://react.iamkasong.com/state/priority.html
如果只考虑中断/继续这样的CPU操作
,以expirationTimes
大小作为衡量优先级
依据的模型可以很好工作。
但是expirationTimes模型
不能满足IO操作
(Suspense)。
在该模型下,高优先级IO任务
(Suspense)会中断低优先级CPU任务
。
还记得么,每次更新
,都是以某一优先级
作为整棵树的优先级
更新标准,而不仅仅是某一组件,即使更新
的源头(update)确实是某个组件产生的。
expirationTimes模型
只能区分是否>=expirationTimes
这种情况。
为了拓展Concurrent Mode
能力边界,需要一种更细粒度的启发式优先级更新算法
。
最理想的模型是:可以指定任意几个优先级
,更新
会以这些优先级
对应update
生成页面快照。
但是现有架构下,该方案实现上有瓶颈。
妥协之下,React17
的解决方案是:指定一个连续的优先级区间
,每次更新
都会以区间
内包含的优先级
生成对应页面快照。
这种优先级区间
模型被称为lanes
(车道模型)。
具体做法是:使用一个31位的二进制代表31种可能性。
其中每个bit
被称为一个lane
(车道),代表优先级
某几个lane
组成的二进制数被称为一个lanes
,代表一批优先级
可以从源码中看到,从蓝线一路划下去,每个bit
都对应一个lane
或lanes
。
当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模型
可以选定一个更新区间
,并且动态的向区间
中增减优先级
,可以处理更细粒度的更新。
联系客服