본문 바로가기

생각정리

[Android APP Architecture] 안드로이드 아키텍처

728x90

 

오늘은 앱 아키텍처에 대해 적어보겠습니다. 

https://developer.android.com/jetpack/guide

 

 

앱 아키텍쳐는 앱의 각 부분과 부분들이 가져야 할 역할의 경계를 정의한다. 

앱의 크기가 커짐에 따라 앱의 확장 , 앱의 견고성 향상 , 테스트 용의성을 높일 수 있다. 

 

 

일단 아키텍처의 설명을 해보자면 

 

1. 집중도, 역할의 분리이다 . 

코드들을 액티비티 또는 프래그먼트에 모두 쓰는 것은 일반적인 실수라고 할 수 있겠다. 

이런 UI 기반 클래스(액티비티, 프래그먼트)에는 UI 및 운영체제 상호작용을 처리하는 로직만 포함을 하는 것이 좋고 

이렇게 함으로써 라이프 사이클과 관련된 많은 문제를 피하고 테스트성이 용이해진다. 

 개발자는 액티비티와 프래그먼트를 만드는 사람이 아니다 . Android OS와 앱을 연결하는 것을 만드는 것이다. 이 OS 는 UI (User Interface) 에 따라서 또는 메모리가 부족한 시스템의 상태에 의해서 언제라고 파괴가 될 수 있다. 

그럼으로 개발자들은 이러한 것들을 고려하여 사용환경과 유지보수를 위해서 최대한 집중도와 역할을 낮추는 것이 좋다. 

 

2. Data Model을 사용하여 UI를 운영하는 것이다. 

UI를 Data Model과 같이 사용하는 것이 좋다. 데이터 모델은 앱의 데이터를 관리하는 곳인데 이것은 UI 요소 및 앱의 컴포넌트와는 독립적이라 UI (액티비티나 프래그먼트) 의 라이프 사이클에 얽메이지 않게된다. 그리고 네트워크가 끊겨도 OS 가 앱을 파괴해도 데이터를 잃지않고 동작하기 때문에 데이터 모델을 사용하는것이 테스트성과 앱의 유지성을 높일 수 있다. 

 

Data Model의 가장 쉬운 예를 들어보면, 숫자 카운트를 세는 어플리케이션이 있다고 했을 때 . 숫자를 높이다가 핸드폰 화면을 회전시키면 숫자는 다시 초기화가 되게 된다 . 이유는 숫자라는 데이터가 앱의 컴포넌트와 독립적이지 않고 종속이 되어있는 상태이기 때문에 초기화가 되는 것이다. (화면이 회전하게되면 라이프 사이클 초기화됨) 이러한 문제를 Data Model 을 사용하면 해결할 수 있다. 

 

 

지금부터 안드로이드에 Developer에서 추천하는 아키텍처를 나름대로 설명을 해보겠다. 

 

 

 

 

1. UI Layer 

 데이터를 화면에 표시하고 사용자 조작 (버튼클릭) 또는 외부 입력 (네트워크)로 인해 데이터가 변경될 때마다 

UI 변경사항을 업데이트하는 역할을 한다. 

 

UI는 두가지 요소로 구성이되어진다. 

 

1. 데이터를 렌더링하는 UI Element (View, Jetpack compose) - 쉽게 말하면 layout 

(Jetpack Compose ? -> UI를 코드로 구현할 수 있고 필요한 영역의 뷰를 그려줌)

 

2. 데이터를 보관하고 UI에 표시, Logic을 처리하는 State Holder  (ViewModel 이 여기에 해당한다.) 

 

 

 

2. Data Layer

비지니스 로직이 포함되는 곳

(비지니스 로직이란? 어떻게 data를 생성하고 저장하고 변경할 것인지에 대한 규칙을 정하는 로직)

 

Data Layer는 0부터 많은 Data Source를 포함 하는 Repository를 만드는 역할을 한다. 하지만 만들 때에는 앱에서 처리하는 데이터 유형별로 Repository를 짜야된다. (만약 영화관 관련된 앱이라면 MovieRepo, PaymentRepo 이런식)

 

Data Source는 하나의 독립적인 data source를 가져야 하며 Data Source는 데

이터 작동을 위한 구체적인 로직 코드들이 포함되는 곳 . 

 

 

 

 

 

UI 레이어와 Data Layer 순서

 

 

3. Domain Layer

UI Layer 와 Data Layer 사이에 있는 선택적인 계층. 

복잡한 비즈니스 로직을 요약하거나 여러 뷰 모델에서 재사용되는 단순한 비지니스 로직이다. 

선택사항이기 때문에 모든 앱에서 필요하진 않지만 복잡한 것을 처리하거나 재사용 가능성을 높이기 위해 사용한다. 

이 클래스들은 단일 기능에 대해서만 사용되어지며 인터랙터라고 불린다. UseCase가 이에 해당한다. 

 

이 UseCase는 Repository에 있는 로직을 하나씩 꺼내어 세분화 하여 사용한다. 

UseCase