플러터(Flutter)의 핵심 철학은 '모든 것은 위젯(Widget)'이라는 한 문장으로 요약될 수 있습니다. UI를 구성하는 버튼, 텍스트, 레이아웃부터 보이지 않는 데이터 처리, 애니메이션에 이르기까지 모든 것이 위젯의 조합으로 이루어집니다. 이러한 위젯 기반의 선언적 UI 프레임워크에서 개발자가 작성하는 코드는 UI의 '설계도'와 같습니다. 개발자는 현재 상태에 따라 UI가 어떻게 보여야 하는지를 정의할 뿐, 실제 화면을 그리고 상태 변화에 따라 UI를 업데이트하는 복잡한 과정은 플러터 프레임워크가 담당합니다.
이러한 아키텍처의 중심에는 '위젯 생명주기(Widget Lifecycle)'가 있습니다. 생명주기란 위젯이 화면에 나타나고(생성), 상태가 변경되어 업데이트되고,最终 화면에서 사라지기(소멸)까지의 전 과정을 의미합니다. 이 흐름을 정확히 이해하는 것은 단순히 앱을 만드는 것을 넘어, 효율적이고 안정적이며 성능이 뛰어난 애플리케이션을 구축하는 데 필수적입니다. 생명주기를 모른 채 개발하면 불필요한 리소스 낭비, 메모리 누수, 예상치 못한 버그 등 다양한 문제에 직면할 수 있습니다.
이 글에서는 플러터의 두 가지 핵심 위젯인 StatelessWidget과 StatefulWidget의 생명주기를 심층적으로 분석합니다. 각 생명주기 메서드가 호출되는 시점과 역할, 그리고 이들을 활용한 실용적인 예제를 통해 위젯의 동작 원리를 깊이 있게 탐구하고, 더 나아가 플러터의 성능 최적화 근간이 되는 '세 개의 트리(Widget, Element, RenderObject)' 개념과 생명주기의 관계를 조명하여 플러터 개발의 근본적인 이해를 돕고자 합니다.
플러터가 UI를 그리는 방식: 세 개의 트리
위젯의 생명주기를 제대로 이해하기 위해서는 플러터가 내부적으로 UI를 어떻게 관리하고 렌더링하는지에 대한 선행 지식이 필요합니다. 플러터는 효율적인 UI 업데이트를 위해 세 종류의 트리 구조를 사용하며, 이들은 각각 다른 역할을 수행합니다.
- 위젯 트리 (Widget Tree): 개발자가 코드에서 직접 작성하는 부분입니다. UI의 구성과 설계를 담고 있는 '청사진'에 해당합니다.
build메서드를 통해 생성되며, 상태가 변경될 때마다 새롭게 생성될 수 있습니다. 위젯 자체는 불변(immutable)하며, 단지 설정값들의 집합일 뿐입니다. 이 때문에 위젯 트리는 매우 가볍고 빠르게 생성 및 폐기될 수 있습니다. - 엘리먼트 트리 (Element Tree): 위젯 트리를 기반으로 생성되는 중간 다리 역할의 트리입니다. 화면에 표시되는 위젯의 실제 위치와 구조를 관리하며, 한 번 생성되면 위젯이 변경되어도 최대한 재사용됩니다. 각 엘리먼트는 특정 위젯과 연결되어 있으며, 해당 위젯의 타입과 키(Key)를 비교하여 위젯이 변경되었을 때 기존 엘리먼트를 업데이트할지, 아니면 새로운 엘리먼트를 생성할지를 결정합니다.
State객체는 바로 이 엘리먼트 트리에 의해 관리되므로, 위젯 트리가 계속해서 재생성되어도 상태가 유지될 수 있는 것입니다. - 렌더 객체 트리 (RenderObject Tree): 실제 화면에 UI를 그리고, 레이아웃을 계산하며, 사용자 입력을 처리하는 등 무거운 작업을 담당하는 트리입니다. 엘리먼트 트리에 의해 생성되고 관리되며, 생성 및 업데이트 비용이 가장 높습니다. 플러터는 렌더 객체 트리의 변경을 최소화하는 방향으로 동작하여 높은 성능을 유지합니다.
이 세 가지 트리의 분리 덕분에 플러터는 개발자가 setState()를 호출하여 UI 전체를 다시 그리는 것처럼 코드를 작성하더라도, 내부적으로는 변경이 필요한 최소한의 부분만 효율적으로 찾아내어 렌더 객체 트리를 업데이트할 수 있습니다. 위젯의 생명주기는 바로 이 엘리먼트 트리가 생성되고, 업데이트되고, 소멸되는 과정과 밀접하게 연관되어 있습니다.
정적인 화면의 구성: StatelessWidget의 생명주기
StatelessWidget은 이름 그대로 '상태가 없는' 위젯입니다. 한 번 생성되면 내부의 데이터가 변하지 않으며, 오직 부모 위젯으로부터 전달받은 초기 설정값(properties)에 의해서만 화면이 결정됩니다. 아이콘, 고정된 텍스트, 디자인을 위한 컨테이너 등 정적인 UI 요소를 구성하는 데 주로 사용됩니다.
StatelessWidget의 생명주기는 매우 단순하며, 두 단계로 구성됩니다.
1. 생성자 (Constructor)
위젯이 코드상에서 처음 인스턴스화될 때 호출됩니다. 부모 위젯으로부터 필요한 데이터를 전달받아 final 키워드로 선언된 멤버 변수에 할당하는 역할을 합니다. 이 단계에서 받은 데이터는 위젯의 수명 동안 절대 변하지 않습니다.
// 부모 위젯으로부터 'title'과 'message'를 전달받는 StatelessWidget
class StaticInfoCard extends StatelessWidget {
final String title;
final String message;
// 생성자: 전달받은 값으로 final 변수를 초기화한다.
// const 생성자를 사용하면 컴파일 타임에 위젯을 상수로 만들 수 있어 성능에 이점이 있다.
const StaticInfoCard({
Key? key,
required this.title,
required this.message,
}) : super(key: key);
@override
Widget build(BuildContext context) {
// ...
}
}
2. `build` 메서드
build(BuildContext context) 메서드는 StatelessWidget의 핵심입니다. 이 메서드는 화면에 표시될 위젯의 구조를 정의하고 반환하는 역할을 합니다. 플러터 프레임워크는 이 메서드가 반환한 위젯 트리를 기반으로 엘리먼트 트리를 구성하고 화면을 렌더링합니다.
build 메서드가 호출되는 주요 시점은 다음과 같습니다:
- StatelessWidget이 처음으로 위젯 트리에 삽입될 때
- 부모 위젯이 리빌드되면서 이 위젯에 전달하는 설정값이 변경되었을 때
- 이 위젯이 의존하는
InheritedWidget이 변경되었을 때
중요한 점은 build 메서드는 여러 번 호출될 수 있다는 것입니다. 따라서 이 메서드 안에서는 항상 UI를 구성하는 코드만 작성해야 하며, 비동기 작업이나 계산 비용이 큰 로직을 수행하는 것은 피해야 합니다. build 메서드는 외부 요인에만 의존하며, 동일한 입력에 대해 항상 동일한 위젯 트리를 반환하는 순수 함수(pure function)처럼 동작해야 합니다.
class StaticInfoCard extends StatelessWidget {
final String title;
final String message;
const StaticInfoCard({
Key? key,
required this.title,
required this.message,
}) : super(key: key);
// build 메서드는 위젯의 UI를 정의한다.
@override
Widget build(BuildContext context) {
// 이 메서드는 프레임워크에 의해 여러 번 호출될 수 있으므로
// 가볍고 빠르게 실행되어야 한다.
return Card(
child: Padding(
padding: const EdgeInsets.all(16.0),
child: Column(
crossAxisAlignment: CrossAxisAlignment.start,
children: [
Text(
title,
style: Theme.of(context).textTheme.headline6,
),
const SizedBox(height: 8.0),
Text(message),
],
),
),
);
}
}
StatelessWidget은 이처럼 단순한 생명주기를 가지므로 상태 관리가 필요 없는 가벼운 UI 컴포넌트를 만들 때 매우 효율적입니다. 개발자는 '언제' 화면을 그릴지 고민할 필요 없이, 주어진 데이터로 '어떻게' 보일지만 정의하면 됩니다.
동적인 화면의 핵심: StatefulWidget의 생명주기
StatefulWidget은 '상태를 가질 수 있는' 위젯입니다. 사용자 상호작용, 데이터 수신, 애니메이션 등 시간의 흐름에 따라 위젯의 모습이 변해야 할 때 사용됩니다. StatefulWidget 자체는 StatelessWidget처럼 불변(immutable)이지만, 자신과 쌍을 이루는 별도의 State 객체를 생성하여 가변적인 상태를 관리합니다.
이러한 구조 때문에 StatefulWidget의 생명주기는 StatelessWidget보다 훨씬 복잡하며, 크게 생성(Creation), 마운트(Mounting), 업데이트(Updating), 소멸(Unmounting)의 네 단계로 나눌 수 있습니다.
1. 생성 단계 (Creation)
이 단계는 위젯 인스턴스와 State 객체가 생성되는 과정입니다.
-
`Constructor` (StatefulWidget의 생성자)
StatelessWidget과 마찬가지로, StatefulWidget이 인스턴스화될 때 가장 먼저 호출됩니다. 부모로부터 전달받은 불변의 설정값(widget properties)을 초기화합니다.
-
`createState()`
생성자 호출 직후, 플러터 프레임워크는 이 메서드를 호출하여 해당 위젯과 연결될 State 객체를 생성합니다. 이 메서드는 위젯의 전체 생명주기 동안 단 한 번만 호출됩니다. 여기서 반환된 State 객체가 위젯의 모든 가변 상태를 관리하게 됩니다.
// StatefulWidget 자체는 불변(immutable)이며, 부모로부터 초기 데이터를 받는다.
class CounterWidget extends StatefulWidget {
final int initialValue;
const CounterWidget({Key? key, this.initialValue = 0}) : super(key: key);
// createState()는 프레임워크에 의해 호출되어 State 객체를 생성한다.
@override
_CounterWidgetState createState() => _CounterWidgetState();
}
// State 객체는 가변적이며, 위젯의 상태를 저장하고 관리한다.
class _CounterWidgetState extends State<CounterWidget> {
// ... State의 생명주기 메서드들이 여기에 위치한다.
}
2. 마운트 단계 (Mounting) - 화면에 처음 나타날 때
State 객체가 생성되고 엘리먼트 트리에 삽입되어 화면에 처음 렌더링될 때까지의 과정입니다. 이 단계의 메서드들은 순서대로 호출되며, 각각 중요한 역할을 합니다.
-
`mounted` 프로퍼티가 `true`가 됨
State 객체가 생성되어 엘리먼트 트리와 연결되면, `mounted` 프로퍼티가 `true`로 설정됩니다. 이 프로퍼티는 State 객체가 현재 트리에 활성화되어 있는지를 나타내는 중요한 플래그입니다. `dispose` 메서드가 호출되기 전까지 `true` 상태를 유지합니다.
-
`initState()`
`createState()` 직후, State 객체가 트리에 삽입될 때 단 한 번 호출됩니다. 이곳은 State 객체의 초기화 작업을 수행하기에 가장 이상적인 장소입니다.
- 상태 변수의 초기값 설정
- 애니메이션 컨트롤러, 텍스트 필드 컨트롤러 등 컨트롤러 객체 초기화
- 데이터 스트림 구독(Subscription)
- 한 번만 실행하면 되는 API 호출 등
주의: 이 시점에서는 아직 `BuildContext`가 완전히 활성화되지 않았기 때문에, `InheritedWidget.of(context)`와 같이 컨텍스트에 강하게 의존하는 코드를 호출하면 에러가 발생할 수 있습니다.
-
`didChangeDependencies()`
`initState()`가 호출된 직후에 처음 호출됩니다. 그리고 이 위젯이 의존하는 `InheritedWidget` (예: `Theme.of(context)`, `MediaQuery.of(context)`, `Provider.of(context)`)이 변경될 때마다 다시 호출됩니다. `initState`와 달리 이 메서드는 여러 번 호출될 수 있습니다.
컨텍스트에 의존적인 초기화 작업이나, `InheritedWidget`의 값에 따라 변경되어야 하는 로직을 수행하기에 적합합니다. 예를 들어, `Provider`로부터 데이터를 받아와 상태를 초기화하는 작업은 이곳에서 수행하는 것이 안전합니다.
-
`build()`
`didChangeDependencies()` 호출 후, 프레임워크는 `build` 메서드를 호출하여 위젯을 화면에 처음으로 그립니다. 이 메서드의 역할은 StatelessWidget과 동일하지만, State 객체가 가진 상태 값을 사용하여 UI를 구성한다는 차이점이 있습니다.
class _CounterWidgetState extends State<CounterWidget> {
late int _counter;
late AnimationController _controller;
// 1. initState: 상태 초기화 (컨트롤러, 변수 등)
@override
void initState() {
super.initState(); // 항상 super.initState()를 먼저 호출해야 한다.
print("initState called");
_counter = widget.initialValue; // 부모 위젯의 초기값을 사용
// _controller = AnimationController(...); // 컨트롤러 초기화
}
// 2. didChangeDependencies: InheritedWidget 의존성 변경 시 호출
@override
void didChangeDependencies() {
super.didChangeDependencies();
print("didChangeDependencies called");
// final user = Provider.of<User>(context); // Provider 등 컨텍스트 의존 작업
}
// 3. build: UI 구성
@override
Widget build(BuildContext context) {
print("build called");
return Scaffold(
body: Center(
child: Text('Count: $_counter'),
),
floatingActionButton: FloatingActionButton(
onPressed: _incrementCounter,
child: Icon(Icons.add),
),
);
}
void _incrementCounter() {
// ...
}
}
3. 업데이트 단계 (Updating) - 상태가 변경될 때
위젯이 이미 화면에 표시된 상태에서 내부 상태가 변경되거나 부모 위젯으로부터 새로운 설정값을 전달받았을 때 발생하는 과정입니다.
-
`didUpdateWidget(OldWidget oldWidget)`
부모 위젯이 리빌드되어 현재 위젯에 새로운 설정값을 전달할 때 호출됩니다. 예를 들어, 부모가 전달하는 `initialValue`가 변경되면 이 메서드가 실행됩니다. `widget` 프로퍼티는 이미 새로운 값으로 업데이트된 상태이며, `oldWidget` 파라미터를 통해 이전 값을 참조할 수 있습니다.
이전 값과 새로운 값을 비교하여 특정 로직을 수행해야 할 때 유용합니다. 예를 들어, 사용자의 ID가 변경되었을 때 기존의 데이터 구독을 취소하고 새로운 ID로 다시 구독하는 등의 작업을 처리할 수 있습니다.
-
`setState()`
StatefulWidget의 핵심 메서드입니다. 개발자가 위젯의 내부 상태를 변경했음을 프레임워크에 알리는 역할을 합니다.
setState()를 호출하면 다음과 같은 일이 발생합니다.- `setState`의 콜백 함수가 실행되어 상태 변수의 값이 변경됩니다.
- 해당 State 객체가 'dirty' 상태로 표시됩니다.
- 플러터 스케줄러는 다음 프레임에 이 위젯을 리빌드하도록 예약합니다.
이후 프레임워크는 다시 `build()` 메서드를 호출하여 변경된 상태가 반영된 새로운 UI를 그리게 됩니다.
중요: 비동기 작업(예: API 호출 후)이 완료된 시점에 위젯이 이미 화면에서 사라졌을 수 있습니다. 이때 `setState()`를 호출하면 에러가 발생합니다. 이를 방지하기 위해 `if (mounted) { ... }` 블록 안에서 `setState()`를 호출하는 것이 안전한 패턴입니다.
-
`build()`
`setState()`가 호출되거나 `didUpdateWidget`이 호출된 후, 프레임워크는 `build` 메서드를 다시 호출하여 화면을 갱신합니다.
class _CounterWidgetState extends State<CounterWidget> {
late int _counter;
// ... (initState, didChangeDependencies)
// 부모가 전달하는 값이 변경될 때 호출
@override
void didUpdateWidget(covariant CounterWidget oldWidget) {
super.didUpdateWidget(oldWidget);
print("didUpdateWidget called: new initialValue is ${widget.initialValue}");
// 이전 값과 새 값을 비교하여 필요한 작업을 수행
if (widget.initialValue != oldWidget.initialValue) {
setState(() {
_counter = widget.initialValue;
});
}
}
void _incrementCounter() {
// setState를 호출하여 상태 변경을 프레임워크에 알린다.
setState(() {
// 이 콜백 함수 안에서 상태 변수를 변경해야 한다.
_counter++;
});
}
@override
Widget build(BuildContext context) {
print("build called");
return Row(
mainAxisAlignment: MainAxisAlignment.center,
children: [
Text('Count: $_counter'),
IconButton(onPressed: _incrementCounter, icon: Icon(Icons.add))
],
);
}
// ...
}
4. 소멸 단계 (Unmounting) - 화면에서 사라질 때
위젯이 위젯 트리에서 영구적으로 제거될 때 발생하는 과정입니다. 메모리 누수를 방지하기 위해 이 단계에서 사용하던 리소스를 정리하는 것이 매우 중요합니다.
-
`deactivate()`
State 객체가 트리에서 제거될 때 호출됩니다. 대부분의 경우, `deactivate` 호출 직후 `dispose`가 호출되어 영구적으로 제거됩니다. 하지만 위젯이 트리 내의 다른 위치로 이동하는 경우(주로 `GlobalKey`를 사용할 때)에는 `deactivate`되었다가 다시 트리에 삽입되어 재활성화될 수 있습니다. 일반적으로는 직접 오버라이드할 일이 많지 않은 메서드입니다.
-
`dispose()`
State 객체와 엘리먼트가 위젯 트리에서 영구적으로 제거될 때 호출됩니다. 이 위젯은 다시는 리빌드되지 않으므로, 여기서 모든 리소스를 해제해야 합니다.
- `AnimationController`, `TextEditingController` 등 모든 컨트롤러의 `dispose()` 메서드 호출
- 구독했던 스트림(Stream)이나 `ChangeNotifier`의 리스너 해제
- 타이머(Timer) 취소
이 작업을 소홀히 하면 앱이 계속 실행되는 동안 해당 리소스들이 메모리에 남아 심각한 메모리 누수(memory leak)를 유발할 수 있습니다. `dispose` 메서드의 마지막에는 항상 `super.dispose()`를 호출해야 합니다.
-
`mounted` 프로퍼티가 `false`가 됨
`dispose()`가 호출된 후에는 `mounted` 프로퍼티가 `false`로 변경됩니다. 이 시점 이후에 `setState()`를 호출하면 에러가 발생합니다.
class _DataFetcherState extends State<DataFetcher> {
StreamSubscription? _dataSubscription;
final TextEditingController _controller = TextEditingController();
@override
void initState() {
super.initState();
_dataSubscription = someDataStream.listen((data) {
// ... 데이터 처리
});
}
// 4. dispose: 모든 리소스 해제
@override
void dispose() {
print("dispose called");
_dataSubscription?.cancel(); // 스트림 구독 취소
_controller.dispose(); // 컨트롤러 해제
super.dispose(); // 마지막에 super.dispose() 호출
}
@override
Widget build(BuildContext context) {
return TextField(controller: _controller);
}
}
생명주기를 활용한 실제 사례와 모범 사례
이론적인 지식을 바탕으로 실제 개발에서 생명주기를 어떻게 활용할 수 있는지 몇 가지 구체적인 사례를 통해 알아보겠습니다.
사례 1: API에서 데이터 가져오기
화면이 처음 로드될 때 API를 호출하여 데이터를 가져오는 것은 매우 흔한 작업입니다. 이 작업은 initState에서 시작하는 것이 일반적입니다.
class UserProfile extends StatefulWidget {
final int userId;
const UserProfile({Key? key, required this.userId}) : super(key: key);
@override
_UserProfileState createState() => _UserProfileState();
}
class _UserProfileState extends State<UserProfile> {
Future<User>? _userFuture;
@override
void initState() {
super.initState();
// initState에서 API 호출을 시작
_userFuture = _fetchUserData(widget.userId);
}
// userId가 변경되면 데이터를 다시 가져와야 함
@override
void didUpdateWidget(UserProfile oldWidget) {
super.didUpdateWidget(oldWidget);
if (widget.userId != oldWidget.userId) {
setState(() {
_userFuture = _fetchUserData(widget.userId);
});
}
}
Future<User> _fetchUserData(int id) async {
// API 호출 로직
final response = await http.get(Uri.parse('https://api.example.com/users/$id'));
if (response.statusCode == 200) {
return User.fromJson(jsonDecode(response.body));
} else {
throw Exception('Failed to load user');
}
}
@override
Widget build(BuildContext context) {
return FutureBuilder<User>(
future: _userFuture,
builder: (context, snapshot) {
if (snapshot.connectionState == ConnectionState.waiting) {
return Center(child: CircularProgressIndicator());
} else if (snapshot.hasError) {
return Center(child: Text('Error: ${snapshot.error}'));
} else if (snapshot.hasData) {
return Text('Name: ${snapshot.data!.name}');
}
return Container(); // 기본 상태
},
);
}
}
위 예제에서는 initState에서 첫 데이터 로드를 시작하고, didUpdateWidget을 사용하여 부모로부터 전달받는 `userId`가 변경되었을 때 데이터를 다시 로드하도록 처리했습니다. FutureBuilder를 사용하면 비동기 작업의 상태에 따라 UI를 쉽게 구성할 수 있습니다.
사례 2: 애니메이션 컨트롤러 관리
애니메이션은 대표적인 상태 변화입니다. AnimationController는 리소스를 사용하므로 반드시 dispose 해주어야 합니다.
class FadingLogo extends StatefulWidget {
const FadingLogo({Key? key}) : super(key: key);
@override
_FadingLogoState createState() => _FadingLogoState();
}
// SingleTickerProviderStateMixin은 애니메이션을 위한 Ticker를 제공한다.
class _FadingLogoState extends State<FadingLogo> with SingleTickerProviderStateMixin {
late AnimationController _controller;
late Animation<double> _animation;
@override
void initState() {
super.initState();
_controller = AnimationController(
duration: const Duration(seconds: 2),
vsync: this, // vsync에 this를 전달하기 위해 Mixin이 필요
);
_animation = CurvedAnimation(parent: _controller, curve: Curves.easeIn);
_controller.forward();
}
@override
void dispose() {
_controller.dispose(); // 컨트롤러를 반드시 해제해야 한다.
super.dispose();
}
@override
Widget build(BuildContext context) {
return FadeTransition(
opacity: _animation,
child: const FlutterLogo(size: 100.0),
);
}
}
initState에서 AnimationController를 생성하고 초기화하며, dispose에서 컨트롤러를 해제하여 애니메이션 관련 리소스 누수를 방지합니다.
결론: 생명주기 이해의 중요성
플러터 위젯의 생명주기는 단순히 순서에 따라 호출되는 메서드들의 목록이 아닙니다. 이는 플러터 프레임워크가 어떻게 효율적으로 UI를 구성하고 상태를 관리하는지에 대한 근본적인 원리를 담고 있습니다. StatelessWidget의 단순함과 StatefulWidget의 체계적인 상태 관리 흐름을 이해하는 것은 플러터 개발의 기본기를 다지는 것과 같습니다.
생명주기의 각 단계를 올바르게 활용하면 다음과 같은 이점을 얻을 수 있습니다.
- 성능 최적화:
initState나didChangeDependencies에서 무거운 초기화 작업을 수행하고,build메서드는 가볍게 유지하여 불필요한 리빌드 비용을 줄일 수 있습니다. - 안정성 확보:
dispose에서 리소스를 철저히 해제하여 메모리 누수를 방지하고,mounted프로퍼티를 확인하여 위젯이 소멸된 후 발생하는 에러를 예방할 수 있습니다. - 예측 가능한 코드 작성: 상태 초기화, 데이터 로딩, 리소스 해제 등 특정 작업을 수행해야 할 정확한 위치를 알게 되어 코드의 구조가 명확해지고 유지보수가 용이해집니다.
결론적으로, 위젯 생명주기에 대한 깊은 이해는 플러터 개발자가 반드시 갖추어야 할 핵심 역량입니다. 이를 통해 단순한 기능 구현을 넘어, 사용자에게 쾌적한 경험을 제공하는 견고하고 성능 좋은 애플리케이션을 만들어 나갈 수 있을 것입니다.
0 개의 댓글:
Post a Comment