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

开发 前端
这篇文章主要介绍Context的实现原理,源码层面掌握React组件的render时机,从而写出高性能的React组件,源码层面了解shouldComponentUpdate、React.memo、PureComponent等性能优化手段的实现。

[[358779]]

 学完这篇文章,你会收获:

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

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

  1. Fiber架构的大体工作流程
  2. 优先级与更新在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:

  1. function Son() { 
  2.   console.log('child render!'); 
  3.   return <div>Son</div>; 
  4.  
  5.  
  6. function Parent(props) { 
  7.   const [count, setCount] = React.useState(0); 
  8.  
  9.   return ( 
  10.     <div onClick={() => {setCount(count + 1)}}> 
  11.       count:{count
  12.       {props.children} 
  13.     </div> 
  14.   ); 
  15.  
  16.  
  17. function App() { 
  18.   return ( 
  19.     <Parent> 
  20.       <Son/> 
  21.     </Parent> 
  22.   ); 
  23.  
  24. const rootEl = document.querySelector("#root"); 
  25. 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是如何实现的。

当通过:

  1. ctx = React.createContext(); 

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

如:

  1. ctx = React.createContext(); 
  2.  
  3. const NumProvider = ({children}) => { 
  4.   const [num, add] = useState(0); 
  5.  
  6.   return ( 
  7.     <Ctx.Provider value={num}> 
  8.       <button onClick={() => add(num + 1)}>add</button> 
  9.       {children} 
  10.     </Ctx.Provider> 
  11.   ) 

使用:

  1. const Child = () => { 
  2.   const {num} = useContext(Ctx); 
  3.   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逻辑,调用组件对应函数。

  1. const Child = () => { 
  2.   const {num} = useContext(Ctx); 
  3.   return <p>{num}</p> 

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

总结

React性能一大关键在于:减少不必要的render。

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

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

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

极端情况下,甚至某些子树会被跳过遍历(bailout返回null)。

参考资料

[1]React技术揭秘: http://react.iamkasong.com/

[2]在线Demo地址: https://codesandbox.io/s/quirky-chaplygin-5bx67?file=/src/App.js

 

责任编辑:姜华 来源: 魔术师卡颂
相关推荐

2021-05-27 13:37:24

开发技能React

2021-08-27 14:26:06

开发技能React

2019-02-25 07:07:38

技巧React 优化

2016-12-19 10:00:00

React性能优化

2022-08-03 09:11:31

React性能优化

2023-11-01 17:57:56

React应用程序性能

2017-09-27 18:21:36

报表性能集算器

2023-11-01 11:59:13

2020-06-22 07:30:00

React开发工具

2009-06-29 15:39:53

Servlet和JSPServlet引擎

2015-09-16 10:13:16

游戏性能

2023-07-03 07:51:47

2019-03-14 15:38:19

ReactJavascript前端

2020-01-06 11:22:06

TCPLinux内核

2021-11-23 09:45:26

架构系统技术

2023-06-16 09:08:39

ReactContextRFC

2020-01-13 10:45:35

JavaScript解析前端

2019-09-18 08:53:55

2023-11-01 11:51:08

Linux性能优化

2022-03-11 10:23:02

React性能优化
点赞
收藏

51CTO技术栈公众号