[한국어 번역] How Flutter Works: The Three Trees #DecodingFlutter (2/6)

https://www.youtube.com/watch?v=xiW3ahr4CRU

.

인트로 (Intro)

0:00

CRAIG LABENZ:
“How Flutter Works” 에피소드 2에 다시 오신 것을 환영합니다.

0:10
이전 에피소드에서 저는 Flutter가 주로 세 가지 서로 다른 트리 구조에 의해 동작한다고 살짝 언급했습니다.

0:13
하나는 우리가 Flutter 개발자로서 직접 작성하는 위젯(widget)으로 가득 찬 트리,

0:17
하나는 우리가 거의 직접 작성하지는 않지만 항상 상호작용하게 되는 엘리먼트(element)로 가득 찬 트리,

0:21
그리고 마지막 하나는 가끔씩 직접 작성하기도 하는 렌더 오브젝트(render object)로 이루어진 트리입니다.

0:30
위젯이 가장 눈에 띄는 개념이므로, 먼저 위젯부터 시작해 보겠습니다.

위젯이란 무엇인가? (What is a widget?)

0:35
위젯이란 무엇일까요?

0:37
위젯은 Flutter 개발자들이 대부분의 시간을 보내며 다루는 선언형 API를 제공합니다.

0:43
각각의 위젯은 불변(immutable)이며 일회용(disposable)입니다.

0:46
즉, UI의 해당 부분이 변경될 필요가 있을 때마다 위젯은 버려지고 새로 생성됩니다.

0:51
현실 세계에서 일회용 플라스틱은 매우 낭비적이지만,

0:55
Flutter 앱에서는 일회용 위젯이 애플리케이션 코드를 훨씬 단순하게 만들어 주며,

0:57
Dart는 충분히 빠르기 때문에 이러한 방식이 문제없이 작동합니다.

1:02
위젯은 크게 세 가지 유형으로 나뉩니다.

1:05

• StatelessWidget
• StatefulWidget
• RenderObjectWidget

1:09
Flutter 개발자의 99% 이상은 StatelessWidget 또는 StatefulWidget을 상속해 사용합니다.

1:14
그 결과 RenderObjectWidget은 나중에 다룰 비교적 특수한 경우로 남게 됩니다.

1:18
또한 네 번째 유형의 위젯인 InheritedWidget도 있는데,

1:21
이 위젯은 데이터를 전달하기만 하고 자체적으로는 아무것도 렌더링 하지 않습니다.

1:25
이에 대해서는 에피소드 3에서 더 자세히 다룰 예정입니다.

Stateless 위젯과 Stateful 위젯의 차이

1:28
그렇다면 가장 흔한 StatelessWidget과 StatefulWidget의 차이는 무엇일까요?

1:34
StatelessWidget은 지금까지 우리가 주로 이야기해 온 형태이며,

1:36
새로운 UI 코드를 작성할 때 가장 먼저 떠올리게 되는 위젯 타입입니다.

1:41
StatelessWidget은 부모 위젯의 build 메서드에서 생성되며,

1:44
UI의 해당 부분이 어떤 이유로든 다시 빌드되어야 할 때까지만 존재합니다.

1:49
에피소드 1에서 언급했듯이, 위젯은

1:52
필요한 매개변수를 받을 수 있는 선택적인 생성자와,

1:55
더 많은 위젯을 조합하는 build 메서드를 가지고 있습니다.

1:59
StatelessWidget은 UI의 한 측면을 설명하며,

2:01
그 부분이 변경될 때까지 사용됩니다.

2:05
반면 StatefulWidget은 더 많은 기능과 능력을 가진 위젯입니다.

2:09
기술적으로 보면, StatefulWidget의 “위젯” 부분 자체는 StatelessWidget과 마찬가지로 생명력이 없고 일회용입니다.

2:15
하지만 StatefulWidget은 더 오래 살아남는, 그리고 매우 중요한
State 객체에 의해 뒷받침됩니다.

2:18
이 State 객체가 바로 에피소드 3의 핵심 주제입니다.

2:23
애니메이션 컨트롤러나 텍스트 편집 컨트롤러처럼 오래 유지되어야 하는 리소스가 필요할 때,

2:29
또는 위젯이 애플리케이션 상태의 변화를 관리해야 할 때 StatefulWidget을 사용합니다.

2:34
StatefulWidget은 StatelessWidget과 외형도 약간 다르며,

2:36
가장 큰 차이점은 build 메서드가 위젯이 아닌 State 객체에 위치한다는 점입니다.

2:41
그리고 이 State 객체는 Flutter의 두 번째 트리에서 관리됩니다.

2:43
이제 그 트리에 대해 이야기해 볼 좋은 시점입니다.

엘리먼트 트리 (The Element Tree)

2:46
이 트리는 엘리먼트 트리(element tree)라고 불립니다.

2:50
엘리먼트 트리는 위젯 트리 뒤에 존재하며,

2:54
위젯과 Flutter 내부의 렌더링 계층을 연결하는 더 오래 살아남는 객체인 엘리먼트(element) 들로 구성됩니다.

2:58
엘리먼트는 프레임마다 위젯 트리의 변화를 분석하고,

3:01
그 변화가 의미하는 바를 판단한 뒤,

3:04
필요한 모든 처리를 해결합니다.

3:06
Flutter 개발자는 거의 직접 엘리먼트를 작성하지 않지만,

3:09
엘리먼트는 항상 뒤에서 모든 것을 움직이고 있습니다.

BuildContext란 무엇인가?

3:12
여기서 엘리먼트에 대한 짧은 설명을 덧붙이겠습니다.

3:14
지금까지 여러 번 등장했던 이 신비로운 BuildContext 객체가 무엇인지 궁금할 수 있습니다.

3:17
Android 개발자에게는 익숙한 이름이지만,

3:21
Flutter에서 BuildContext란 무엇일까요?

3:24
정답은 간단합니다. BuildContext는 해당 위젯의 엘리먼트입니다.

3:28
위젯이 엘리먼트를 생성하고,

3:31
그 엘리먼트는 build 메서드에서 중요한 정보를 조회할 수 있도록 자신을 다시 제공합니다.

위젯 → 엘리먼트 → 빌드 흐름

3:36
이 흐름은 다음과 같습니다.

3:38
새 위젯이 위젯 트리에 처음 추가되면,

3:41
프레임워크는 해당 위젯의 createElement 메서드를 호출합니다.

3:43
그리고 생성된 엘리먼트는 엘리먼트 트리에 연결됩니다.

3:46
이로 인해 위젯 트리와 엘리먼트 트리는 항상 동일한 형태를 유지합니다.

3:51
이후 Flutter가 위젯 트리를 따라 재귀적으로 내려가면서,

3:54
해당 위젯의 build 메서드를 호출합니다.

3:57
그런데, 누가 build 메서드를 호출할까요?

3:59
바로 엘리먼트입니다.

4:00
엘리먼트가 자신의 위젯의 build 메서드를 호출하면서,

4:05
자기 자신을 BuildContext로 전달합니다.

4:08
이 과정에서 더 많은 위젯이 생성되고, 이 흐름은 계속 반복됩니다.

위젯 트리와 엘리먼트 트리의 변화

4:12
이제 UI가 시간에 따라 변화할 때 이 트리들이 어떻게 동작하는지 시각화해 봅시다.

4:16
예를 들어, 이 블록이 애니메이션 중에 색상이 바뀐다고 가정해 보겠습니다.

4:20
여기에는 가상의 위젯 트리와 이를 뒷받침하는 엘리먼트 트리가 있습니다.

4:24
최상단의 위젯은 애니메이션 동안 매 프레임마다 변경되고 다시 빌드됩니다.

4:31
이 재빌드 과정에서 모든 하위 위젯은 제거되고 새 위젯으로 대체됩니다.

4:36
반면 엘리먼트 트리는 가능한 한 오래 유지되며,

4:40
이 예제에서는 새 위젯들이 기존 엘리먼트와 같은 위치에서 짝지어질 수 있습니다.

4:48
하지만 항상 이런 것은 아닙니다.

4:50
이 예제에서는 현재 색상 값과 시간에 따른 변경 로직이

4:52
앞서 이야기한 State 객체에 저장되어 있습니다.

4:59
즉, 이 트리의 최상단 노드는 처음부터 StatefulWidget이었던 것입니다.

5:01
그리고 엘리먼트는 그 State 객체를 항상 준비된 상태로 유지합니다.

5:07
보셨죠?

5:08
엘리먼트는 보이지 않는 곳에서 모든 것을 조종하는 Flutter의 진정한 지배자입니다.

RenderObject 위젯과 렌더 트리

5:15
Flutter 개발자는 주로 위젯, State 객체, 그리고 build 메서드를 작성합니다.

5:18
이 세 가지 작업은 연습하면 매우 재미있어집니다.

5:23
세 번째 위젯 유형인 RenderObjectWidget은 완전히 다른 역할을 합니다.

5:25
바로 렌더 오브젝트(render object)를 생성하는 것입니다.

5:29
RenderObjectWidget에는 build 메서드가 없습니다.

5:32
대신 다음 두 가지 메서드를 가집니다.

5:35

• createRenderObject
• updateRenderObject

5:38
이에 대해서는 에피소드 4와 5에서 자세히 살펴볼 예정입니다.

렌더 트리 (The Render Tree)

5:42
렌더 오브젝트들은 Flutter의 마지막 주요 트리인 렌더 트리(render tree)를 구성합니다.

5:47
렌더 오브젝트는 위젯의 값을 실제 그리기 명령으로 변환합니다.

5:49
이 명령은 결국 GPU에서 실행됩니다.

5:53
렌더 오브젝트 역시 엘리먼트처럼 상대적으로 오래 살아남는 객체입니다.

5:56
일부 Flutter 개발자는 직접 커스텀 렌더 오브젝트를 작성하기도 합니다.

5:59
이에 대해서는 Flutter Build Show의 첫 번째 에피소드에서 다뤘습니다.

Flutter 렌더링 파이프라인

6:05
Flutter 아키텍처의 핵심은 다단계로 구성된, 매우 계층적이고 추상화된 렌더링 루프입니다.

6:09
각 계층은 데이터를 조금씩 변환하여,

6:13
운영체제가 화면에 표시할 수 있는 픽셀 버퍼에 한 걸음씩 가까워지게 만듭니다.

6:20
이 단계에서 위젯 트리 안에 있는 RenderObjectWidget들은

6:22
렌더 오브젝트를 생성하며 한 단계 앞으로 나아갑니다.

6:30
렌더 오브젝트는 다시 트리 구조를 이루며,

6:32
위젯의 속성을 사용해 다음과 같은 핵심 작업을 수행합니다.

• 접근성 (Accessibility)
• 레이아웃 (Layout)
• 페인팅 (Painting)
• 히트 테스트 (Hit Testing: 사용자가 클릭하거나 터치한 UI 요소 판별)

6:48
여기서 페인팅은 바로 픽셀을 그리는 것처럼 들릴 수 있지만,

6:50
실제로는 그리기 명령(drawing commands)만 생성합니다.

6:52
이 명령은 나중에 Skia 또는 Impeller가 실제로 화면에 그리게 됩니다.

마무리 및 다음 에피소드 예고

7:01
이것으로 Flutter의 세 가지 주요 트리를 살펴보았습니다.
이번 편에서는 특히 위젯 트리에 초점을 맞췄습니다.

7:06
Flutter에는 이 외에도 다음과 같은 트리들이 존재합니다.

• 접근성을 위한 시맨틱 트리
• 키보드 포커스를 위한 포커스 트리
• UI 합성을 위한 레이어 트리

7:16
하지만 오늘 다룬 세 가지 트리가 일상적인 Flutter 개발에서 가장 중요합니다.

7:20
다음 에피소드에서는 State 객체의 라이프사이클을 살펴보고,

7:23
에피소드 4와 5에서는 렌더 트리가 어떻게 Flutter 엔진으로 바통을 넘기는지 자세히 알아볼 예정입니다.

7:33
그때 다시 만나요.

🎵 (음악)