从Context源码实现谈React性能优化

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

1. 了解Context的实现原理

2. 源码层面掌握React组件的render时机，从而写出高性能的React组件

3. 源码层面了解shouldComponentUpdate、React.memo、PureComponent等性能优化手段的实现

我会尽可能将文章写的通俗易懂。可是，要彻底理解文章内容，须要你掌握这些前置知识：

1. Fiber架构的大致工做流程

2. 优先级与更新在React源码中的意义

若是你还不具有前置知识，能够先阅读React技术揭秘。

组件render的时机

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

换句话说，组件在何时render？

这个问题的答案，已经在React组件到底何时render啊 聊过。在这里再归纳下：

在React中，每当触发更新（好比调用this.setState、useState），会为组件建立对应的fiber节点。

fiber节点互相连接造成一棵Fiber树。

有2种方式建立fiber节点：

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

2. 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地址

点击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>
  )
}
复制代码

使用：

const Child = () => {
  const {num} = useContext(Ctx);
  return <p>{num}</p>
}
复制代码

当遍历组件生成对应fiber时，遍历到Ctx.Provider组件，Ctx.Provider内部会判断context value是否变化。

若是context value变化，Ctx.Provider内部会执行一次向下深度优先遍历子树的操做，寻找与该Provider配套的Consumer。

在上文的例子中会最终找到useContext(Ctx)的Child组件对应的fiber，并为该fiber触发一次更新。

注意这里的实现很是巧妙：

通常更新是由组件调用触发更新的方法产生。好比上文的NumProvider组件，点击button调用add会触发一次更新。

触发更新的本质是为了让组件建立对应fiber时不知足bailout条件4：

!includesSomeLane(renderLanes, updateLanes) ？

从而进入render逻辑。

在这里，Ctx.Provider中context value变化，Ctx.Provider向下找到消费context value的组件Child，为其fiber触发一次更新。

则Child对应fiber就不知足条件4。

这就解决了老ContextAPI的问题：

因为Child对应fiber不知足条件4，因此从Ctx.Provider到Child，这棵子树无法知足：

子树中全部子孙节点都知足条件4

因此即便遍历中途有组件进入bailout逻辑，也不会返回null，即不会无视这棵子树的遍历。

最终遍历进行到Child，因为其不知足条件4，会进入render逻辑，调用组件对应函数。

const Child = () => {
  const {num} = useContext(Ctx);
  return <p>{num}</p>
}
复制代码

在函数调用中会调用useContext从Context栈中找到对应更新后的context value并返回。

总结

React性能一大关键在于：减小没必要要的render。

从上文咱们看到，本质就是让组件知足4个条件，从而进入bailout逻辑。

而ContextAPI本质是让Consumer组件不知足条件4。

咱们也知道了，React虽然每次都会遍历整棵树，但会有bailout的优化逻辑，不是全部组件都会render。

极端状况下，甚至某些子树会被跳过遍历（bailout返回null）。