안드로이드 앱 아키텍처 (App Architecture)

안드로이드 개발을 공부하면서 항상 고민 하는 것이 어떻게 유지보수가 편하고, 기존 기능을 확장하거나 새로운 기능을 추가할 때 좀더 쉽게 할 수 있는 구조로 앱을 개발하는 방법일 것이다. 

 

그래서 구글에서 권장하는 것이 3가지 Layer로 나누는 앱 아키텍처이다. 구글 사이트에서 권장하는 구조적 패턴을 따름으로써, 코드의 유지 보수성과 확장성을 높일 수 있다.  (링크)

 

앱 아키텍처 설계는 앱이 견고하고 테스트 가능하며 유지 보수가 용이하도록 보장하는 중요한 고려 사항이다.

1. 모바일 앱 사용자 경험 (Mobile app user experiences)

안드로이드 앱은 컴포넌트들(Activity, Fragment, Service, Content Provider, Broadcast Receiver)을 포함하고 있다.

Manifest.xml에 대부분의 앱 컴포넌트들을 선언한다. 

 

모바일 기기는 리소스 제한이 있기 때문에 언제든 OS에서 새로운 프로세스를(앱)을 켜기 위해 기존의 사용되고 있는 프로세스(앱)을 종료시킬 수 있다.

 

이러한 이벤트는 직접 제어할 수 없기 때문에 앱 컴포넌트에 앱 데이터나 상태를 저장해서는 안되고 앱 컴포넌트가 서로 의존하면 안된다. 

 

Activity, Fragment, Service, Content Provider, Broadcast Receiver에 데이터나 상태 저장 X

 

의문점 :

프로세스가 OS가 앱을 종료시킨다면 데이터 보존이 안되는 것은 이해하는데 앱 강제종료와 앱 구성요소간의 종속이 무슨 관계인지 모르겠다.

 

Chat gpt의견으로는 프로세스에서 앱자체를 종료시키는 것이 아니라 앱컴포넌트 하나만 종료 시킬수도 있다고해서 분리가 안된다면 오류 발생이 가능하다고 한다.

 

Chat Gpt 의견 : 종료된 구성 요소의 의존성 문제

• 예를 들어, 액티비티 A가 액티비티 B의 데이터를 참조하고 있는데, 운영 체제가 메모리 확보를 위해 액티비티 B를 종료했다면, 액티비티 A는 필요한 데이터나 상태에 접근할 수 없게 되어 오류가 발생할 수 있습니다.
• 이러한 경우, 앱이 비정상적인 동작을 하거나 **충돌(crash)**할 가능성이 높아집니다.

이런 이유가 아니어도 종속성이야 없는게 좋기 때문에 종속성을 없애는 방향쪽으로 가는게 좋을 것 같다.  (Hilt 사용)

2 일반 아키텍처 원칙 :

안드로이드 앱을 확장할때 견고성을 높이고, 테스트 쉽게 하기 위한 아키텍처를 정의하는 것이 좋다.

데이터와 상태를 저장하는 데 앱 구성요소를 사용할 수 없다면 4가지 원칙을 준수하도록 앱 아키텍처를 설계해야 한다. 

 

2-1 관심사 분리 (Separation of concerns)

나도 그렇고 주니어 개발자들이 하는 실수가 관심사를 분리하지 않고 Activity나 Fragment에 모든 코드를 작성하는 것이다. Activity나 Fragment 같은 UI 기반의 클래스에는 UI와 운영체제와 상호작용하는 로직만 포함해야 한다. 이러한 클래스를 가능한 최대로 가볍게 유지하여 컴포넌트 생명주기와 관련된 문제를 피하고, 테스트에 용이하게 한다. 

 

Activity와 Fragment는 안드로이드 OS와 앱을 이어주는 클래스일 뿐이다. OS는 언제든지 상황에 따라 Activity나 Fragment를 종료시킬수 있다. 만족스러운 사용자 경험을 제공하고 앱 유지보수를 더 쉽게 하기 위해서는 이러한 구성 요소에 대한 의존성을 최소화하는 것이 가장 좋습니다.

 

Activity와 Fragment는 UI & 운영체제 상호작영 로직만 포함

 

2-2 데이터 모델에서 UI 도출하기 (Drive UI from data Model )

또 다른 중요한 원칙은 데이터 모델에서 UI에 사용할 데이터를 가져와야한다. 데이터 모델은 앱의 UI 요소나 다른 구성요소와 독립적이어야 하고, UI 요소나 컴포넌트들의 생명 주기에 독립적이어야 한다. 하지만 OS가 앱 프로세스를 메모리에서 제거하면 여전히 사라질 수 있다.  

 

2-3 단일 소스 저장소

새로운 데이터 타입을 정의할 때는 Single Source of Truth(SSOT)에 정의해야 한다. 단일 소스 저장소는 데이터의 소유자이며, 여기서만 데이터를 수정 및 변경 가능하게 해야한다.

 

이것을 위해서는 SSOT는 val과 같이 불변 유형으로 데이터를 선언하고, 데이터를 수정하기 위해서는 functions을 통해서 이벤트를 받아서 수정하게 한다. (자바에서 캡슐화를 얘기하는 것 같음)

 

2-4 단방향 데이터 흐름

• state 는 모델에서 뷰로 흐름
• event 는 뷰에서 모델로 흐름

 

3. Three Layers

안드로이드 공식 페이지에서는 3가지 Layer들로 관심사를 분리하는 것을 추천 (UI Layer, Domain Layer, Data Layer)

 

Figure 1. Diagram of a typical app architecture.

 

3-1. UI Layer

UI Layer는 화면에 애플리케이션 데이터를 표시한다. 로그인 버튼 클릭과 같은 사용자 상호작용, 네트워크 응답과 같은 외부 입력으로 인해 데이터가 변할 때마다 변경 사항을 반영하도록 UI가 업데이트 되어야한다.

 

UI Layer를 구성하는 2가지 :

• 화면에 데이터를 렌더링하는 UI 요소. 이러한 요소는 Views 또는 Jetpack Compose 함수들을 사용하여 만듭니다.
• 데이터를 보유하고 UI에 노출하며 로직을 처리하는 상태 보유자 (예: ViewModel)

3-2 Data Layer

앱의 Data Layer는 비지니스 로직을 포함한다. 비즈니스 로직은 앱에 가치를 부여하는 것으로, 앱이 데이터를 생성, 저장 및 변경하는 방식을 결정하는 규칙들로 이루어져 있습니다.

 

Data Layer는 각각 0개에서 여러 개의 data sources를 포함할 수 있는 repository로 구성됩니다. 앱에서 처리하는 다른 유형의 데이터에 대해 repository class를 만들어야 합니다. 예를 들어, 영화와 관련된 데이터를 위한 MoviesRepository 클래스나, 결제와 관련된 데이터를 위한 PaymentsRepository 클래스를 만들 수 있습니다.

 

3-3 Domain Layer

Domain Layer는 UI Layer와 Data Layer 사이에 있는 선택적인 Layer다.복잡한 비즈니스 로직,여러 ViewModel 에서 재사용되는 간단한 비즈니스 로직의 캡슐화를 담당한다. 복잡성을 처리하거나 재사용성을 높여야 할 때와 같이 필요한 경우에만 사용하는 것이 좋습니다.

 

4. 앱 구성요소간 종속 항목 관리

앱 구성요소들 사이에 의존성이 생기기 때문에 이 부분을 해결하기 위한 추천

• 의존성 주입 (Hilt 추천)
• Service locator : Service locator 패턴은 클래스가 종속성을 생성하는 대신에 이를 얻을 수 있는 레지스트리를 제공

 

5. 일반적인 권장사항

다음 권장 사항들은 필수 사항은 아니지만, 대부분의 경우 이를 따름으로써 장기적으로 코드베이스가 더욱 견고하고, 테스트 가능하며, 유지 관리가 용이해집니다:

1. 앱 구성 요소에 데이터 X
2. Android 클래스에 대한 의존성을 줄이는 방향으로.
3. 앱의 다양한 모듈 간에 명확한 책임 경계를 설정.
4. 각 모듈에서 가능한 한 노출을 최소화하세요.
5. 앱의 고유한 핵심 기능에 집중하여 다른 앱과 차별화.
   • 반복적인 보일러플레이트 코드를 다시 작성하는 대신, Jetpack 라이브러리 및 기타 권장 라이브러리가 이러한 반복 작업을 처리하도록 하여, 시간을 절약하고 앱의 고유한 부분에 집중.
6. 앱의 각 부분이 독립적으로 테스트 가능하도록 고려해야 한다.
7. 타입은 자신의 동시성 정책을 책임져야 한다. (적절한 Thread 및 코루틴 RxJava 사용)
8. 사용이 많이 되는 최신의 데이터를 지속적으로 저장 필요.
   • 이렇게 하면 사용자가 기기가 오프라인 상태에서도 앱의 기능을 사용가능. 모든 사용자가 인터넷 속도가 일정하게 항상 빠른게 아님.