文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

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

2024-12-03 15:02

关注

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

  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 
    Son
  4.  
  5.  
  6. function Parent(props) { 
  7.   const [count, setCount] = React.useState(0); 
  8.  
  9.   return ( 
  10.      {setCount(count + 1)}}> 
  11.       count:{count
  12.       {props.children} 
  13.     
 
  •   ); 
  •  
  •  
  • function App() { 
  •   return ( 
  •      
  •        
  •      
  •   ); 
  •  
  • const rootEl = document.querySelector("#root"); 
  • ReactDOM.render(, 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.      
    8.        add(num + 1)}>add 
    9.       {children} 
    10.      
    11.   ) 

    使用:

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

      {num}

       

      当遍历组件生成对应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,这棵子树没法满足:

    所以即使遍历中途有组件进入bailout逻辑,也不会返回null,即不会无视这棵子树的遍历。

    最终遍历进行到Child,由于其不满足条件4,会进入render逻辑,调用组件对应函数。

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

      {num}

       

     在函数调用中会调用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

     

    来源:魔术师卡颂内容投诉

    免责声明:

    ① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

    ② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

    软考中级精品资料免费领

    • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

      难度     813人已做
      查看
    • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

      难度     354人已做
      查看
    • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

      难度     318人已做
      查看
    • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

      难度     435人已做
      查看
    • 2024年上半年系统架构设计师考试综合知识真题

      难度     224人已做
      查看

    相关文章

    发现更多好内容

    猜你喜欢

    AI推送时光机
    位置:首页-资讯-后端开发
    咦!没有更多了?去看看其它编程学习网 内容吧
    首页课程
    资料下载
    问答资讯