[Android] 앱 아키텍처 가이드 (1) - 개요

모바일앱 사용자 환경

일반적인 Android 앱에는 activity, fragment, service, content provider, broadcast receiver를 비롯하여 여러 앱 구성요소가 포함됩니다. 개발자는 앱 매니페스트에서 이러한 앱 구성요소 대부분을 선언하며, Android OS는 이 파일을 사용하여 기기의 전반적인 사용자 경험에 앱을 통합하는 방법을 결정하구요. 일반적인 Android 앱은 여러 구성요소를 포함할 수 있고, 사용자는 짧은 시간 내에 여러 앱과 상호작용할 때가 많습니다. (유튜브를 보다가 크롬을 켜 검색을 한다던지, 카메라로 사진을 찍고 편집을 위해 갤러리에 들어간다던지 등등)

따라서, 앱은 사용자 중심의 다양한 워크플로 및 작업에 맞게 조정될 수 있어야합니다. 

 

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

디바이스의 자원(메모리 등)은 한정되어 있기 때문에, 운영체제는 메모리 부족 등의 상황에 임의로 앱의 프로세스를 종료할 수도 있습니다.

 

이러한 환경 조건을 고려해 볼 때 앱 구성요소는 개별적이고 비순차적으로 실행될 수 있으며, 운영체제나 사용자가 언제든지 앱 구성요소를 제거할 수 있습니다. 이러한 이벤트는 직접 제어할 수 없기 때문에( = 언제 어떻게 일어날지 모름) 앱 구성요소에 애플리케이션 데이터나 상태를 저장해서는 안되며 앱 구성요소가 서로 종속되면 안 됩니다. (메모리 누수 가능성)

 

 

일반 아키텍처 원칙

애플리케이션 데이터와 상태를 저장하는 데 앱 구성요소를 사용할 수 없다면 앱을 대신 어떻게 설계해야 할까요?

 

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

 

앱 아키텍처는 앱의 부분과 그 각 부분에 필요한 기능 간의 경계를 정의합니다. 위에 언급된 요구사항을 충족하려면 몇 가지 특정 원칙을 준수하도록 앱 아키텍처를 설계해야 합니다.

좋은 아키텍처 = 확장성 좋고 견고한 테스트하기 쉬운 구조

 

1. 관심사 분리

따라야 할 가장 중요한 원칙은 관심사 분리입니다. Activity 또는 Fragment에 모든 코드를 작성하는 실수는 흔히 일어납니다. 이러한 UI 기반의 클래스는 UI 및 운영체제 상호작용을 처리하는 로직만 포함해야 합니다. 이러한 클래스를 최대한 가볍게 유지하여 구성요소 수명주기와 관련돤 많은 문제를 피하고 클래스의 테스트를 쉽게 할 수 있습니다.

 

Activity 및 Fragment 구현은 Android OS와 앱 상의 계약을 나타내도록 이어주는 클래스일 뿐입니다. OS는 사용자 상호작용을 기반으로 또는 메모리 부족과 같은 시스템 조건으로 언제든지 클래스를 제거할 수 있습니다. 만족스러운 사용자 환경과 더욱 수월한 앱 관리 환경을 제공하려면 이러한 클래스에 대한 의존성을 최소화하는 것이 좋습니다.

 

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

또 하나의 중요한 원칙은 데이터 모델에서 UI를 도출해야 한다는 것입니다. 데이터 모델은 앱의 데이터를 나타내며, 앱의 UI 요소 및 기타 구성요소로부터 독립되어 있습니다. 즉, 이들은 UI 및 앱 구성요소 수명 주기와는 관련이 없습니다. 하지만 OS가 메모리에서 앱의 프로세스가 종료될 때에는 같이 사라져야 합니다.

가급적 지속적인 모델(persistent model)을 권장합니다.

지속적인 모델이 이상적인 이유는 다음과 같습니다.

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

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

저는 이 지속 모델을 Room, Realm과 같은 로컬 DB에서 받아오는 데이터로 이해했습니다.

데이터 모델 클래스를 기반으로 앱 아키텍처를 구축하면 앱의 테스트 가능성과 견고성이 더 높아집니다.

 

3, 단일 진실 공급원(SSOT, Single source of truth)

앱에서 새로운 데이터 유형을 정의할 때는 데이터 유형에 단일 소스 저장소(SSOT)를 할당해야 합니다.

SSOT는 데이터의 소유자이며, SSOT만 데이터를 수정하거나 변경할 수 있습니다. SSOT는 이를 위해 불변 유형을 사용하여 데이터를 노출하며, 다른 유형이 호출할 수 있는 이벤트를 수신하거나 함수를 노출하여 데이터를 수정합니다.

 

장점

- 특정 유형 데이터의 모든 변경사항을 한곳으로 일원화합니다.

- 다른 유형이 조작할 수 없도록 데이터를 보호합니다.

- 데이터 변경사항을 더 쉽게 추적할 수 있도록 합니다 따라서 버그를 발견하기가 쉬워집니다.

 

오프라인 상태를 지원하는 앱의 경우에는 보통 로컬 DB가 SSOT 역할을 합니다. 몇명의 다른 경우에는 뷰모델이나 심지어 UI도 SSOT가 될 수 있다고 합니다.

 

4. 단방향 데이터 흐름(Unidirectional Data Flow)

단일 소스 저장소 원칙은 단방향 데이터 흐름(UDF) 패턴과 함께 사용됩니다. 

단방향 데이터 흐름(UDF)에서 상태는 한방향으로만 흐릅니다. 그리고 이벤트는 상태의 반대 방향으로 흐릅니다.

위 사진이 안드로이드에서 UDF의 흐름을 잘 보여주고 있는 것 같습니다. 상태(State) 혹은 데이터는 위(SSOT)에서 아래(UI)로 전달되어 표시되고, 이벤트(버튼 클릭 등)는 아래(UI)에서 발생하여 위(SSOT)로 전달됩니다.

이런식으로 이벤트를 전달 받은 SSOT의 노출된 함수는 알맞게 데이터를 조작하고, 또 다시 변경된 데이터를 불변 형태로 노출하여 UI까지 내려 보내게 되는 것입니다.

 

장점

- 데이터 일관성을 보장할 수 있고,

- 에러에 덜 취약해지고, 더 쉽게 디버깅할 수 있습니다.

- SSOT 패턴의 이점을 용이하게 활용할 수 있습니다.

 

 

권장 앱 아키텍처

일반적인 아키텍처 원칙에 따라 각 애플리케이션에는 최소한 다음 두 가지 레이어가 포함되어야 합니다.

UI Layer

- 화면에 애플리케이션 데이터를 표시하는 역할을 합니다.

Data Layer

- 앱의 비즈니스 로직을 포함하고 애플리케이션 데이터를 노출하는 역할을 합니다.

Domain Layer (선택사항)

- UI와 Data Layer간의 상호작용을 간소화하고 재사용하기 위한 역할을 합니다.

일반적인 앱 아키텍처 다이어그램

다이어 그램의 화살표는 클래스 간의 종속성을 나타냅니다. 예를 들어 Domain Layer는 Data Layer 클래스에 종속됩니다.

 

 

아키텍처의 이점

앱에 좋은 아키텍처를 구현하면 다음과 같은 여러 장점이 있습니다.

1. 유지보수가 용이해지고, 애플리케이션의 품질, 안정성이 올라갑니다.

2. 최소한의 코드 충돌로 여러 사람이 같은 코드베이스에 기여할 수 있어 앱을 확장하기에 수월합니다.

3. 아키텍처가 프로젝트에 일관성을 가져오기 때문에 새로 들어온 사람도 쉽고 빠르게 적응할 수 있습니다.

4. 좋은 아키텍처는 단순한 데이터 타입을 권장하므로 디버깅에 수월합니다.

5. 잘정의된 프로세스를 사용하기 때문에 버그를 체계적으로 트래킹할 수 있습니다.

 

아키텍처에 투자하는 것은 사용자에게도 직접적인 영향을 줍니다. 개발팀의 생산성이 높아짐에 따라 애플리케이션의 안정성이 향상되고 더 많은 기능이 적용됩니다. 하지만 아키텍처 도입은 사전 조사를 필요로 합니다.

 

각 계층(UI, Data, Domain) 에 대한 설명은 다음 게시물에 기재하겠습니다.

 

 

출처

About app architecture guide

https://developer.android.com/topic/architecture

앱 아키텍처 가이드  |  Android 개발자  |  Android Developers

https://patrick-dev.tistory.com/58

Guide to app architecture

https://velog.io/@dddooo9/Android-%EC%95%B1-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EA%B0%80%EC%9D%B4%EB%93%9C%EC%9D%98-%EA%B6%8C%EC%9E%A5-%EC%95%B1-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98%EA%B0%80-%EB%B3%80%EA%B2%BD%EB%90%98%EC%97%88%EB%8B%A4

[Android] 앱 아키텍처 가이드의 권장 앱 아키텍처가 변경되었다?!

 

https://developer.android.com/topic/architecture/ui-layer

UI 레이어  |  Android 개발자  |  Android Developers

 

https://developer.android.com/topic/architecture/data-layer

데이터 영역  |  Android 개발자  |  Android Developers

 

About the Domain layer

https://developer.android.com/topic/architecture/domain-layer

도메인 레이어  |  Android 개발자  |  Android Developers