본 게시글은 Android Developers 공식문서를 번역하여 개인적으로 공부한 자료입니다. 틀린 내용이 있을 수도 있으니 유의바랍니다.
ViewModel 개요
ViewModel 클래스는 lifecycle에 민감한 UI와 관련된 data들을 저장하고 관리하기위해 만들어진 클래스입니다. ViewModel 클래스는 스마트폰을 회전하여도 data들을 유지할 수 있게 도와줍니다.
ViewModel class 가 필요한 이유?
1) 화면을 재구성할 때, 데이터가 소멸되었다가 다시 불러와야한다.
만약 시스템이 종료되거나, 화면을 re-create해야할 때, 예를 들면 스마트폰의 화면을 회전했을 때, 화면에 담겨있던 일시적인 UI 와 관련된 data들은 사라지게 됩니다.
ex) app 화면에 친구목록이 담긴 list 를 띄우는 activity 가 있다고 가정해 봅시다. 이 activity 가 re-created 되어야하는 상황이라면, 생명주기 상 pause->stop->destroy->create->start->resume 의 과정을 거쳐서 새롭게 re-created 된 activity에 친구목록 db의 data를 불러와 list에 다시 fetch 해야 될 것입니다.
단순한 data의 경우 onSaceInstanceState() 메소드와 bundle을 사용하여서 activity가 re-created 되더라도 데이터가 사라지지 않도록 저장할 수 있지만 이런 경우는 아주 작은 양의 데이터에 적합하도록 설계되어 있습니다. (ex-화면 설정 default 값)
2) UI controller에서 비동기식으로 많은 UI 의 data를 갱신해야할 때, 혹은 화면 재구성으로 인해 data를 다시 불러올 때, 작업시간이 오래 걸릴 위험이 있다.
UI controller (activity or fragment)에서 UI에 표시할 데이터를 직접 관리하는 상황에서 화면에서 표시할 UI가 상당히 많다면, UI마다 비동기식으로 데이터를 불러와야 하는 상황에서 작업시간이 많이 걸릴 수 있습니다.
UI controller 은 이런 데이터의 요청, 관리하는 동시에 destroyed 되었을 때에는 메모리가 낭비되지 않도록 신경써야합니다.
이런 관리법은 많은 유지비용을 필요로 합니다. 또 이미 처음에 불러왔던 데이터를 re-created 된 화면에서 재구성을 위해 또 다시 db에 접근해서 data를 불러온다는 것은 자원낭비 입니다.
activity 와 fragment 와 같은 UI controller 는 본질적으로 UI의 data를 표시하고, 사용자와 상호작용을 하고, system 과 소통하는 것을 목적으로 설계되었습니다. 이 과정에서 UI controller 가 UI에 data를 표시하기 위해 db에 접근하거나, network 에 요청하는 책임까지 맡게 되었습니다.
그 결과로 여러 class가 협동하여 작동하는 것이 아닌, 한 UI controller (class) 에 수 많은 역할의 코드가 들어가게 되었고 이런 운영 방식은 유지 보수나 unit test를 굉장히 어렵게 합니다.
이런 이유로, UI controller 가 UI 에 표시할 data 에 대한 ownership 을 분리하는 것이 효율적일 것입니다.
참조
