React 컴포넌트의 성능 최적화에 대한 자세한 설명

이 글은 주로 React 컴포넌트의 성능 최적화에 대해 소개하고 있습니다.

Gartner: "우리는 작은 성능 최적화를 무시하는 것을 잊어야 합니다. 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 함수는 "다시 렌더링할 필요가 없는 시기"를 결정하기 위해 렌더링 함수 전에 호출됩니다.

업데이트가 계속될지 여부를 결정하기 위해 부울 값을 반환합니다. . 기본적으로 true를 반환합니다. false를 반환하면 업데이트가 중단됩니다.

shouldComponentUpdate(nextProp,nextState){
  return (nextProp.completed !== this.props.completed) ||
    (nextProp.text !== this.props.text)
}

여기서 nextProps는 이 업데이트에 전달된 소품입니다. 이 두 prop이 변경되지 않은 한, shouldComponentUpdate는 이를 차단하기 위해 false를 반환할 수 있습니다. 업데이트

그러나 위의 비교는 단지 '얕은 비교'일 뿐입니다. 값이 동일한 한 기본 유형이므로 "얕은 비교"

도 두 가지를 동일한 것으로 간주합니다.

그렇다면 prop이 다음과 같은 경우 어떻게 해야 합니까? 유형은 복잡한 객체입니까?

복잡한 객체의 경우 '얕은 비교' 방법은 두 prop이 동일한 객체에 대한 참조인지 여부만 확인합니다. 그렇지 않으면 객체의 내용이 정확히 동일하더라도 두 개의 다른 prop으로 간주됩니다. 그런 다음 "심층 비교"를 사용합니다. 그러나 개체의 구조는 예측할 수 없습니다. 각 필드에 대해 "심층 비교"를 반복적으로 수행하면 코드가 더 복잡해질 뿐만 아니라 성능 문제가 발생할 수도 있습니다.

따라서 개체 유형 전후의 props가 동일한지 확인하려면 props가 동일한 JavaScript 개체를 가리키는지 확인해야 합니다.

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

위의 사용을 피하려면 들어오는 메서드를 사용하려면 렌더링이 발생할 때마다 {color: "red"} 객체가 다시 생성되고 참조 주소가 매번 달라지므로 styleProp이 매번 달라집니다.

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

'싱글턴 모드'를 사용하여 전달된 styleProp이 동일한 객체를 가리키는지 확인하세요

함수라면 어떨까요?

<Foo onToggle={() => onToggleTodo(item.id)}/>

여기에 할당된 것은 익명 함수이고 할당 중에 생성되기 때문에 위의 함수 전송 모드를 사용하지 않아야 합니다. 즉, 각 렌더링이 새로운 함수를 생성한다는 의미입니다. 문제.

전달해야 할 소품이 많다면?

글쎄~~React-Redux를 사용한다면 shouldComponentUpdate의 기본 구현이 있습니다.

3. 여러 React 구성 요소의 성능 최적화

React 구성 요소가 로드, 업데이트 및 언로드되면 구성 요소의 일련의 수명 주기 함수가 호출됩니다. 그러나 이러한 수명주기 기능은 특정 React 구성 요소 기능을 위한 것입니다. 애플리케이션에는 위에서 아래로 결합된 많은 React 구성 요소가 있으며, 이들 간의 렌더링 프로세스는 더 복잡합니다.

동일 컴포넌트의 렌더링 프로세스도 로드 단계, 업데이트 단계, 언로드 단계의 세 가지 프로세스를 고려해야 합니다.

로딩 단계에서는 어쨌든 한 번만 컴포넌트를 완전히 렌더링해야 하며, 이로부터 모든 하위 구성 요소는 React 컴포넌트 하향, React 컴포넌트의 로딩 라이프사이클을 거쳐야 하므로 최적화할 부분이 많지 않습니다.

제거 단계에는 오직 하나의 라이프사이클 함수인 componentWillUnmount가 있습니다. 이 함수는 componentDidMount 및 기타 마무리 작업에 의해 추가된 이벤트 처리 및 모니터링만 정리하므로 최적화할 여지가 없습니다. React 업데이트 단계(조정) 프로세스에서

컴포넌트 업데이트 프로세스 중에 업데이트된 Virtual DOM이 빌드되고 이전 Virtual DOM과 비교되어 차이점을 찾아 최소한의 DOM 작업으로 업데이트됩니다

调和过程：即React更新中对Virtual DOM找不同的过程，通常对比两个N个节点的树形结构的算法，时间复杂度是O(n*3),如果直接

使用默认对比，节点过多的话，需要操作的数量太多，而React不可能采用这种算法；

React实际采用的算法时间复杂度是O(N)(时间复杂度只是对一个算法最好和最差情况下需要的指令操作数量级的估量)

React的Reconciliation算法并不复杂，首先检查两个树形的根节点的类型是否相同，根据相同或者不同有不同的处理方式：

节点类型不同的情况

如果树形节点的类型不相同，那就意味着改动很大，直接认为原来的那个树形结构已经没用，可以扔掉，需要从新构建DOM树，原有的树形上的React组件便会经历“卸载”的生命周期；

也就是说，对于Virtual DOM树这是一个“更新”过程，但是却可能引发这个树结构上某些组件的“装载”和“卸载”过程
如：

更新前

 <p>
  <Todos />
 </p>

我们想要更新成这样：

 <span>
   <Todos />
 </span>

>1. 那么在作比较的时候，一看根节点原来是p，新的是span，类型就不一样了，那么这个算法就废弃之前的p包括里面的所有子节点，从新构建一个span节点和子节点；

>2. 很明显因为根节点不同就将所有的子节点从新构建，这很浪费，但是为了避免O(N*3)的时间复杂度，React这能选择这种比较简单、快捷的方法；

>3. 所以，作为开发者，我们一定要避免上面的浪费的情景出现

节点类型相同的情况

如果两个节点类型相同时，对于DOM元素，React会保留节点对应的DOM元素，只对其节点的属性和内容做对比，然后只修改更新的部分；

节点类型相同时，对于React组件类型，React做得是根据新节点的props去更新节点的组件实例，引发组件的更新过程；

在处理完根节点对比后，React的算法会对根节点的每一个子节点重复一样的操作

多个相同子组件的情况

如果最初组件状态为：

<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

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，并没有预期让组将直接访问。

上面是我整理给大家的，希望今后会对大家有帮助。

相关文章：

如何关闭Vue计算属性自带的缓存功能，具体步骤有哪些？

Vue에서 Compass를 사용하는 구체적인 방법이 있나요?

vue2.0의 swiper 구성 요소를 사용하여 캐러셀 구현(자세한 튜토리얼)

위 내용은 React 컴포넌트의 성능 최적화에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!