일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- shortcut
- Swift
- js
- styled-components
- GitLab
- HTML
- git
- ios
- Branch
- npm install
- npm
- nextJS
- currying
- Xcode
- react-native
- JavaScript
- React Native
- ES6
- rn
- REACT
- Docker
- styling
- github
- vscode
- Android
- xtring.log
- commit
- DevOps
- viewcontroller
- ReactNative
- Today
- Total
xtring.dev
[React] React Reconciliation 알아보기 본문
'전문가를 위한 리액트' 4장 재조정(reconciliation)을 읽으며 알게된 내용을 정리합니다.
React의 Reconciliation
React는 UI 업데이트를 효율적으로 처리하기 위해 Reconciliation
라는 과정을 사용합니다. 간단하게 설명하자면, 이 과정은 React의 Virtual DOM과 실제 브라우저의 DOM의 차이를 계산하고, 최소한의 DOM 조작으로 UI를 업데이트하기 위한 목적을 가지고 만들어졌습니다. 종종 'React의 장점이 뭐에요?'라는 질문을 받곤하면 업데이트할 내용을 한번에 계산하고 Virtual DOM과 실제 DOM 간의 비교를 통해 렌더링을 최소화하는 알고리즘을 가지고 있어 성능이 좋다는 설명을 하곤 했는데 Reconciliation에 대해서 자세히 알아보면서 더 자세한 동작 방법을 알 수 있게 되었습니다.
Reconciliation의 가장 중요한 목표는 빠르고 부드러운 UX를 보장하는 것입니다. React가 Reconciliation 이라는 과정을 어떤 식으로 처리할까요?
가장 먼저 UI의 변경이 발생하면 새로운 Virtual DOM을 생성하여 실제 돔과 대칭되는 가벼운 Tree 구조의 데이터 구조를 생성합니다. 그리고 상태에 대한 업데이트를 계산하고 Virtual DOM에 업데이트합니다. 다음으로 기존 DOM과 대비하여 업데이트 되어야할 내용을 비교(diffing)합니다. 마지막으로 변경이 필요한 부분만 실제 DOM에 적용하여 업데이트합니다.
- Virtual DOM 생성: UI 변경이 발생하면 React는 새로운 가상 DOM 트리를 생성
- 변경 사항 계산: 기존의 가상 DOM과 새로 생성된 Virtual DOM을 비교(diffing)하여 변경 사항을 계산
- 업데이트 수행: 변경이 필요한 부분만 실제 DOM에 적용
아무렇지 않게 사용중인 React는 실제로 바쁘게 계산하고 우리가 사용하기 편하도록 움직입니다.
React의 Reconciliation 메커니즘은 초창기부터 개발되어지고 있었고 특히 React 16에서 Fiber Reconciliation라는 새로운 구조를 도입하면서 큰 변화가 생겼습니다.
React 16 이전의 Stack Reconciliation
React 16 이전에는 Stack Reconciliation이라는 알고리즘을 통해 DOM 업데이트 사항을 체크했습니다. 이 방식은 우선적으로 업데이트해야할 UI를 확인하지 않고, 순차적으로 모든 요소를 둘러보며 업데이트 사항을 확인하는 방식으로 동작했습니다. 간단하게 생각해도 비효율적이라는 생각이 듭니다. 따라서 점점 더 구조가 복잡해지는 UI에서는 적절하지 못한 방식이 되었습니다.
특징과 한계점을 정리하자면 아래와 같습니다.
Stack Reconciliation 특징
- 동기적 처리
• UI 업데이트는 재귀적으로 수행되며, 컴포넌트 트리의 루트에서 시작해 각 자식 컴포넌트를 순차적으로 처리한다.
• 이는 JavaScript의 단일 스레드 특성을 따르며, 콜 스택을 이용해 깊이 우선 탐색 방식으로 실행된다. - 최적화된 비교
• React는 각 컴포넌트의 key를 기반으로 자식 목록을 비교하여, 불필요한 재렌더링을 줄였다.
• 동일한 key를 가진 요소는 재사용하고, 변경된 부분만 다시 렌더링한다.
한계점
- 대규모 업데이트 처리가 어려움
• UI가 복잡해지고, 업데이트가 오래 걸릴 경우, 메인 스레드가 차단(blocking)되어 사용자가 UI를 조작할 수 없는 상태가 발생 - 작업 중단 불가
• 한 번 작업이 시작되면 중단 없이 끝까지 처리해야 하므로, 높은 우선순위의 작업(예: 사용자 인터렉션)을 끼워넣기 어려움
이러한 단점을 보완하기 위해 Fiber 아키텍처를 React 16에서 도입하게됩니다.
Fiber Reconciliation
React 16에서 도입된 Fiber Reconciliation은 UI 업데이트를 더 유연하고 효율적으로 처리하기 위한 새로운 알고리즘으로 만들어졌습니다. Fiber는 React의 코어 알고리즘을 재설계하여 이전의 Stack Reconciliation을 개선하여 다음과 같은 특징을 가지게 되었습니다.
주요 특징
- 작업의 단위화(Incremental Rendering)
• Fiber는 작업을 작은 단위(chunk)로 나누어 실행
• 이로 인해 작업 중단과 재개가 가능해져, 긴 작업이 메인 스레드를 차단하지 않도록 설계됨 - 우선순위 기반 스케줄링
• React는 업데이트의 중요도에 따라 우선순위 부여
• Fiber는 낮은 우선순위의 작업을 잠시 중단하고, 높은 우선순위의 작업을 먼저 처리할 수 있음(Stack Reconciliation의 동작 방식과 차이점) - 메모리 효율성
• Fiber는 각 컴포넌트의 업데이트를 표현하는 데이터 구조로, 이전과 이후 상태를 추적할 수 있음
• 시간을 절약하고 메모리 사용을 최적화
동작 과정
- 렌더 단계(Render Phase)
• React는 Fiber 트리를 순회하며 새로운 가상 DOM을 생성하고 변경 사항 계산
• 이 단계는 비동기적으로 수행 - 커밋 단계(Commit Phase)
• 실제 DOM 업데이트와 같은 작업이 이 단계에서 이루어짐
• 이 단계는 동기적으로 수행되며, 화면에 즉시 반영
Fiber의 장점
그렇다면 Fiber Reconciliation의 장점은 아래와 같이 정리될 수 있겠습니다.
• 중단 가능한 렌더링: 긴 작업 중에도 사용자 이벤트를 빠르게 처리할 수 있음
• 애니메이션 개선: React는 프레임 단위로 작업을 나눌 수 있어, 애니메이션과 전환 효과를 부드럽게 처리
• 더 나은 사용자 경험: 브라우저의 메인 스레드가 차단되지 않으므로, 사용자와의 상호작용이 끊기지 않음
과거 React 16 이전의 Stack Reconciliation은 간단하고 동기적으로 동작했지만, 긴 작업이 메인 스레드를 차단하는 문제가 있었습니다. 새로운 Fiber Reconciliation은 작업을 작은 단위로 나누고 우선순위를 고려하는 비동기적 방식으로, 사용자 경험을 크게 향상시켰습니다.
마무리
Fiber는 React가 더 복잡한 UI를 효과적으로 처리할 수 있는 기반을 제공하여 또 한번 React 개발자들의 생산성을 향상 시켜준 것 같습니다. 기술의 속을 자세히 들여다보는 것은 그 기술을 다른 시각으로 새롭게 볼 수 있도록 하는 것 같습니다.
'Front-End > React' 카테고리의 다른 글
[React] eject가 필요하다면 - npm run eject (0) | 2021.02.03 |
---|---|
(deprecated)[React] Redux 궁금증 해소하기 - 15가지 질문들 (0) | 2021.01.25 |
[React] 프로젝트 디렉토리 구조 도대체 어떻게 잡아야 되나요? - 고민하지 마세요🙃 (0) | 2021.01.10 |
[React] 코드 분할(Code Splitting) - React 더 잘 사용하기 (1) | 2020.06.29 |
[React] Functional Component에서 Hooks를 사용하자. (useState, useEffect) (0) | 2020.06.24 |