1. Android App Architecture 개요

면접을 압두고, 앱 아키텍처에 대해 다시한번 공부해야겠다 생각하여 작성한다. 

참고는 물론 안드로이드 개발자 문서.

 

모바일 앱 사용자 환경

Android App component: Activity, Fragment, Service, Api, broadcast receiver 등 여러 앱 구성 요소가 포함된다.

-> 이것들을 menifest에서 선언하며 OS에서는 상기 파일들을 사용해 전반적인 사용자 경험에 앱을 통합한다.

 

환경조건: 

1. 사용자는 짧은 시간 내에 여러 앱과 상호작용하는 경우가 있다. -> 즉, 헤비유저같은..?

2. 휴대기기는 리소스가 제한되어 있으므로, 운영체제에서 새로운 앱을 위한 공간을 확보하도록 언제든지 일부 앱 프로세스를 종료해야할 수 있다.

 

 이러한 이벤트는 직접 제어할 수 없기 때문에 앱 구성요소에 애플리케이션 데이터나 상태를 저장해서는 안 되며 앱 구성요소가 서로 종속되면 안 됩니다.

 

일반 아키텍처 원칙

Android 앱은 크기가 커지기 때문에 앱을 확장하고 앱의 견고성을 높이며 앱을 더 쉽게 테스트 할 수 있도록 아키텍처를 정의해야한다.

앱 아키텍처는 앱의 부분과 그 각 부분에 필요한 기능 간의 경계를 정의한다.

준수해야 할 특정원칙은 다음과 같다.

 

1. 관심사 분리

Activity 또는 Fragment에 모든 코드를 작성하는건 굉장히 큰 실수. 이러한 UI 기반 클래스는 UI 및 운영체제 상호작용을 처리하는 로직만 포함

2. 데이터 모델에서 UI 도출하기

데이터 모델이란 앱의 데이터를 나타내며, 앱의 UI 요소 및 기타 구성요소로부터 독립되어 있다. 즉, 이들은 UI 및 앱 구성요소 수명주기와는 관련이 없다. 하지만, OS가 메모리에서 앱의 프로세스를 삭제하기로 결정하면 데이터 모델도 삭제된다.

 

이상적인 지속 모델이 중요한 이유

 -> Android OS에서 리소스를 확보하기 위해 앱을 제거해도 사용자 데이터가 삭제되지 않는다.

 -> 네트워크 연결이 취약하거나 연결되어 있지 않아도 앱이 계속 작동한다.

 

권장 앱 아키텍처

UI Layer

UI Layer(또는 프레젠테이션 레이어)의 역할은 화면에 어플리케이션 데이터를 표시하는 것이다.

사용자 상호작용(버튼 액션) 또는 외부 입력(네트워크 응답)으로 인해 데이터가 변할 때마다 변경사항을 반영하도록 UI가 업데이트 되어야 한다.

UI 레이어는 다음 두 가지로 구성된다.

1. 화면에 데이터를 렌더링하는 UI 요소, 이러한 요소는 뷰 또는 Jetpack Compose 함수를 사용하여 빌드할 수 있다.

2. 데이터를 보유하고 이를 UI에 노출하며 로직을 처리하는 상태 홀더(ex: ViewModel)

Data Layer

앱의 데이터 레이어에는 비즈니스 로직이 포함되어 있다. 비즈니스 로직은 앱에 가치를 부여하는 요소로, 앱의 데이터 생성, 저장, 변경 방식을 결정하는 규칙으로 구성된다.

데이터 레이어는 각각 0개부터 여러 개의 데이터 소스를 포함할 수 있는 저장소로 구성된다. 앱에서 처리하는 다양한 유형의 데이터별로 저장소 클래스를 만들어야 한다.

예) 영화 관련 데이터에는 MoviesRepository Class, 결제 관련 데이터에는 PaymentRepository 클래스를 만들 수 있다.

 

저장소 클래스에서 담당하는 작업은 다음과 같다.

1. 앱의 나머지 부분에 데이터 노출

2. 데이터 변경사항을 한 곳에 집중

3. 여러 데이터 소스 간의 충돌 해결

4. 앱의 나머지 부분에서 데이터 소스 추상화

5. 비즈니스 로직 포함

각 데이터 소스 클래스는 파일, 네트워크 소스, 로컬 데이터베이스와 같은 하나의 데이터 소스만 사용해야 한다. 데이터 소스 클래스는 데이터 작업을 위해 어플리케이션과 시스템 간의 가교 역할을 한다.

 

Domain Layer(Optional)

Domain Layer는 복잡한 비즈니스 로직, 또는 여러 ViewModel에서 재사용되는 간단한 비즈니스 로직의 캡슐화를 담당한다. 모든 앱에 이러한 요구사항이 있는 것이 아니므로 이 레이어는 선택사항이다. 따라서 복잡성을 처리하거나 재사용성을 선호하는 등 필요한 경우에만 사용.

 

구성요소 간 종속성 관리

특정 클래스의 종속 항목을 수집하는 데 다음 디자인 패턴 중 하나를 사용할 수 있다.

-> 종속 항목 주입(DI): 종속 항목 주입을 사용하면 클래스가 자신의 종속 항목을 구성할 필요 없이 종속 항목을 정의할 수 있다.

-> 서비스 로케이터: 서비스 로케이터 패턴은 클래스가 자신의 종속 항목을 구성하는 대신 종속 항목을 가져올 수 있는 레지스트리를 제공.

*이 패턴은 코드를 중복학나 복잡성을 추가하지 않아도 종속 항목을 관리하기 위한 명확한 패턴을 제공하므로 코드를 확장할 수 있다.

또한 이러한 패턴을 사용하면 테스트와 프로덕션 간에 신속하게 전환할 수 있다.

 

종속 항목 삽입 패턴을 따르고 Android 앱에서 Hilt 라이브러리를 사용하는 것이 좋다.

-> Hilt는 종속 항목 트리를 따라 이동하여 객체를 자동으로 구성하고 종속 항목의 컴파일 시간을 보장하며 Android 프레임워크 클래스의 종속 항목 컨테이너를 만든다.