大家好，我卡颂。

对于如下这个常见交互步骤：

  1. 点击按钮，触发状态更新
  2. 组件render
  3. 视图渲染

你感觉哪些步骤有性能优化的空间呢？

答案是：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>;}
在线Demo地址

首次渲染,打印：

App render 0child render

第一次点击div,打印：

App render 1child 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变为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>;}

在控制台执行如下代码，能够扭转视图显示的num么？

window.updateNum(100)

答案是：能够。

因为App组件对应fiber（保留组件相干信息的节点）曾经被作为预设的参数传递给window.updateNum了：

// updateNum的实现相似这样// 其中fiber就是App对应fiberconst 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 1child 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策略并没有达到最现实的状态。