likes
comments
collection
share

React内部的性能优化没有达到极致?

作者站长头像
站长
· 阅读数 27

大家好,我卡颂。

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

  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 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的时候。

当组件renderuseState执行并返回最新状态

考虑如下代码:

const [num, updateNum] = useState(0);

useState执行后返回的num就是最新状态

之所以useState执行时才能计算出最新状态,是因为状态是根据一到多个更新计算而来的。

比如,在如下点击事件中触发3个更新:

const onClick = () => {
  updateNum(100);
  updateNum(num => num + 1);
  updateNum(num => num * 2);
}

组件rendernum最新状态应该是多少呢?

  • 首先num变为100
  • 100 + 1 = 101
  • 101 * 2 = 202

所以,useState会返回202作为num的最新状态

实际情况会更复杂,更新拥有自己的优先级,所以在render前不能确定究竟是哪些更新会参与状态的计算

所以,在这种情况下组件必须renderuseState必须执行才能知道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 fiberwip fiber会交换位置(也就是说本次更新的wip fiber会变为下次更新的current fiber)。

回到例子

刚才谈到,eagerState的前提是:当前组件不存在更新

具体来讲,是组件对应的current fiberwip fiber都不存在更新。

回到我们的例子:

第一次点击div,打印:

App render 1
child render 

current fiberwip fiber同时标记更新。

renderwip fiber更新标记清除。

此时current fiber还存在更新标记

完成渲染后,current fiberwip fiber会交换位置。

变成:wip fiber存在更新,current fiber不存在更新。

所以第二次点击div时,由于wip fiber存在更新,没有命中eagerState,于是打印:

App render 1

renderwip fiber更新标记清除。

此时两个fiber上都不存在更新标记。所以后续点击div都会触发eagerState,组件不会render

总结

由于React内部各个部分间互相影响,导致React性能优化的结果有时让开发者迷惑。

为什么没有听到多少人抱怨呢?因为性能优化只会反映在指标上,不会影响交互逻辑。

通过本文我们发现,React性能优化并没有做到极致,由于存在两个fibereagerState策略并没有达到最理想的状态。