플러터 공식문서를 번역하여 정리한 글입니다.
렌더링 프로세스
목차
렌더링 프로세스
플러터는 어떻게 빠른 성능을 낼까?
먼저 안드로이드를 살펴보자.
안드로이드는 java코드를 통해 시스템 라이브러리의 ui를 호출하고,
skia 엔진을 통해 canvas에 ui를 그린다.
그리고 일반적인 크로스 플랫폼 프레임워크는
안드로이드, ios의 UI에 대한 추상화를 통해
시스템 라이브러리의 UI를 사용한다.
이 방식은 앱 로직과 UI간의 상호작용이 많아질수록 성능에 큰 영향을 미친다.
반면에 플러터는 시스템 라이브러리의 UI를 플러터 자체에서 직접 제공한다.
그리고 이 dart코드를 네이티브 코드로 컴파일하여
skia엔진(또는 Impeller)을 통해 렌더링을 하기 때문에 빠른 성능을 보여줄 수 있다.
렌더링 과정 살펴보기
플러터에서는 위젯이 실제화면에 그려지기까지
3가지의 계층구조(트리)를 이용한다.
Container(
color: Colors.blue,
child: Row(
children: [
Image.network('https://www.example.com/1.png'),
const Text('A'),
],
),
);위 코드를 예시로 살펴보자.
실제 위젯트리는 다음과 같이 구성된다.
실제 위젯 계층구조에는
ColoredBox, RawImage, RichText 위젯이 포함된다.
빌드 단계에서 위젯트리를 엘리먼트 트리로 변환한다.
엘리먼트 트리는 다른 요소의 부모역할을 하는 ComponentElement와
실제 렌더링되는 RenderObjectElement로 이루어진다.
그리고 실제로 화면에 그려지는 렌더트리와 중간 다리 역할을 한다.
렌더트리는 RenderObject를 상속받은 위젯들로 구성된다.
자식요소에 제약조건(constrains, 높이 넓이 등의 정보)를 전달하고
자식요소는 제약조건 내에서 자기자신의 size를 부모에게 전달하여
실제 화면에 어느위치에 어느 크기로 그려지는지를 정하게 된다.
3단계 트리구조의 장점
이 트리구조는 효율적인 렌더링을 도와준다.
상태 변경으로 인한 리렌더링 상황을 가정해보자.
부모위젯에서 build 메서드가 실행되면 자식위젯들까지 새로 build되며
위젯트리를 새로 생성하게 된다.
그리고 엘리먼트 트리에서 변경사항을 감지하여 변경사항이 있는 경우에만 업데이트한다.
변경사항이 없는 경우에는 기존의 요소를 재사용하여 렌더링 성능을 최적화 한다.
(변경사항을 감지하는 방법은 위젯의 key와 shouldUpdateWidget 함수, diffing 알고리즘 등을 사용한다.)
즉, 위젯트리가 새로 그려진다고 엘리먼트 트리와 렌더 트리가 항상 새로 그려지는 것은 아니다.
