[Android] Fragment의 정의와 필요성, Lifecycle 및 이에 따른 대응.
Intro..
저번 포스팅에 이어 Fragment Lifecycle을 다뤄보려 한다.
프레그먼트란 무엇인지, lifecycle, 대응사항(중요) 순으로 작성해보겠다!
Fragment 란?
이름 뜻 그대로 조각이다.
Activity 위에서만 동작하는 화면이라 생각하면 편하다.
대신, Activity와 마찬가지로 코드, 레이아웃 xml을 작성할 수 있고,
한 Activity 위에 하나 이상의 Fragment 조각이 존재할 수 있다.
뭔가 들어보면 Activity가 할 수 있는 기능인데 굳이 필요한가?? 라고 생각할 수 있지만,
거의 대부분의 프로젝트에서 Fragment를 써먹는걸 보면 필요하니까 쓰는것같다.. 이유가 뭘까??
첫번째로, 가볍기 때문이다.
Activity의 경우 Fragment에 비해 무겁고, 초기화 시간도 많이걸린다.
Framgnet는 더 가볍기 때문에 메모리 효율도 좋다. 가볍기 때문에 Fragment 전환 시 비교적 빠르다.
두번째로, 데이터 공유측면에서 유리하기 때문이다.
일반적으로 여러 Activity는 각각의 프로세스에서 실행되고 있고,
(시스템 관리 중 필요에 따라 달라질 수 있으며)
프로세스는 각각의 메모리를 할당받아 관리되기 때문에, 프로세스간 데이터를 주고받으려면 Intent 라는 객체를 사용해야 한다.
따라서 이러한 방식은 직접 접근하는 방식보다 느릴 수 밖에 없다.
그러나, Fragment는 하나의 프로세스 안에 존재하기 때문에 직접 접근이 가능하여 빠르고 유리하다.
세번째로, 관리가 쉽다.
하나의 Activity에 여러 기능이 필요할 경우 Activity 클레스내에 수십에서 수백줄의 코드가 요구된다.
그러나 하나의 Activity 에 여러 Fragment 를 배치할 경우, 기능별로 코드를 분담해 담을 수 있으며 이는 가독성 및 코드 재사용성이 올라가고 관심사를 분리시켜 의존성을 줄이고 독립성을 키우게 된다.
추가적으로, 모든 Fragment는 (부모)Activity의 생명주기를 따라가기 때문에,
맘에 안들어 Activity를 초기화 시키면, 그 위에있는 프레그먼트들이 몽땅 따라서 초기화된다. 훨씬 관리가 쉽다.
그렇다면 단점은? 비동기 문제가 발생할 수 있고, Activity의 생명주기를 고려하며 Fragment 생명주기를 고려해야하기 때문에 복잡하다.
Fragment Lifecycle
프래그먼트는 왼쪽 사진과 같이 정해진 생명주기에 따라 움직인다. (같은사진입니다)
onAttact
- 나와있진 않지만 가장 먼저 진행되는 단계다.
- 프래그먼트가 호스트 액티비티에 attach되는 단계.
onCreate
- Fragment가 생성된 단계 / FragmentManager에 의해 add 됐을때 도달하는 단계.
- View가 생성되지 않았기에 View관련 작업 두기에는
부적절 - onSaveInstanceState
- 세로, 가로 모드 변환 시에도 onCreate 함수가 호출됨.
이때 프래그먼트가 초기화 됨에 따라 값들이 전부 초기화되기 때문에, 값을 유지하고싶을 경우 savedInstanceState 를 활용할 수 있음.
(화면 회전시에 호출되는 오버라이드 함수임)
⇒ 그치만 이 기능은 Bitmap이나 대량 데이터에는 적합하지 않고, 적은 데이터에 적합
onCreateView
- view를 inflater하여 초기화, 생성하는 단계.
onViewCreated
- 완전한 View 생성을 보장해주는 단계.
- onCreateView에서 정상적으로 View 객체가 반환됐을 때 도달하는 단계로, View 초기값 설정, 리스너 설정, LiveData 옵저빙, RecyclerView나 ViewPager2에 사용될 adapter 세팅 등을 이곳에서 하는것이 더 안전함.
onViewStateRestored
- 저장해둔 상태 값등을 불러옴
- View lifecycle owner는 이때 initlalized에서 Created로 변환해줌
onStart
- Fragment가 사용자에게 보여질 수 있을 때 호출
- Fragment의 child FragmentManager를 통해 FragmentTransaction을 안전 수행
- View lifecycle owner는 이때 STARTED로 변환해줌
onResume
- Fragment가 보이는 상태에서 Animator, Transition 효과가 종료되고, 프래그먼트와 사용자가 상호작용할 수 있을 때 호출되는 단계.
- 즉 사용자와 프래그먼트가 상호작용하기 적절한 상태.
- 반대로 이 단계에가 아니라면 입력 시도나 포커스 설정등을 하면 안된다는것을 의미
onPause
- 사용자가 Fragment 를 떠나기 시작했으나 Fragment는 여전히 Visible일 때 호출되는 단계
onStop
- 더이상 화면에 보여지지 않는 단계
- 부모 액티비티나 프래그먼트가 중단 or 상태 저장할때 호출됨
- 여기까지 Fragment Transaction을 안전히 수행할 수 있는 마지막 지점
onSaveInstanceState
- 값을 저장하는 곳
- 화면의 회전, home 버튼을 눌러 밖으로 나간경우에 호출됨
onDestroyView
- 모든 exit animation, transition이 완료되고 Fragment가 화면으로부터 벗어났을 경우 호출
- 이 시점에서는 가비지 컬렉터에 의해 수거될 수 있도록 Fragment View에 대한 모든 참조가 제거되어야 함 (메모리누수)
onDestroy
- Fragment 가 제거되거나, FragmentManager 가 destory 됐을 때 해당 함수 호출.
onDetach
- 가장 마지막 단계
Fragment Lifecycle 에 따른 고려사항 (중요!)
case 1 : First Fragment 위에 Seconde fragment가 올라가는(Add) 경우.
First Fragment가 onResume 된 상태에서 새 프래그먼트가 올라감
case 2 : First Fragment 에서 third fragment로 바뀌는 (replace) 경우. (addToBackStack : true)
Frist Fragment 가 onResume 상태에서 secondeFragment를 replace 함수 호출 후,
First onPause → stop까지 진행,
Seconde가 onstart 까지 진행
first 의 onDestroyView 가 호출된 후, seconde onResume 실행되며 대기.
case 3 : First Fragment 에서 seconde fragment로 replace 하는 경우. (addToBackStack : false)
case 2와 같지만, First의 onDestroyView, onDestory, onDetach까지 진행된 후
seconde onResume 됨
case 4 : home 버튼을 눌러 빠져나간경우
onResume 까지 동작된 후,
onPause, onStop, onSaveInstanceState 까지 간 후 대기함
만약 휴대폰 메모리가 부족할 경우 detroy될수도있음
case 5 : ViewBinding을 사용한 경우
Fragment 전환 시, Add나 Replace Back Stack 인 경우
사용된 ViewBinding 또한 메모리에 올라가있는 상태로 Back Stack에 들어간다.
이는 분명한 메모리 누수이기 때문에 binding을 null로 비워줘야 한다.
학부생 레벨에서 쓴 글로, 다소 부족한 부분이 있을 수 있으니 친절한 피드백을 매우 환영합니다.