从Context源码实现谈React性能优化_编程技术

学完这篇文章，你会收获：

了解Context的实现原理
源码层面掌握React组件的render时机，从而写出高性能的React组件
源码层面了解shouldComponentUpdate、React.memo、PureComponent等性能优化手段的实现

我会尽量将文章写的通俗易懂。但是，要完全理解文章内容，需要你掌握这些前置知识：

Fiber架构的大体工作流程
优先级与更新在React源码中的意义

组件render的时机

Context的实现与组件的render息息相关。在讲解其实现前，我们先来了解render的时机。

换句话说，组件在什么时候render?

这个问题的答案，已经在React组件到底什么时候render啊聊过。在这里再概括下：

在React中，每当触发更新(比如调用this.setState、useState)，会为组件创建对应的fiber节点。

fiber节点互相链接形成一棵Fiber树。

有2种方式创建fiber节点：

bailout，即复用前一次更新该组件对应的fiber节点作为本次更新的fiber节点。

render，经过diff算法后生成一个新fiber节点。组件的render(比如ClassComponent的render方法调用、FunctionComponent的执行)就发生在这一步。

经常有同学问：React每次更新都会重新生成一棵Fiber树，性能不会差么?

React性能确实不算很棒。但如你所见，Fiber树生成过程中并不是所有组件都会render，有些满足优化条件的组件会走bailout逻辑。

比如，对于如下Demo：

function Son() {

  console.log('child render!');

  return <div>Son</div>;

}

function Parent(props) {

  const [count, setCount] = React.useState(0);

  return (

    <div onClick={() => {setCount(count + 1)}}>

      count:{count}

      {props.children}

    </div>

  );

}

function App() {

  return (

    <Parent>

      <Son/>

    </Parent>

  );

}

const rootEl = document.querySelector("#root");

ReactDOM.render(<App/>, rootEl);

在线Demo地址[2]

点击Parent组件的div子组件，触发更新，但是child render!并不会打印。

这是因为Son组件会进入bailout逻辑。

bailout的条件

要进入bailout逻辑，需同时满足4个条件：

1.oldProps === newProps

即本次更新的props全等于上次更新的props。

注意这里是全等比较。

我们知道组件render会返回JSX，JSX是React.createElement的语法糖。

所以render的返回结果实际上是React.createElement的执行结果，即一个包含props属性的对象。

即使本次更新与上次更新props中每一项参数都没有变化，但是本次更新是React.createElement的执行结果，是一个全新的props引用，所以oldProps !== newProps。

2.context value没有变化

我们知道在当前React版本中，同时存在新老两种context，这里指老版本context。

3.workInProgress.type === current.type

更新前后fiber.type不变，比如div没变为p。

4.!includesSomeLane(renderLanes, updateLanes) ?

当前fiber上是否存在更新，如果存在那么更新的优先级是否和本次整棵Fiber树调度的优先级一致?

如果一致代表该组件上存在更新，需要走render逻辑。

bailout的优化还不止如此。如果一棵fiber子树所有节点都没有更新，即使所有子孙fiber都走bailout逻辑，还是有遍历的成本。

所以，在bailout中，会检查该fiber的所有子孙fiber是否满足条件4(该检查时间复杂度O(1))。

如果所有子孙fiber本次都没有更新需要执行，则bailout会直接返回null。整棵子树都被跳过。

不会bailout也不会render，就像不存在一样。对应的DOM不会产生任何变化。

老Context API的实现现

在我们大体了解了render的时机。有了这个概念，就能理解ContextAPI是如何实现的，以及为什么被重构。

我们先看被废弃的老ContextAPI的实现。

Fiber树的生成过程是通过遍历实现的可中断递归，所以分为递和归2个阶段。

Context对应数据会保存在栈中。

在递阶段，Context不断入栈。所以Concumer可以通过Context栈向上找到对应的context value。

在归阶段，Context不断出栈。

那么老ContextAPI为什么被废弃呢?因为他没法和shouldComponentUpdate或Memo等性能优化手段配合。

shouldComponentUpdate的实现

要探究更深层的原因，我们需要了解shouldComponentUpdate的原理，后文简称其为SCU。

使用SCU是为了减少不必要的render，换句话说：让本该render的组件走bailout逻辑。

刚才我们介绍了bailout需要满足的条件。那么SCU是作用于这4个条件的哪个呢?

显然是第一条：oldProps === newProps

当使用shouldComponentUpdate，这个组件bailout的条件会产生变化：

-- oldProps === newProps

++ SCU === false

同理，使用PureComponenet和React.memo时，bailout的条件也会产生变化：

-- oldProps === newProps

++ 浅比较oldProps与newsProps相等

回到老ContextAPI。

当这些性能优化手段：

使组件命中bailout逻辑

同时如果组件的子树都满足bailout的条件4

那么该fiber子树不会再继续遍历生成。

换言之，不会再经历Context的入栈、出栈。

这种情况下，即使context value变化，子孙组件也没法检测到。

新Context API的实现

知道老ContextAPI的缺陷，我们再来看新ContextAPI是如何实现的。

当通过：

ctx = React.createContext();

创建context实例后，需要使用Provider提供value，使用Consumer或useContext订阅value。

如：

ctx = React.createContext();

const NumProvider = ({children}) => {

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

  return (

    <Ctx.Provider value={num}>

      <button onClick={() => add(num + 1)}>add</button>

      {children}

    </Ctx.Provider>

  )

}