어쩌다 개발자

프래그먼트란?

안드로이드 앱의 사용자 인터페이스(UI) 일부를 나타내는 모듈화된 컴포넌트이다. 라고 하면 확 와닿지 않는다.

내 개인적인 이해를 가지고 예시를 들어 설명을 하자면, 퍼즐과 비슷한 것 같다.

액티비티가 한 폭의 그림이 담긴 큰 틀이라고 한다면, 프래그먼트는 그 그림을 이루는 퍼즐 조각같은거다.

우선 프래그먼트라는 개념이 나오게 된 배경을 알아보자.

예전에는 핸드폰이 나왔을 때 대부분 비슷비슷한 화면이었다. 근데 지금을 보자면 핸드폰 자체도 화면 크기가 굉장히 다양하다. 갤럭시 노트와 아이폰 미니만 비교해봐도 꽤나 큰 차이다. 그런데 폴드니,, 플립이니,, 뭐니 제각각 개성을 갖춘 녀석들이 등장하기도 하고 태블릿, 스마트TV, 스마트워치 등이 등장하면서 다양한 화면 크기에 대응해야하는 시기가 와버린 것이다. 

다양한 화면 크기에 대응하기 위해서는 화면을 동적으로 조절하고 유연하게 대응해야 할 필요가 있다. 이와 더불어 개발 측면에서도 기능을 모듈화시키고 각각 따로 떼어내는 추세이기에 그에 따라 화면도 여러개로 나누어 조합하여서 다양한 레이아웃을 생성할 수 있도록 하는 모듈화와 재사용성을 높일 필요가 있었다. 이러한 요구사항에 부합하도록 도입된 것이 프래그먼트이다.

요새 앱 환경도 웹의 SPA(Single Page Application) 같이 메인 액티비티 1~2개에 여러 개의 프래그먼트를 사용해서 화면을 구현하는 편이라고 한다.

프래그먼트 특징

1. Jetpack Library Navigation / Viewpager 와 같은 아주 유용한 라이브러리들이 프래그먼트로 사용하도록 설계되어서 함께 사용하면 아주 편리하게 화면을 구성할 수 있다.

2. 액티비티 내에서 여러 프래그먼트가 동작할 때, 각 프래그먼트 간에는 직접적인 통신이 가능하다. 이를 통해 모듈 간의 상호작용이 가능하다.

3. 화면을 여러개의 프래그먼트로 나눠서 다양한 레이아웃을 생성 가능하고 여기 저기 쓸 수 있으니 재사용성에도 기여한다. (화면이 작은 디바이스면 프래그먼트 하나 딱 보여주고 화면이 크면 프래그먼트 여러 개 띄어서 보여준다.) + 동적인 UI 업데이트

4. 액티비티는 안드로이드 시스템에서 직접 관리하지만 프래그먼트는 프래그먼트 매니저가 간접적으로 관리한다.

이를 통해 메모리 리소스가 상대적으로 덜 소모된다고 한다.

5. 액티비티안에 종속되지만 자체적인 생명주기를 가지고 있다.

프래그먼트의 생명주기를 왜 이해해야하는가?

이 정도 대충 읽으면 프래그먼트가 대세구만! 하는 느낌이 온다. 그럼 이제 잘 사용하고 싶어진다. 프래그먼트를 잘 사용하려면 프래그먼트의 생명주기를 잘 이해해야한다.

또한, 메모리 누수를 방지하기 위해서 프래그먼트의 각 단계별 상황에서 어떤 적절한 액션을 취해서 대처해야할지 알아야 하기에 잘 이해해놓아야 한다.

메모리 누수(Memory Leak) 란 한정된 자원을 가진 프로그램이 할당한 메모리를 제대로 해제하지 않아 발생하는 현상이다.

즉, 일꾼들에게 작업공간을 주고서 작업이 다 끝났으면 다시 다른 일꾼에게 그 공간을 잘 할당해주어야 하는데 노는 공간이 많이 발생하면서 계속 누적되고 시스템 자원이 낭비되고 결국 성능에 악영향을 끼치는 현상이다.

우리가 객체를 참조하고 더 이상 쓰지 않거나 필요하지 않은 시점에선 적절하게 메모리를 해제시켜야 성능과 안정성을 높일 수 있다. 그런 시점을 알려면? 생명주기 이해 해야한다!

위 그림은 안드로이드 공식 문서에서 제공한 그림이다. 보면 프래그먼트의 자체의 생명주기(왼쪽)와 프래그먼트 뷰의 생명주기를 구분해서 표현한다. 이 둘 주기의 차이점을 잘 파악해두면 메모리 누수나 런타임 오류를 방지할 수 있다.

우선 액티비티 생명주기와의 콜백함수 차이점을 보면 onCreateView() onCreatedView(), onViewStateRestored() 와 onSaveInstanceState(), onDestroyView()가 있다.

차이점만 인지하고 이제 생명주기를 알아보자.

onAttach() & onCreate()

(+내 메모리에 잘 넣기 위해서 조금 각색해보았다. 정확한 표현이 아닐 수 있기에 (?) 표시해두었다.)

Fragment의 압축파일(?) 같은 녀석이 프래그먼트 매니저를 통해서 호스트 액티비티에 attach되고, onAttach() 작업이 완료되면 onCreate()에서 프래그먼트 자체가 압축해제(?) 되어 생성된다.

생명주기 그림을 보면 알겠지만 아직 프래그먼트 뷰 생성 전이므로 뷰와 관련된 작업을 이 메소드에서 진행하는건 적절하지 않다.

한줄 요약

onAttach() -> 프래그먼트가 호스트 액티비티에 attach 된다.

onCreate() -> attach된 프래그먼트 자체가 생성된다.

onCreateView & onViewCreated()

onCreateView에서 프래그먼트 뷰가 초기화되고 완료됨과 동시에 onViewCreated()를 호출하여 완전히 생성된 뷰 객체를 반환한다. onCreateView에서 레이아웃을 inflate 하기에 뷰 객체들을 참조할 수 있지만, 안정적으로 뷰 객체의 생성이 보장이 된 onViewCreated에서 참조하는 것이 안전하다. (+ 여기에서 findViewById, 뷰 바인딩, LiveData 옵저빙, 각종 어댑더 세팅하면 된다.)

이제 슬슬 생명주기를 왜 알아야하는지 감이 오기 시작하죠?? (어디서 어떤 처리를 해야하는지 알겠죠?)

onCreateView() - > 프래그먼트 뷰 초기화 + 뷰 객체 반환

onViewCreated() -> 뷰의 생성 완료를 보장

onViewStateRestored() 

프래그먼트의 상태를 복원할 때 호출된다. 프래그먼트의 뷰 계층 구조와 연관된 상태를 복원하는데 사용된다.

많은 블로그에서 이렇게 설명한다. 사실 이렇게 들으면 초보입장에서는 알아듣기 힘든 것 같다.

우선, 이 콜백메소드는 일반적으로 프래그먼트가 소멸되고 다시 생성될 때 호출된다.

쉽게 이야기하자면, 우리가 앱을 보다가 잠시 떠났다가 들어왔을 때 다 초기화되어있을 수도 있지만 요즘 앱들은 내가 나갔다가 와도 내가 보던 그 화면 위치, 내가 작성하던 텍스트 등 포커싱 아웃 전 내 UI 현재 상태를 유지하고 있다.

그 상태들을 복원시킬 때 쓰이는게 이 메소드다. 

onViewStateRestored()  - > 소멸된 프래그먼트 상태 복원

onStart()

프래그먼트가 사용자에게 보여질 수 있을 때 호출되며 이 때부터 사용자에게 프래그먼트 뷰가 보이게 된다. 이 시점부터 프래그먼트는 자식 프래그먼트매니저를 통해 프래그먼트의 추가, 교체, 제거 등의 작업으로 관리되어진다.

onResume()

액티비티와 마찬가지로 onResume() 부터 사용자와 상호작용할 수 있는 상태이다. 이 때 상호작용에 필요한 작업을 수행하면 된다. 

onPause()

프래그먼트가 일시 중지될 때 호출된다.

onPause()에서는 사용자와의 상호작용이 중단되는 시점에서 필요한 작업을 수행한다.

onStop()

프래그먼트가 사용자에게 더 이상 표시되지 않을 때 호출된다.

onStop()에서는 UI 업데이트 및 리소스 정리와 같은 작업을 수행한다.

onSaveInstanceState()

프래그먼트가 소멸되기 전에 호출되며, 프래그먼트의 현재 상태를 저장하는 데 사용됩니다. 주로 화면 회전이나 다른 구성 변경 시에 발생하는 프로세스의 재시작으로부터 데이터를 보존하고 복원하는 데 활용됩니다. 

onDestroyView()

프래그먼트의 뷰 계층 구조가 소멸될 때 호출됩니다.

onDestroyView()에서는 UI와 관련된 자원을 해제하는 작업을 수행합니다.

onDestroy()

프래그먼트가 소멸될 때 호출됩니다.

onDestroy()에서는 필요한 자원을 해제하고 정리하는 작업을 수행합니다.

onDetach()

프래그먼트가 액티비티에서 분리될 때 호출됩니다.

onDetach()에서는 프래그먼트가 속한 액티비티에 대한 참조를 해제하는 작업을 수행합니다.