아래 이미지는 onAttach 이후 onDetach 사이의 라이프사이클이다.
onAttach : 프래그먼트가 매니저에 추가되고, 호스트 액티비티에 연결될 때 호출됨. 이때부터 findFragmentById등으로 프래그먼트를 반환할 수 있는 시점이 됨. 특이점으로 파라미터로 컨텍스트를 넘겨줌. 호스트 액티비티의 컨텍스트임
onCreate : 프래그먼트의 초기 생성을 수행하나, 레이아웃은 여기서 하지 않음
onCreateView : 프래그먼트의 레이아웃을 인플레이트하게 됨.
onViewCreated : onActivityCreated는 deprecated됨. view관련 초기화는 여기서 해야함. 즉 바인딩까진 그렇다 치고, 바인딩으로 부터 연결하는동작등은 여기서 초기화를 해야함
- 이 콜백의 호출 시점부터, view의 초기값을 설정, livedata observing, 어댑터 세팅등 을 하는것이 안전하다.
onViewStateRestored : 저장해둔 모든 state값이 프래그먼트 뷰 계층구조에 복원되었을때 호출됨. 따라서 여기서부터는 체크박스 위젯이 현재 체크되어있는지등 각 뷰의 상태값을 체크할 수 있음.
- viewLifecycleOwner는 이때 INITIALIZED에서 CREATED로 변경됨
onStart : 프래그먼트가 사용자에게 보여질 수 있을 때 호출됨. 프래그먼트의 childFragmentManager를 통해 트랜잭션을 안전하게 수행할 수 있다.
onResume : 프래그먼트가 사용자와 상호작용할 수 있을때 호출됨. 이시점에서 입력이나, 포커스 설정등을 할 수 잇음
onPause : 사용자가 프래그먼트를 떠나기 시작했지만 아직 visible상태일 때. viewLifecycle이 CREATED상태로 돌아감
onStop : 프래그먼트가 더이상 화면에 보이지 않게 될 때. viewLifecycle은 CREATED 상태로 변하고 콜백이 호출됨. onStop이 onSaveInstanceState보다 먼저 호출됨으로써 프래그먼트 트랜잭션을 안전하게 수행할 수 있는 마지막 지점
onSaveInstanceState : 즉 여기서부터는 상태가 저장이되어야 함. 따라서 상태가 변경될 필요가 있는 트랜잭션은 onStop에서 하는것이 안전하다는 것.
- api 28 기준으로 순서가 바뀜
onDestroyView : 모든 exit animation과 trainsition이 완료되고, 프래그먼트가 화면에서 벗어났을 경우, viewLifecycle은 DESTROYED 상태가되고 콜백이 호출됨. 해당시점에는 GC에 의해 수거될 수 있도록 뷰에대한 모든 참조가 제거되어야 한다.
onDestroy : 라이프사이클의 끝
onDetach : 액티비티에서 떨어졌을 때에 호출됨
위와같은 프래그먼트 라이프사이클에 따라 프래그먼트가 가지고 있는 viewLifecycleOwner객체는
- onCreateView 콜백이 호출 되기 전에 생성되어 상태를 가지게 되고,
- onDestroyView 콜백의 수행이 끝난 직후 null로 참조가 사라지기 때문에 그 사이에서 이용할 수 있다.
- 따라서 onCreateView에서 view를 인플레이트하고 참조를 만들고,
- onViewCreated에서 뷰에 관련된 초기화 및 옵저버를 등록한다.
- 그리고 onDestroyView에서는 뷰에 관련된 참조를 모두 제거해 주어야 한다. LiveData의 경우 lifeCycleOwner의 상태에 따라 자동으로 옵저버를 삭제한다고 했으므로, lifecycelowner만 잘 넣어주면 되는데
- 이때!!! 프래그먼트의 경우는 중복호출등의 문제를 막기 위해서라도 프래그먼트의 viewLifecycleOwner 객체를 이용해야 한다. 이것이 정확한 뷰의 라이프사이클이기 때문이다.
