개발 블로그를 시작하고 첫 글로 ViewModel
에 대해서 공부하는 글을 썼는데, 순서가 잘못되었다는 생각이 들었다.
ViewModel
은 Android에서 제공하는 AAC(Android Architecture Components)의 구성요소 라이브러리 중의 하나이며, 따라서 ViewModel
에 대해서만 알고 끝낼 게 아니라 AAC에 대해서 먼저 알아보고 그 다음 각 AAC의 구성요소들에 대해서 차례대로 알아보기로 했다.
AAC는 안드로이드에서 공식 발표한 유지관리가 쉬운 앱을 디자인하도록 돕는 라이브러리들의 모음이다.
안드로이드에서는 AAC 라이브러리를 기반으로 앱을 디자인할 것을 권장하고 있으며 가이드도 제공하고 있다.
Android 앱에는 Activity, Fragment, Service, Content Provider, Broadcast Receiver 등 다양한 컴포넌트가 포함되며 한 앱에서는 물론 다른 앱과도 짧은 시간 내에 여러 상호작용이 발생할 수 있다.
하지만 휴대기기의 리소스는 제한되어 있으므로 OS에서 언제든지 새로운 앱을 위한 공간 확보를 위해 일부 앱 프로세스를 종료할 수도 있다.
이러한 환경 조건을 고려할 때 앱 컴포넌트는 개별적이고 비순차적으로 실행될 수 있어야 하며 언제든지 사용자나 OS가 앱 컴포넌트를 소멸시킬 수 있다.
이러한 이벤트는 앱에서 직접 제어할 수 없기 때문에 1) 앱 컴포넌트에 애플리케이션 데이터나 상태를 저장해서는 안된다. 또한 2) 앱 컴포넌트가 서로 종속되어도 안된다.
따라서 일반적으로 앱을 설계할때는 위의 해당 조건을 충족시키기 위해 몇가지 원칙을 준수해야한다.
가장 중요한 원칙은 관심사 분리이다. Activity
나 Fragment
같은 UI 기반 클래스로 UI 및 운영체제 상호작용을 처리하는 로직만 포함해야 한다.
그렇지 않을 경우 UI 기반 컴포넌트에서 생명 주기와 관련된 많은 문제가 발생하게 되고 테스트 과정도 복잡해지게 된다.
Activity
및 Fragment
는 Android OS와 앱 사이의 계약을 나타내도록 이어주는 클래스일 뿐. OS는 메모리 부족 등 이유로 언제든지 클래스를 소멸시킬 수 있다. 따라서 이러한 UI 클래스에 대한 의존성은 최소화 해야한다.
데이터 모델은 앱의 데이터를 나타내며 앱의 UI 및 기타 컴포넌트로부터 독립되어 있다. 따라서 생명 주기의 영향을 받지 않지만 OS가 앱의 프로세스를 제거하면 데이터 모델 역시 삭제된다.
-> 따라서 지속적인 모델을 사용하는 것이 권장된다.
앱에서 새로운 데이터 유형을 정의할 때는 데이터 유형에 단일 소스 저장소(SSOT)를 할당해야 한다. SSOT를 활용하면 특정 유형 데이터의 변경사항을 일원화할 수 있고 다른 유형으로부터 조작될 수 없도록 데이터가 보호되며 변경사항 추적이 용이하다.
이벤트는 보통 UI -> SSOT -> 데이터 방향으로 흐르며 상태는 반대 방향으로 흐른다. 이러한 패턴은 데이터 일관성을 강화해주고 오류 발생 확률을 줄여주며 디버그하기도 용이하다.
위의 일반 앱 아키텍처 원칙에 따라 다이어그램을 그리면 아래와 같다.
레퍼런스)
안드로이드 아키텍처 구성요소
안드로이드 앱 아키텍처 가이드
안드로이드 AAC(Android Architecture Components)란?