[Flutter] State와 StatefulWidget을 분리한 이유

선행지식(위젯 트리)

플러터는 어떻게 위젯을 렌더링할까? + 발표 영상

 

 

모든 것은 위젯이다.

라기에는 우리 눈에 굉장히 불편한 위젯이 하나 있습니다.

 

StatefulWidget & State

class Some extends StatefulWidget {
  @override
  _SomeState createState() => _SomeState();
}

class _SomeState extends State<Some> {
  
  @override
  Widget build(BuildContext context) {
    return ...;
  }
}

StatefulWidget은 StatelessWidget과는 다른 구조를 가지고 있습니다.

 

createState에서 State를 생성하지만

State는 상속받을 때 제네릭으로 StatefulWidget을 넘기는

굉장히 혼란스러운 크로스 관계를 보이고 있습니다. ㅋㅋㅋㅋ

 

StatefulWidget과 State를 분리한 이유가 도저히 이해 안 가는 사람들도 계실 겁니다.

그리고 StatefulWidget이 State와 분리한다는 사실을 아는 개발자분들은 많지만 정작 왜 분리했는지 아는 개발자는 손에 꼽을 정도입니다.

그래서 오늘은 도대체 왜? StatefulWidget과 State를 분리했는지 그 이유를 설명하겠습니다.

 

 

State는 위젯이야?

플러터를 얘기할 때 나오는 말 중 하나가 "모든 것이 위젯"이라는 말을 꽤 많이 들었습니다.

하지만 State는 위젯이라고 부르기엔 UI상에 노출되지 않고 생명주기를 담당하는 등 좀 특별한 기능을 담당합니다.

 

자 그럼 여기서 State의 역할을 다시 한번 정리해봅시다.

State는 상태 클래스로 StatefulWidget의 생명주기 및 상태를 관리하는 클래스입니다.

 

StatelessWidget 같은 경우에는 생명주기가 없습니다.

있다고 쳐도 build 뿐입니다. 하지만 StatefulWidget은 생명주기가 있습니다.

 

아니, 정확히 말해선 StatefulWidget이 가지고 있는 State가 생명주기를 가지고 있습니다.

위젯은 State 클래스만큼 다양한 생명주기를 가질 수 없습니다.

StatefulWidget 또한 마찬가지로 위젯이기 때문에 생명주기를 State가 관리하도록 역할을 몰아준 것입니다.

 

그래서 State가 위젯이냐 아니냐로 나뉜다면 저는 중간을 선택하겠습니다.

 

 

그래서 분리한 이유가 뭐냐고!!!!

자자 진정하시고 아까 전에 StatefulWidget이 생명주기를 State에 몰아줬다고 얘기했습니다.

하지만 굳이 생명주기를 전해줄 필요가 없다고 느끼실 수 있습니다. 그런데 만약 StatafulWidget이 생명주기를 가지면 어떻게 될까요?

 

맨 위에 선행지식을 보신 분들이라면 아실 텐데 속성 또는 부모 위젯이 바뀌게 되면 StatefulWidget 또한 예외 없이 바꾸어야 합니다.

이 과정에서 위젯이 다시 재생성하는데 StatefulWidget이 생명주기를 가지고 있으면 생명주기를 다시 복구하는데 꽤나 많은 비용이 듭니다.

 

하지만 State가 생명주기를 관리한다면 위젯과 함께 폐기되었다가 재구축하지 않습니다.

또한 State는 폐기되지 않으므로 데이터 변경에 대한 응답으로 필요할 때 언제든지 위젯을 재구성할 수 있습니다.

 

따라서 성능을 위해 State와 StatefulWidget를 분리했다고 말할 수 있습니다.

다시 정리하자면 재구축되는 것은 '위젯'인 StatefulWidget이고 재구축되지 않은 것은 '상태'인 State 클래스입니다.

그래서 State 클래스를 위젯이라고 부르기엔 애매하다고 한 것입니다.