Guide to app architecture

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

안드로이드 공식문서의 앱 아키텍처 가이드에 제가 이해한 내용을 주석 다는 느낌으로 덧붙여 작성했습니다.

이상한게 한글 번역본은 번역이 이상한 것도 있고 아예 빼먹은 것도 있고 해서 한글판 영문판 둘 다 보면서 작성했습니다..

모바일 앱 사용자 환경

https://medium.com/@Abderraouf/understand-android-basics-part-1-application-activity-and-lifecycle-b559bb1e40e

일반적인 Android 앱에는 활동, 프래그먼트, 서비스, 콘텐츠 제공업체, broadcast receiver를 비롯하여 여러 앱 구성요소가 포함됩니다. 개발자는 앱 매니페스트에서 이러한 앱 구성요소 대부분을 선언하며, Android OS는 이 파일을 사용하여 기기의 전반적인 사용자 경험에 앱을 통합하는 방법을 결정합니다. 일반적인 Android 앱은 여러 구성요소를 포함할 수 있고, 사용자는 짧은 시간 내에 여러 앱과 상호작용할 때도 많다는 점을 고려하면, 앱은 사용자 중심의 다양한 워크플로 및 작업에 맞게 조정될 수 있어야 합니다.

일반적으로 안드로이드 앱은 Activity, Service, Content Provider, Broadcast Receiver 같은 앱 구성 요소( = 4대 컴포넌트)의 조합으로 이루어져, 대부분 앱 매니페스트(AndroidManifest.xml)에 선언되어 사용됩니다.

 

안드로이드 OS는 이 매니페스트 파일을 통해 패키지명, 구성 요소와 실행 조건, 장치 또는 다른 구성 요소와의 상호작용을 위한 권한, 앱에 필요한 HW/SW 기능 등 애플리케이션 실행을 위한 필수 정보를 확인하고, 어떻게 디바이스에 이를 통합할지 결정하게 됩니다.

 

일반적으로 사용자는 하나의 앱만 사용하지 않고, 짧은 시간 내에 여러 앱을 사용하는 경우가 많습니다.

(유튜브를 보다가 크롬을 켜 검색을 한다던지, 카메라로 사진을 찍고 편집을 위해 갤러리에 들어간다던지 등등)

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

 

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

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

 

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

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

일반 아키텍처 원칙

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

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

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

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

 

좋은 아키텍처 구현을 위해선 몇가지 원칙이 있습니다:

1. 관심사 분리

가장 중요한 원칙입니다. 액티비티나 프래그먼트에 모든 코드를 작성해버리는 경우가 관심사 분리 원칙 위반의 경우라고 볼 수 있겠습니다. 이러한 UI 기반 클래스는 UI 처리 & OS와의 상호작용 로직만 포함해야 합니다. UI 기반 클래스를 최대한 가볍게 유지함으로써, 수명 주기와 관련된 수많은 문제를 피할 수 있고 클래스의 테스트를 쉽게 만들 수 있습니다.

 

액티비티 및 프래그먼트구현은 소유 대상이 아니며 안드로이드 OS와 앱 사이의 계약을 나타내도록 이어주는 클래스일 뿐입니다. (이 부분은 이해가 잘 안되네요)

사용자와의 상호작용이나 메모리 부족 등의 상황에 따라 언제든지 제거될 수 있기 때문에, 만족스러운 UX와 수월한 앱 관리 환경을 위해서는 UI 기반 클래스에 대한 종속성은 최소화 해야 합니다.

2. 데이터 모델에 기반한 UI 표시

또다른 중요한 원칙은 UI가 데이터 모델을 토대로 동작해야 한다는 것 입니다. 데이터 모델은 UI 요소와 다른 앱 컴포넌트에 독립적이어야 하는데, 이는 데이터 모델이 UI나 앱 컴포넌트의 수명 주기에 묶여있지 않아야 한다는 것 입니다. 하지만 앱의 프로세스가 종료될 때에는 같이 사라져야 합니다.

 

여기서 데이터 모델은 지속 모델(persistent model)을 권장하는데, 지속 모델은 다음과 같은 장점이 있습니다.

• Android OS에서 리소스를 확보하기 위해 앱을 제거해도 사용자 데이터가 삭제되지 않습니다.
• 네트워크 연결이 취약하거나 연결되어 있지 않아도 앱이 계속 작동합니다

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

 

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

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

유명한? 단일 진실 공급원(SSOT) 원칙입니다. 데이터의 유일한 소유자 역할을 하는 SSOT를 하나 두고, SSOT만이 데이터를 수정하거나 변형할 수 있게 하는 것 입니다. 이를 위해서 SSOT는 불변 형태의 타입으로만 데이터를 노출하고, 데이터 조작을 위해서는 해당하는 함수만을 노출해 이벤트를 처리해야 합니다.

 

이러한 패턴을 통해 다음과 같은 효과를 얻을 수 있습니다.

• 특정 유형의 데이터에 대한 모든 변경사항을 한 곳에 모을 수 있습니다.
• 데이터를 보호해 다른 유형의 데이터 조작을 막습니다.
• 데이터의 변화를 추적하기 쉽게 하여 버그를 찾기 쉽게 합니다.

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

4. 단방향 데이터 흐름

단일 진실 공급원 원칙과 함께 쓰이는 단방향 데이터 흐름 원칙입니다.

 

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

https://developer.android.com/jetpack/guide/ui-layer?hl=ko#udf

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

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

 

단방향 데이터 흐름 구조 구현을 통해

1. 데이터의 일관성을 보장할 수 있고,

2. 에러에 덜 취약해지고, 더 쉽게 디버깅할 수 있으며,

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

권장 앱 아키텍처

https://developer.android.com/topic/architecture?hl=ko#recommended-app-arch

안드로이드에서 권장하는 앱 아키텍처는 Data, Domain, UI 세 가지 레이어로 나뉘어집니다.

 

각각의 레이어는 공식문서에서도 별개의 문서로 다룰 정도로 내용이 길어 따로 적도록 하겠습니다.

 

는 다음 기회에 이어서 쓰도록 하겠습니다.

 

좋은 아키텍처의 장점

1. 유지보수가 용이해지고, 애플리케이션의 전체적인 완성도와 안정성이 올라갑니다.

2. 최소한의 코드 충돌로 많은 사람이 같은 코드베이스를 공유해 작업함으로써 애플리케이션을 확장할 수 있게 해줍니다.

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

4. 좋은 아키텍처는 단순한 데이터 타입을 권장하므로 일반적으로 테스트가 쉬워집니다.

5. 잘 정의된 절차와 함께라면 체계적으로 버그를 조사할 수 있습니다.

 

아키텍처에 투자함으로써 유저들은 직접적으로 더 안정적인 앱을 사용할 수 있게 되고, 개발팀이 더 생산적이게 되므로 더 많은 기능을 사용할 수 있게 됩니다. 하지만 아키텍처 도입은 사전 조사를 필요로 합니다.

이에 관한 도움을 얻고 싶다면 https://developer.android.com/quality를 방문해보라고 하네요.

 

오역이나 잘못된 점이 있다면 남겨주면 감사하겠습니다.

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