라이프 사이클

라이프 사이클을 알아야 하는 이유

라이프 사이클을 모르라도 앱을 만들 수 있다. 하지만 여러가지 문제점을 접하게 될 텐데 어떤 부분에서 문제가 일어났는지 정확히 알 수 없게 된다.

stateless의 경우

constructor가 실행이 되고 build가 실행되는게 끝입니다.

stateful의 경우

constructor가 가장 먼저 실행이 되고 createState, initState, didChangeDependencies가 실행되고 build가 되고 위젯이 없어질때 dispose가 실행됩니다.

 

setstate의 경우 위젯 내에서 state값이 변경될 때 실행이고 그 다음 build가 됩니다.

didUpdateWidget의 경우 부모 위젯에서 업데이트가 발생할 때 실행됩니다.

 

코드를 보면서 이해해 보죠.

StatefulSampleWidget이라는 constructor가 실행이고 의존성을 주입시켜주고 있습니다.

그런 다음 createState가 실행이 되고 상태를 생성해줍니다.

initState를 통해서 초기의 state의 값을 설정을 해줍니다. 이 initstate는 최초 한번만 실행이 됩니다.

initState와 같이 최초로 한번만 실행되며 initState와는 다르게 context에 접근할 수 있어 context에 접근할 수 있는 로직을 여기에 작성하면 된다.

가장 대표적인것이 provider와 device의 해상도를 불러오는 로직입니다.

물론 build 단계에서 사용할 수 있지만 그렇게 되면 다시 build될때마다 호출되기 때문에 성능상 좋지 않아진다.

build는 ui를 구성하는 단계입니다. 가장 많이 호출되는 부분이기 때문에 계산을 하는 부분은 넣지 않는 것이 좋습니다.

didupdatewidget은 다른 함수들과는 달리 이전 상태의 위젯을 받을 수 있습니다. 그래서 그걸 비교해서 변경이 되었는지 변경된 상태에 대한 추가적인 로직을 구현할 수 있습니다.

이걸 확인 해주어봅시다.

부모의 위젯에서 1초마다 value값을 더해주는 로직을 구현했습니다.

statefulsamplewidget에 value를 넘겨줍시다.

statesamplewidget에서는 print를 해주겠습니다.

그렇게 되면

초기의 init state와 didChangewidget이 실행이되고 build된 다음 1초마다 didUpdatewidget과 build가 호출되는 것을 알 수 있습니다.

dispose에서는 사용되었던 것들을 없애줍니다. 대표적으로 text controller나 pagecontroller같은 controller를 dispose 해주어야 합니다.

라이프 사이클을 모르라도 앱을 만들 수 있다. 하지만 여러가지 문제점을 접하게 될 텐데 어떤 부분에서 문제가 일어났는지 정확히 알 수 없게 된다.