앱 아키텍처 가이드 | Android 개발자 | Android Developers
앱 아키텍처 가이드 - 권장 아키텍처
일반적인 Android 앱에는 Activity, Fragment, Service, Content Provider, BroadCast Receiver를 비롯해 여러 앱 구성요소가 포함된다. 메니페스트에서 이런 앱 구성요소를 선언하여 Android OS에서 이 파일을 사용하여 유저 환경에 앱을 통합하는 방법을 결정한다.
모바일 디바이스는 리소스가 제한되어 있으므로, OS에서 새로운 앱을 위한 공간을 확보하도록 언제든지 일부 앱 프로세스를 종료해야 할 수 있다.
이러한 환경 조건으로 앱 구성요소는 개별적이고 비순차적으로 실행될 수 있으며, OS나 사용자가 언제든지 앱 구성요소를 제거할 수 있다. 이러한 이벤트는 직접 제어가 불가능하기 때문에 앱 구성요소에 데이터나 상태를 저장해서는 안되고, 앱 구성요소가 서로 종속되면 안된다.
데이터와 상태를 저장하는 데 앱 구성요소를 사용할 수 없다면 어떻게 설계해야할까?
앱은 크기가 커지기 때문에 앱을 확장하고 앱의 견고성을 높이며 더 쉽게 테스트할 수 있도록 아키텍처를 정의하는게 중요하다.
앱 아키텍처는 앱의 부분과 각 부분에 필요한 기능 간 경계(layer)를 정의한다.
Activity나 Fragment에 모든 코드를 작성하는 실수는 흔히 일어난다. (불과 1~2년전엔 그랬다.) 이러한 UI 기반의 클래스는 UI 및 OS 상호작용을 처리해야하는 로직만 포함해야 한다. 이러한 클래스를 최대한 가볍게 유지하여 구성요소 수명 주기와 관련된 많은 문제를 피하고, 클래스의 테스트 가능성을 개선할 수 있다.
OS는 유저 상호작용을 기반으로 메모리 부족과 같은 시스템 조건으로 인해 언제든지 클래스를 제거할 수 있다. 더욱 수월한 앱 관리 환경을 제공하려면 클래스에 대한 의존성을 최소화하는 것이 좋다.
UI뿐만 아니라 해당 영역에 대해서 관심사 분리를 해야한다.
데이터 모델은 앱의 데이터를 나타낸다. → 서버의 Response나 Room의 결과 값.
이들은 앱의 UI요소 및 기타 구성요소와 독립되어 있다.
즉, 이들은 UI 및 앱 구성요소 수명 주기와는 관련이 없다. 하지만 OS에서 앱의 프로세스를 삭제하기로 결정하면 여전히 삭제된다.
지속적인 모델을 사용하자!