React内部的性能优化没有达到极致?
共 2973字,需浏览 6分钟
·
2022-03-23 11:28
大家好,我卡颂。
对于如下这个常见交互步骤:
点击按钮,触发
状态更新
组件
render
视图渲染
你觉得哪些步骤有「性能优化的空间」呢?
答案是:1和2。
对于「步骤1」,如果状态
更新前后没有变化,则可以略过剩下的步骤。这个优化策略被称为eagerState
。
对于「步骤2」,如果组件的子孙节点没有状态变化,可以跳过子孙组件的render
。这个优化策略被称为bailout
。
看起来eagerState
的逻辑很简单,只需要比较「状态更新前后是否有变化」。
然而,实践上却很复杂。
本文通过了解eagerState
的逻辑,回答一个问题:React
的性能优化达到极致了么?
一个奇怪的例子
考虑如下组件:
function App() {
const [num, updateNum] = useState(0);
console.log("App render", num);
return (
<div onClick={() => updateNum(1)}>
<Child />
div>
);
}
function Child() {
console.log("child render");
return <span>childspan>;
}
在线Demo地址[1]
首次渲染,打印:
App render 0
child render
第一次点击div
,打印:
App render 1
child render
第二次点击div
,打印:
App render 1
第三、四......次点击div
,不打印
在「第二次」点击中,打印了App render 1
,没有打印child render
。代表App
的子孙组件没有render
,命中了bailout
。
「第三次及之后」的点击,什么都不打印,代表没有组件render
,命中了eagerState
。
那么问题来了,明明第一、二次点击都是执行updateNum(1)
,显然状态是没有变化的,为什么第二次没有命中eagerState
?
eagerState的触发条件
首先我们需要明白,为什么叫eagerState
(急迫的状态)?
通常,什么时候能获取到最新状态
呢?组件render
的时候。
当组件render
,useState
执行并返回最新状态
。
考虑如下代码:
const [num, updateNum] = useState(0);
useState
执行后返回的num
就是最新状态
。
之所以useState
执行时才能计算出最新状态
,是因为状态
是根据「一到多个更新」计算而来的。
比如,在如下点击事件中触发3个更新:
const onClick = () => {
updateNum(100);
updateNum(num => num + 1);
updateNum(num => num * 2);
}
组件render
时num
的最新状态
应该是多少呢?
首先
num
变为100100 + 1 = 101
101 * 2 = 202
所以,useState
会返回202
作为num的最新状态
。
实际情况会更复杂,更新
拥有自己的优先级
,所以在render
前不能确定「究竟是哪些更新会参与状态的计算」。
所以,在这种情况下组件必须render
,useState
必须执行才能知道num的最新状态
是多少。
那就没法提前将num的最新状态
与num的当前状态
比较,判断「状态是否变化」。
而eagerState
的意义在于,在「某种情况」下,我们可以在组件render
前就提前计算出最新状态
(这就是eagerState
的由来)。
这种情况下组件不需要render
就能比较「状态是否变化」。
那么是什么情况呢?
答案是:当前组件上「不存在更新」的时候。
当不存在更新
时,本次更新就是组件的第一个更新
。在只有一个更新
的情况下是能确定最新状态
的。
所以,eagerState
的前提是:
当前组件不存在更新,那么首次触发状态更新时,就能立刻计算出最新状态
,进而与当前状态
比较。
如果两者一致,则省去了后续render
的过程。
这就是eagerState
的逻辑。但遗憾的是,实际情况还要再复杂一丢丢。
先让我们看一个「看似不相干」的例子。
必要的React源码知识
对于如下组件:
function App() {
const [num, updateNum] = useState(0);
window.updateNum = updateNum;
return <div>{num}div>;
}
在控制台执行如下代码,可以改变视图显示的num
么?
window.updateNum(100)
答案是:可以。
因为App
组件对应fiber
(保存组件相关信息的节点)已经被作为「预设的参数」传递给window.updateNum
了:
// updateNum的实现类似这样
// 其中fiber就是App对应fiber
const updateNum = dispatchSetState.bind(null, fiber, queue);
所以updateNum
执行时是能获取App
对应fiber
的。
然而,一个组件实际有2个fiber
,他们:
一个保存「当前视图」对应的相关信息,被称为
current fiber
一个保存「接下来要变化的视图」对应的相关信息,被称为
wip fiber
updateNum
中被预设的是wip fiber
。
当组件触发更新后,会在组件对应的2个fiber
上都「标记更新」。
当组件render
时,useState
会执行,计算出新的状态
,并把wip fiber
上的「更新标记」清除。
当视图完成渲染后,current fiber
与wip fiber
会交换位置(也就是说本次更新的wip fiber
会变为下次更新的current fiber
)。
回到例子
刚才谈到,eagerState
的前提是:「当前组件不存在更新」。
具体来讲,是组件对应的current fiber
与wip fiber
都不存在更新。
回到我们的例子:
第一次点击div
,打印:
App render 1
child render
current fiber
与wip fiber
同时标记更新。
render
后wip fiber
的「更新标记」清除。
此时current fiber
还存在「更新标记」。
完成渲染后,current fiber
与wip fiber
会交换位置。
变成:wip fiber
存在更新,current fiber
不存在更新。
所以第二次点击div
时,由于wip fiber
存在更新,没有命中eagerState
,于是打印:
App render 1
render
后wip fiber
的「更新标记」清除。
此时两个fiber
上都不存在「更新标记」。所以后续点击div
都会触发eagerState
,组件不会render
。
总结
由于React
内部各个部分间互相影响,导致React
性能优化的结果有时让开发者迷惑。
为什么没有听到多少人抱怨呢?因为性能优化只会反映在指标上,不会影响交互逻辑。
通过本文我们发现,React
性能优化并没有做到极致,由于存在两个fiber
,eagerState
策略并没有达到最理想的状态。
参考资料
[1]在线Demo地址: https://codesandbox.io/s/frosty-cerf-mg64o5?file=/src/App.js:188-200