이번엔 MVVM의 ViewModel에 관한 궁금증을 해결해 볼 예정이다. MVVM에 관한 사항은 해당 글에서 설명한 바가 있다. 잘 모른다면 한 번 읽어보는 것도 좋겠다. MVVM을 안드로이드 문서에서는 Clean Architecture라는 이름으로 소개하고 있다. 그리고 해당 아키텍처를 구현하는데 있어 유용한 라이브러리들을 제공하는데, 이 라이브러리들은 일명 AAC로 불린다. 아무튼 AAC 중에 이름 자체가 Life Cycle인 라이브러리가 존재한다.
MVVM과 ViewModel을 공부하다보면 수명주기 인식에 관한 내용들이 많이 나온다. 하지만 필자는 아! 관리해주는구나^^ 하고 코드몽키스럽게 프로젝트를 진행했다. 이 시간을 통해 반성하고, 공부를 해야겠다는 생각이 들었다. MVVM을 적용해 프로젝트를 진행할 경우가 많을 것 같은데, 생명주기의 관리가 어떻게 이뤄지는 지에 대해 알아두는 것은 필수적이라고 생각했기 때문이다. 심지어 lifecycle는, ViewModel 클래스에도 당당하게 import되어 있다. 대체 어떤 녀석일까 궁금하다.
Life Cycle Library
먼저 Life Cycle 라이브러리는 AAC의 구성요소이기 때문에, Android jectpack의 구성요소이다. 안드로이드 공식문서에 따르면 해당 라이브러리는
액티비티와 프래그먼트 같은 다른 구성요소의 수명 주기 상태 변경에 따라 작업을 실행합니다. 이러한 구성요소를 사용하면 잘 구성된 경량의 코드를 만들고 더욱 쉽게 유지할 수 있습니다.
androidx.lifecycle 패키지는 수명 주기 인식 구성요소(액티비티나 프래그먼트의 현재 수명 주기 상태를 기반으로 동작을 자동 조정할 수 있는 구성요소)를 빌드할 수 있는 클래스 및 인터페이스를 제공합니다.
라고 되어있다. Life Cycle은 경량화된 코드로 수명주기에 관한 처리를 더욱 쉽게 해준다는 것 같은데, ViewModel은 이와 같은 기능을 간절히 원했을 것이다. ViewModel은 View의 Lifecycle 동안 데이터를 유지시켜 주는 클래스이니까 말이다. 위에서 Life Cycle 라이브러리의 효용성에 대해 언급했다면, 정의에 대한 내용을 읽어보자.
Lifecycle은 액티비티나 프래그먼트와 같은 구성요소의 수명 주기 상태 관련 정보를 포함하며 다른 객체가 이 상태를 관찰할 수 있게 하는 클래스입니다.
Lifecycle은 두 가지 기본 열거(이벤트, 상태)를 사용하여 연결된 구성요소의 수명 주기 상태를 추적합니다.
볼드체를 거를 타선이 없다. 정의는 위의 설명으로 이해했을 것이다. 그렇다면 두 가지 열거를 사용한다고 하는데, 이 열거에 해당하는 이벤트와 상태는 무엇일까?
-
LifeCycle - Event
프레임워크 및 Lifecycle 클래스에서 전달되는 수명 주기 이벤트입니다. 이러한 이벤트는 액티비티와 프래그먼트의 콜백 이벤트에 매핑됩니다.
-
LifeCycle - State
Lifecycle 객체가 추적한 구성요소(Activity/Fragement)의 현재 상태입니다.
클래스는 DefaultLifecycleObserver를 구현하고 onCreate, onStart 등의 상응하는 메서드를 재정의하여 구성요소의 수명 주기 상태를 모니터링할 수 있습니다.
LifeCycle 라이브러리는
- 해당 클래스에 전달되는 수명주기 이벤트와
Activity/Fragment의 현재 상태 정보
를 사용해 Activity/Fragment의 수명주기 상태를 추적한다. - 이런 방식으로 추적한 Activity/Fragment의 수명주기 상태 정보를 다른 객체가 관찰할 수 있게 해주는 클래스이다.
- 본격적으로 들어가보자.
LifeCycleOwner
이거 어디선가 본 적이 있다. 바로 ViewModel과 연결되어 있는 Fragment 클래스에서 말이다.
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
super.onViewCreated(view, savedInstanceState)
myPlateViewModel.plate.observe(viewLifecycleOwner){
//UI 작업
}
}LifeCycleOwner는 클래스에 LifeCycle이 있음을 나타내는 단일 메서드 인터페이스이다. 이 인터페이스는 Fragment 및 AppCompatActivity와 같은 개별 클래스에서 Lifecycle의 소유권을 추출하고 함께 작동하는 구성요소를 작성할 수 있게 한다. 모든 맞춤 애플리케이션 클래스는 LifecycleOwner 인터페이스를 구현할 수 있다.
-> AAC를 통해 "이미 잘 만들어진" viewLifeCycleOwner를 사용하고 있던 것이었다.
오호라. LifeCycle의 소유권을 추출하고 함께 작동하는 구성요소(예를 들면 Listener와 같은)를 작성할 수 있게 해준다고 한다. 위와 같이 ViewModel을 적용한 Fragment에서는 ViewLifeCycleOwner를 사용했는데, 해당 코드에 커서를 갖다 대보면
Get a LifecycleOwner that represents the Fragment's View lifecycle. In most cases, this mirrors the lifecycle of the Fragment itself, but in cases of detached Fragments, the lifecycle of the Fragment can be considerably longer than the lifecycle of the View itself.
해당 프래그먼트의 View LifeCycle을 나타내는 LifeCycleOwner를 가져온다고 한다. ViewModel은 View lifeCycle을 인지한다고 했는데, 이와 맞아 떨어진다. 그리고 viewModel.liveData.observe(viewLifeCycleOwner) 의 코드로 작성이 돼있는데, 해당 ViewModel과 liveData가 View LifeCycle을 관찰하도록 처리해준다는 것이다.
따라서 ViewModel의 liveData는 View의 수명주기를 관찰하고, View가 활성화된 시점에 데이터의 변동이 발생하면 해당 데이터로 하여금, 자동으로 View를 업데이트시켜줄 수 있게 되는 것이다.
ViewModel LifeCycle
안드로이드 공식문서에 따르면 ViewModel엔 수명주기가 존재한다. 앞서 설명했 듯 ViewModel은 Life Cycle을 통해 Activity/Fragment의 수명주기를 인지하고 있다.
위 그림은 화면 전환 이벤트가 발생했을 때의 Activity와 ViewModel의 수명주기에 관한 그림이다. 그리고 ViewModel은 Activity와 연결되어 있다. ViewModel은 해당 Activity의 수명주기를 인지하며 Activity가 폐기(Finished)될 때까지 존재한다고 한다.
이는 정말 중요한데, Activity의 LifeCycle이 아무리 변화해도 ViewModel은 끝까지 활성화돼있다. Activity가 onDestroy - finished 돼서야 cleared되는 것을 확인할 수 있다. 정말 마지막까지 함께하는 것이다.
+) 그렇기 때문에 ViewModel에 Context를 넣으면 안된다고 한다. Activity는 Finish되었는데 ViewModel은 살아남아서 Memory Leak이 발생할 수 있기 때문이라고 한다. 정 Context가 필요한 경우, ViewModel 클래스를 생성할 때 ViewModel의 서브 클래스인 AndroidViewModel 클래스를 상속 받으면 된다고 한다. 이렇게 할 시 Application Context를 이용할 수 있기 때문이다.
