안드로이드에 관해 확실하게 알기 위해 정리하는 글!
안드로이드 마스터 돼야징😆
앱 아키텍처 가이드
앱 아키텍처 설계는 앱을 강력하고 테스트 및 유지관리가 가능하도록 하는 데 중요한 고려사항이다.
모바일 앱 사용자 환경
Android 앱은 Activity, Fragment, Content Provider, Broadcast Receiver를 비롯해 여러 앱 구성요소가 포함된다.
Menifest에서 이러한 앱 구성요소 대부분을 설정한다.
그리고 휴대기기는 리소스가 제한되어 있기 때문에 특정 앱을 실행시키기 위해 일부 앱 프로세스를 종료해야 할 수도 있다.
앱의 구성요소는 개별적이고 비순차적으로 실행될 수 있으며, 운영체제나 사용자나 언제든지 앱 구성요소를 소멸시킬 수 있다. 이러한 이벤트는 직접 제어할 수 없기 때문에 앱 구성요소에 앱 데이터나 상태를 저장해서는 안되고 앱 구성요소가 서로 종속되면 안된다.
일반 아키텍처 원칙 4가지
안드로이드 앱을 확장하고 앱의 견고성을 높이며 앱을 더 쉽게 테스트할 수 있도록 아키텍처를 정의하는 것이 중요하다.
앱 아키텍처는 앱의 부분과 그 각 부분에 필요한 기능 간의 경계를 정의한다. (앱이 기능 별로 잘 나누어져야 하는 것)
위의 요구사항을 충족하려면 4가지 원칙을 준수하도록 앱 아키텍처를 설계해야 한다.
관심사 분리
4가지 원칙 중 가장 중요한 원칙이 관심사 분리이다.
Activity나 Fragment에서 모든 코드를 작성하는 것은 누구나 흔히 하는 실수다. (나도 대학생 때 처음으로 앱 개발하면서 했던 실수..ㅎㅎ)
UI 기반의 클래스는 UI 및 OS 상호작용을 처리하는 로직만 포함해야 한다.
최대한 가볍게 유지해 구성요소 수명 주기와 관련된 많은 문제를 피하고 테스트 가능성을 개선할 수 있다.
OS는 사용자 상호작용을 기반으로 또는 메모리 부족과 같은 시스템 조건으로 인해 언제든지 클래스를 소멸시킬 수 있다.
만족스러운 사용자 환경과 더욱 수월한 앱 관리 환경을 제공하려면 이러한 클래스에 대한 의존성을 최소화하는 것이 좋다.
데이터 모델에서 UI 도출하기
데이터 모델에서 UI를 도출해야 한다.
데이터 모델은 앱의 데이터를 나타내며, 앱의 UI 요소 및 기타 구성요소로부터 독립되어있다.
즉, UI 및 앱 구성요소 수명 주기와는 관련이 없다!
데이터 모델 클래스를 기반으로 앱 아키텍처를 구축하면 앱의 테스트 가능성과 견고성이 더 높아진다.
그리고 가급적 지속적인 모델을 권장한다.
이유
- Android OS에서 리소스를 확보하기 위해 앱을 제거해도 사용자 데이터가 삭제되지 않는다.
- 네트워크 연결이 취약하거나 연결되어 있지 않아도 앱이 계속 작동한다.
단일 소스 저장소
앱에서 새로운 데이터 유형을 정의할 때는 데이터 유형에 단일 소스 저장소(SSOT, single source of truth)를 할당해야 한다.
장점
- 특정 유형 데이터의 모든 변경사항을 한곳으로 일원화한다.
- 다른 유형이 조작할 수 없도록 데이터를 보호한다.
- 데이터 변경사항을 더 쉽게 추적할 수 있도록 합니다. 따라서 버그를 발견하기가 쉬워진다.
쉽게 말하자면 데이터를 하나의 공간에 저장하고 가져와야 한다는 것이다.
단방향 데이터 흐름
SSOT는 단방향 데이터 흐름(UDF, Undirectional Data Flow) 패턴과 함께 사용된다.
UDF에서 상태는 한 방향으로만 흐르고 데이터를 수정하는 이벤트는 반대 방향으로 흐른다.
즉, 데이터는 DataSource에서 UI로 흐르고 사용자 이벤트는 UI에서 SSOT로 흐른다.
ViewModel을 사용해 단방향 데이터 흐름을 구현할 수 있다.
ViewModel -> (state) -> Activity
Activity -> (event) -> ViewModel
권장 앱 아키텍처
일반적인 아키텍처 원칙에 따라 각 애플리케이션에서는 최소한 두 가지 레이어가 포함되어야 한다.
- 화면에 애플리케이션 데이터를 표시하는 UI 레이어
- 앱의 비즈니즈 로직을 포함하고 애플리케이션 데이터를 노출하는 데이터 레이어
UI와 데이터 레이어 간의 상호작용을 간소화하고 재사용하기 위해 도메인 레이어를 추가할 수도 있다.
최신 앱 아키텍처
- 반응형 및 계층형 아키텍처
- 앱의 모든 레이어에서의 단방향 데이터 흐름(UDF)
- 상태 홀더가 있는 UI 레이어로 UI의 복잡성 관리
- 코루틴 및 흐름
- 종속 항목 삽입 권장사항
UI 레이어
UI 레이어는 화면에 데이터를 표시한다.
사용자 상호작용(ex. 버튼 누르기) 또는 외부 입력(ex. 네트워크 응답)으로 인해 데이터가 변할 때마다 변경사항을 반영하도록 UI가 업데이트되어야 한다.
구성 요소
- 화면에 데이터를 렌더링하는 UI 요소 -> 뷰 또는 Jeppack Compose 함수를 사용해 빌드할 수 있다.
- 데이터를 보유하고 이를 UI에 노출하며 로직을 처리하는 상태 홀더 (ex. ViewModel)
데이터 레이어
데이터 레이어에는 비즈니즈 로직이 포함되어 있다.
앱의 데이터 생성, 저장, 변경 방식을 결정하는 규칙으로 구성된다.
앱에서 처리하는 다양한 유형의 데이터 별로 저장소 클래스를 만들어야 한다.
Repository에서 담당하는 작업
- 앱의 나머지 부분에 데이터 노출
- 데이터 변경사항을 한 곳에 집중
- 여러 데이터 소스 간의 충돌 해결
- 앱의 나머지 부분에서 데이터 소스 추상화
- 비즈니스 로직 포함
각 데이터 소스 클래스는 파일, 네트워크 소스, 로컬 데이터베이스와 같은 하나의 데이터 소스만 사용해야 한다. 데이터 소스 클래스는 데이터 작업을 위해 애플리케이션과 시스템 간의 가교 역할을 한다.
도메인 레이어
도메인 레이어는 UI 레이어와 데이터 레이어 사이에 있는 선택적 레이어이다.
복잡한 비즈니스 로직이나 여러 ViewModel에서 재사용되는 간단한 비즈니스 로직의 캡슐화를 담당한다.
선택적 레이어이기 때문에 복잡성을 처리하거나 재사용성을 선호하는 등 필요한 경우에만 사용해야 한다.
장점
- 코드 중복을 방지
- 도메인 레이어 클래스를 사용하는 클래스의 가독성을 개선
- 앱의 테스트 가능성을 높임
- 책임을 분할하여 대형 클래스를 방지
구성요소 간 종속 항목 관리
앱의 클래스는 올바른 작동을 위해 다른 클래스에 종속된다.
종속 항목 관리를 위해 DI 주입과 서비스 로케이터 패턴을 사용할 수 있다.
이 패턴은 코드를 중복하거나 복잡성을 추가하지 않아도 종속 항목을 관리하기 위한 명확한 패턴을 제공하므로 코드를 확장할 수 있다.
일반 권장사항
- 앱 구성요소에 데이터를 저장한다.
- Android 클래스의 종속 항목을 줄인다.
- 앱의 다양한 모듈 간 책임이 잘 덩의된 경계를 만든다.
- 각 모듈에서 가능하면 적게 노출한다.
- 다른 앱과 차별되도록 앱의 고유한 핵심에 초점을 맞춘다.
- 앱의 각 부분을 독립적으로 테스트하는 방법을 고려한다.
- 유형은 동시 실행 정책을 담당한다.
- 가능한 한 관련성이 높은 최신 데이터를 보존한다.
참조
