StatelessWidget과 StatefulWidget 의 생명주기

StatelessWidget과 StatefulWidget 의 생명주기는 각각 다르기 때문에 적절히 사용하면 성능 향상에 도움이 된다.

 

StatelessWidget Lifecycle

 

StatefulWidget Lifecycle

 

1. Constructor()

• 생성자

 

2. createState()

• Stateful Widget 객체를 생성하면 생성자가 호출되고 이 메서드가 호출된다. Stateful Widget 에서 필수적으로 오버라이드 해야 하는 메서드이다.
• 이 메서드의 역할은 State 객체를 생성하는 일.

 

3. initState()

• State 객체가 생성되면 State 객체의 생성자가 호출된다.
• 처음 한 번만 호출되는 함수이다. 여기서 데이터나 속성값을 초기화 할 수 있다.
• context를 사용 할 수 없다.
• Constructor와 비슷한데 StatefulWidget에서는 Constructor보다 initState에서 더 사용

 

4. didChangeDependencies()

• initState() 다음에 바로 실행되는 메서드.
• 위젯이 의존하는 데이터의 객체가 호출되거나 변경되었을 때 다시 실행됨.(여러번 호출 가능)
• 참조(Dependency)아는 위젯이나 Inherited Widget, Provider가 변경되면 호출된다.
• build()는 항상 이 함수 다음에 호출 된다.
• context를 사용 할 수 있다.

 

*5. dirty - state class의 상태를 말하는 것으로 build()가 실행되어야 하는 상태를 말함 (실제로 사용되거나 하진 않음)

 

6. build()

• build()를 통해서 위젯이 그려진다. State 클래스에서 반드시 오버라이딩 되어야 하는 메서드이다. 예를 들어 버튼을 클릭 할 때나 어떠한 액션을 취할 때 계속 실행되는 함수이다.
• UI를 구현하는 부분.
• 반드시 존재해야하는 부분으로 @override 재정의 대상이고 Widget을 반환해야한다.

 

*7. clean - state class의 상태를 말하는 것으로 build()가 실행된 다음의 상태를 말함 (실제로 사용되거나 하진 않음)

 

*8 setState()

• State 객체의 상태가 변경되었다는 것을 프레임워크에 알리는 용도이다. 따라서 State 객체의 상태가 변경될 때마다 setState() 함수를 통해서 알려야 한다. 그래야만 프레임워크가 build() 함수가 호출할 준비를 한다.
• build함수를 다시 실행시키는 것으로 state class를 dirty 상태로 만드는 역할

 

*9 didUpdateWiget()

• 부모 위젯이 재 빌드되어 위젯이 갱신될 때 호출된다. didUpdateWiget()이 호출된 후에는 항상 build()를 호출한다. 따라서 만약 didUpdateWiget() 내에서 setState() 를 호출하면 build() 중복 호출이 된다.
• 부모 위젯이 재 빌드 되어 Constructor가 실행되는데 createState는 실행되지 않고 기존에 있던 위젯을 가져와서 사용. -> 기존에 생성했던 변수들을 사용가능함

 

10. deactivate()

• 트리에서 State 객체가 제거될 때마다 호출된다.
• 어떤 경우에는 프레임워크가 제거된 State 객체를 트리의 다른 부분에 다시 삽입하기도 한다. 이 경우에는 State 객체가 트리의 새로운 위치에 적응할 수 있는 기회를 주기 위해 build()를 호출한다.
• 거의 사용하지 않고 dispose를 많이 사용함

 

11. dispose()

• 해당 위젯이 위젯트리에서 제거됐을 때 실행된다. 더이상 빌드되지 않는다는 의미.

 

 

reassemble()

• hot reload 를 실행하면 reassemble()이 호출된다. reassemble() 이 호출되면 build()도 호출이 된다.