大家好，我卡颂。
对于如下这个常见交互步骤：
- 点击按钮，触发状态更新。
- 组件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>child</span>;
}- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
在线Demo地址[1]。
首次渲染,打印：
App render 0
child render - 1.
- 2.
第一次点击div,打印：
App render 1
child render - 1.
- 2.
第二次点击div,打印：
App render 1- 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);- 1.
useState执行后返回的num就是最新状态。
之所以useState执行时才能计算出最新状态，是因为状态是根据「一到多个更新」计算而来的。
比如，在如下点击事件中触发3个更新：
const onClick = () => {
updateNum(100);
updateNum(num => num + 1);
updateNum(num => num * 2);
}- 1.
- 2.
- 3.
- 4.
- 5.
组件render时num的最新状态应该是多少呢?
- 首先num变为100。
- 100 + 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>;
}- 1.
- 2.
- 3.
- 4.
- 5.
在控制台执行如下代码，可以改变视图显示的num么?
window.updateNum(100)- 1.
答案是：可以。
因为App组件对应fiber(保存组件相关信息的节点)已经被作为「预设的参数」传递给window.updateNum了：
// updateNum的实现类似这样
// 其中fiber就是App对应fiber
const updateNum = dispatchSetState.bind(null, fiber, queue);- 1.
- 2.
- 3.
所以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 - 1.
- 2.
current fiber与wip fiber同时标记更新。
render后wip fiber的「更新标记」清除。
此时current fiber还存在「更新标记」。
完成渲染后，current fiber与wip fiber会交换位置。
变成：wip fiber存在更新，current fiber不存在更新。
所以第二次点击div时，由于wip fiber存在更新，没有命中eagerState，于是打印：
App render 1- 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。