[Flutter] Stateful 위젯이 두 개의 클래스로 나눠진 이유

Flutter 앱을 구성하는 위젯은 Stateful 위젯과 Stateless 위젯으로 구분할 수 있다. 이렇게 구분하는 이유는 효율적인 상태 갱신을 위해서이다. 예를 들어 도움말 페이지는 사용자에 의해 화면이 바뀔 내용이 거의 없이 정적으로 화면을 보여주면 된다. 이런 경우 StatelessWidget 클래스를 상속받아서 위젯을 만든다. 하지만 마이페이지에서 이름을 변경하면 변경된 이름으로 화면이 갱신되어야 할 것이다. 이런 경우 StatefulWiddget을 상속받아서 만든다. 앱이 위젯의 상태를 감시하고 있다가 위젯이 특정 상태가 되면 알맞은 처리를 수행해야 한다. 상태가 연결된 동적인 위젯이 StatefulWidget이다. Stateful 위젯은 계속 상태를 지켜봐야하므로 그만큼 메모리나 CPU 등 자원 소비가 더 많다.

 

Stateless Widget을 상속받아 만드는 위젯은 아래와 같은 틀을 가진다. StatelessWidget을 상속받는(extends) 클래스를 정의하고 그 안에 어떤 위젯을 만들 것인지 작성할 build 함수를 재정의했다. 

class myApp extends StatelessWidget {
  const myApp({super.key});

  @override
  Widget build(BuildContext context) {
    return Container();
  }
}

 

 

반면 Stateful Widget을 상속받을 때의 코드 틀은 아래와 같다. 훨씬 복잡한데, 눈에 보이는 차이점은 class가 2개인 것이다. 

class myApp extends StatefulWidget {
  const myApp({super.key});

  @override
  State<myApp> createState() => _myAppState();
}

class _myAppState extends State<myApp> {
  @override
  Widget build(BuildContext context) {
    return Container();
  }
}

 

Stateful 위젯은 혼자서 화면을 출력할 수 없고 State 클래스가 필요하다. State를 상속받는 _myAppState 클래스를 만들고 그 안에 위젯을 담는다. StatefulWidget 클래스를 상속받는 클래스에서는 위젯의 상태를 생성하는 createState()함수를 재정의해서 호출한다. 이렇게 하면 myApp 클래스가 현재 화면을 계속 주시하다가 상태가 변경되면 이를 감지하고 _myApp 클래스가 화면을 갱신한다. 

 

이렇게 두 개의 클래스로 나누어놓은 이유는 바로 성능 때문이다. StatefulWidget보다 State 클래스가 상대적으로 더 무겁기 때문에 StatefulWidget에서 감시하고 있다가 상태 변경 신호가 오면 State 클래스가 화면을 갱신하도록 구현한다. 만약 StatefulWidget에서 바로 갱신하면 나중에 화면이 종료되어도 할당받은 메모리를 없앨 때까지 오랜 시간이 걸릴 수 있다. 따라서 상태 변경 감시는 StatefulWidget 클래스가 담당하고, 실제 갱신은 State 클래스가 담당하도록 분리해둔 것이다.