4、React组件之机能优化

2024年5月16日 216次阅读 来源: keywords

React组件的机能优化

高德纳: “我们应当遗忘疏忽很小的机能优化，能够说97%的状况下，过早的优化是万恶之源，

而我们应当体贴对机能影响最症结的别的3%的代码。”

  • 不要将机能优化的精神糟蹋在对团体机能进步不大的代码上，而对机能有症结影响的部份，

优化并不嫌早。由于，对机能影响最症结的部份，每每触及解决方案中心，决议团体的架构，
未来要转变的时刻牵涉更大。

1. 单个React组件的机能优化

  • React运用Virtual DOM来提拔衬着机能，虽然每一次页面更新都是最组件的从新衬着，

但是并非将之前的衬着内容悉数扬弃重来，借助Virtual DOM，React能够盘算出对DOM
树的起码修正，这就是React默许状况下衬着都很敏捷的窍门；

  • 不过，虽然Virtual DOM能够将每次DOM操纵量削减到最小，但，盘算和比较Virtual DOM依然是一个庞杂的历程；
  • 固然，假如能够在最先盘算Virtual DOM之前就推断衬着的效果不会有变化，那末就能够不举行Virtual DOM盘算和比较，速率就会更快。

2.shouldComponentUpdate的默许完成体式格局

  • 既然能够对组件在最先盘算Virtual DOM之前推断衬着效果不会有变化时，阻挠衬着的举行，
    从而提拔机能，那末我们天然想到运用shouldComponentUpdate(nextProp,nextState)
  • shouldComponentUpdate函数在render函数之前挪用，决议“什么时刻不须要从新衬着”；
  • 即返回一个布尔值，决议更新是不是举行下去，默许返回true，若返回false则中缀更新；
shouldComponentUpdate(nextProp,nextState){

    return (nextProp.completed !== this.props.completed) ||
        (nextProp.text !== this.props.text)
}

  • 个中nextProps为此次更新传入的props，关于这个组件，影响衬着内容的prop只需completed和text，
    只需确保这两个prop没有变化，shouldComponentUpdate就能够返回false阻挠没必要的更新

    但是，上述的比较只是‘浅层比较’，假如范例是基础范例，只需值雷同，那末“浅层比较”
    也会以为两者雷同：

    1. 那，假如prop的范例是庞杂的对象怎么办？
    • 关于庞杂对象，‘浅层比较’的体式格局只看这两个prop是不是是同一个对象的援用，假如不是，哪怕
      对象中的内容完整一样也会以为是差别的两个prop。
    • 那末运用“深层比较”：但对对象的构造是没法预知的，假如递归对每一个字段都举行“深层比较”，
      不光会让代码越发庞杂，也能够会形成机能题目。

  • 所以，要想推断前后的对象范例的prop是雷同的，就必需要保证prop是指向同一个JavaScript对象：

    <Foo styleProp = {{color: "red"}}>

    • 要防止运用上面的传入体式格局，应为每次衬着都邑从新建立{color: “red”}对象，援用地点每次都差别，将致使每次的styleProp都差别。

      const footStyle = {color: "red"};//确保这个初始化只实行一次，不要放在render函数中

<Foo styleProp = {footStyle}>
  • 运用‘单例形式’确保传入的styleProp指向同一个对象

  • 假如是函数呢？

    <Foo onToggle={() => onToggleTodo(item.id)}/>
  • 应当防止运用上面的函数通报形式，由于这里赋值的是一个匿名函数，而且是在赋值的时刻发作的，也就是说
    每次衬着都邑发作一个新的函数，这就是题目所在。

  1. 假如要通报的prop许多呢？

    • 恩~~用React-Redux的话，有对shouldComponentUpdate的默许完成。

3. 对多个React组件的机能优化

  • 当一个React组件被装载、更新和卸载时，组件的一序列性命周期函数会被挪用。不过，这些性命周期函数是针对一个
    特定的React组件函数，在一个运用中，从上而下有许多React组件组合起来，它们之间的衬着历程要越发庞杂。
  • 一样一个组件的衬着历程也要斟酌三个历程：装载阶段、更新阶段、卸载阶段
  • 关于装载阶段，组件无论如何都要完全衬着一次，从这个React组件往下的一切子组件，都要阅历一遍React组件的装载性命
    周期，所以并没有若干优化的事变可做。
  • 关于卸载阶段，只需一个性命周期函数componentWillUnmount,这个函数只是清算componentDidMount增加的事宜处置惩罚监听等扫尾事情，
    所以，也没有什么可优化的空间；

4. React更新阶段的折衷（Reconciliation）历程

  • 在组件更新历程，会构建更新Virtual DOM，并将其与之前的Virtual DOM举行比较，从而找出差别之处，运用起码的DOM操纵举行更新
  • 折衷历程：即React更新中对Virtual DOM找差别的历程，一般对照两个N个节点的树形构造的算法，时候庞杂度是O(n*3),假如直接
    运用默许对照，节点过量的话，须要操纵的数目太多，而React不能够采纳这类算法；
  • React现实采纳的算法时候庞杂度是O(N)(时候庞杂度只是对一个算法最好和最差状况下须要的指令操纵数目级的估计)
  • React的Reconciliation算法并不庞杂，起首搜检两个树形的根节点的范例是不是雷同，依据雷同或许差别有差别的处置惩罚体式格局：

  1. 节点范例差别的状况

    • 假如树形节点的范例不雷同，那就意味着修改很大，直接以为本来的谁人树形构造已没用，能够抛弃，须要从新构建DOM树，
      原有的树形上的React组件便会阅历“卸载”的性命周期；
    • 也就是说，关于Virtual DOM树这是一个“更新”历程，但是却能够激发这个树构造上某些组件的“装载”和“卸载”历程
      如：
      更新前
      <div>
   <Todos />
  </div>

    我们想要更新成如许：

      <span>
      <Todos />
  </span>
>1. 那末在作比较的时刻，一看根节点本来是div，新的是span，范例就不一样了，那末这个算法就烧毁之前的div包含内里的一切子节点，
  从新构建一个span节点和子节点；
  
>2. 很明显由于根节点差别就将一切的子节点从新构建，这很糟蹋，但是为了防止O(N*3)的时候庞杂度，React这能挑选这类比较简单、快速的要领；
  
>3. 所以，作为开发者，我们一定要防止上面的糟蹋的情形涌现

  1. 节点范例雷同的状况

    • 假如两个节点范例雷同时，关于DOM元素，React会保存节点对应的DOM元素，只对其节点的属性和内容做对照，然后只修正更新的部份；
    • 节点范例雷同时，关于React组件范例，React做得是依据新节点的props去更新节点的组件实例，激发组件的更新历程；
    • 在处置惩罚完根节点对照后，React的算法会对根节点的每一个子节点反复一样的操纵

  2. 多个雷同子组件的状况

    • 假如最初组件状况为：
    <ul>
    <TodoItem text = "First" />
    <TodoItem text = "Second" />

</ul>
    • 更新后为：
    <ul>
    <TodoItem text = "First" />
    <TodoItem text = "Second" />
    <TodoItem text = "Third" />
</ul>
    • 那末React会建立一个新的TodoItem组件实例，而前两个则举行一般的更新历程但是，假如更新后为：
    <ul>
    <TodoItem text = "Zero" />
    <TodoItem text = "First" />
    <TodoItem text = "Second" />

</ul>
    • （这将暴露一个题目）抱负处置惩罚体式格局是，建立一个新的TodoItem组件实例放在第一位，后两个进入天然更新历程
      但是要让react根据这类体式格局，就必需找两个子组件的差别之处，而现有盘算两个序列差别的算法时候是O(N*2),显但是
      不适合对机能请求很高的场景，所以React挑选了一个看起来很傻的方法，即挨个比较每一个子组件；
    • React起首以为把text为First的组件的text改成Zero,Second的改成First，末了建立一个text为Second的组件，如许便会破原有的两个组件完成一个更新历程，并建立一个text为Second的新组件
    • 这显然是一个糟蹋，React也意到，并供应了方战胜，不过须要开发人员供应一点协助，这就是key
  3. Key的运用

  • key属性能够明白的通知React每一个组件的唯一标识

    • 假如最初组件状况为：
    <ul>
    <TodoItem key={1} text = "First" />
    <TodoItem key={2} text = "Second" />

</ul>

  • 更新后为：

    <ul>
    <TodoItem key={0} text = "Zero" />
    <TodoItem key={1} text = "First" />
    <TodoItem key={2} text = "Second" />
</ul>

    由于有唯一标识key,React能够依据key值，晓得如今的第二和第三个组件就是之前的第一和第二个，便用本来的props启动更新历程，
    如许shouldComponentUpdate就会发作作用，防止无谓的更新；

  • 注重：由于作为组件的唯一标识，所以key必需唯一，且不可变
  • 下面的代码是毛病的例子：
<ul>
    todos.map((item,index) => {
            <TodoItem
                key={index}
                text={item.text}
            />
        })
</ul>

运用数组下标作为key值，看起来唯一，但不稳固，由于跟着todos数组值的差别，一样一个组件实例在差别的更新历程当中数组的下标完整能够差别，
把下标当作能够就会让React乱套，记着key不仅要唯一还要确保稳固不可变

须要注重：虽然key是一个prop，但是接收key的组件不能读取key的值，由于key和ref是React保存的两个特别prop，并没有预期让组将直接接见。

    原文作者：keywords
    原文地址: https://segmentfault.com/a/1190000013483603
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞