[Android] App Architecture

안드로이드 앱 아키텍처

앱 아키텍처 디자인은 앱이 강력하고, 테스트와 유지보수가 용이한지 확인하기 위한 중요한 요소이다.

안드로이드는 우리가 앱 아키텍처를 용이하게 짜기 위해 라이브러리와 best practice를 제공한다.

 

아키텍처의 탄생

수 많은 프로그램을 만들면서 사람들은 자주 발생하는 문제들에 대해 반복적으로 사용가능한 효율적인 구조가 있다는 것을 알게 되었고 그것이 아키텍처라고 불리게 되었다. 만드는 프로그램에 따라 다른 용이한 수 많은 아키텍처가 존재하지만 안드로이드에서 주로 mvc, mvp, mvvm 패턴이 사용되고 있다.

1970년대 Trygve Reenskaug가 MVC 패턴을 만들었고 이후 수많은 패턴들이 고려되기 시작했다.

1990년대에는 Taligent가 MVC의 개선 모델이라 할 수 있는 MVP 모델을 도입했다.

2005년에는 John Gossman이 micro soft wpf와 실버 라이트에 MVVM 패턴을 도입했다.

아키텍처 패턴의 사용 이유

아키텍처 패턴은 프로그램 내부에서 관심사를 분리해서 프로그램을 더 안전하고 확장가능하게 만들 수 있다.

MVC vs MVP vs MVVM

MVC

MVC에서는 Model, View, Controller로 나눈다.

Model은 데이터와 비지니스 로직이라 불리는 app ui와 관계없는 부분을 담당한다.

View는 화면에 모델의 데이터를 표시하거나 데이터를 갱신하는 ui 로직을 담당한다. (xml layout)

Controller는 View와 Model의 상호작용을 중계하는 컨트롤 타워 역할을 한다. 외부에서 전달받은 입력을 처리해서 뷰에 내용을 갱신하고화면 그리기를 요청하는 프레젠테이션 로직을 가지고 있다. (class MyActivity)

• MVC 패턴에서는 Model과 View과 완전히 분리되므로 Model은 쉽게 테스트 가능
• Controller가 안드로이드에 종속되기 때문에 테스트가 어려워짐
• 안드로이드 특성상 액티비티가 View 표시와 Controller 역할을 같이 수행해야 하기 때문에 두 요소의 결합도가 높아짐
• 많은 코드가 Controller로 모이게 되어 액티비티가 비대해짐

MVP

위와 같은 문제를 해결하기 위해 MVP 패턴이 등장했다. MVP 모델은 Model, View, Presenter로 나눈다.

Model은 MVC와 동일한 역할을 한다.

Presenter는 MVC의 Controller와 같은 역할을 하지만 View의 참조를 거치지 않고 interface를 통해서 교신하므로 결합이 상대적으로 느슨해 졌다. 뿐만아니라 android 의존성을 갖지 않기 때문에 test도 용이하다. Presenter는 View로부터 액션을 전달받고 Model에서 데이터를 전달 받고 이를 View에 표시한다. 

View는 MVC의 View와 Controller를 MVP에서는 View로 간주된다. (xml과 acitvity or fragment) View에서 모델 참조가 없어지고 presenter 참조가 생김

• View와 Model 사이의 데이터 흐름이 사라지고 Presenter가 중간에서 데이터 흐름을 제어
• 인터페이스를 추가로 구현해야 하기 때문에 구현 비용이 올라가게 됨 (추가 코드가 생김)
• View와 Presenter가 1:1로 대응해야 하기 때문에, 앱이 커질수록 두 요소의 의존성이 강해지게 됨

MVVM

MVVM은 앱을 Model, View, ViewModel로 나눈다.

Model은 MVC의 모델과 동일하다.

ViewModel은 View를 만드는데 필요한 model을 관리한다. View가 ViewModel을 참조하지 않게 되었기 때문이 1:N 관계가 되었다. 따라서 중복되는 코드를 묶어서 ViewModel에서 코드를 줄일 수 있다.

View는 사용자에게 보여지는 Ui 부분이고 Binding을 통해서 ViewModel에서 일방적으로 통지받은 데이터를 유저에게 보여주는 역할만 한다. ViewModel은 View를 참조하지는 않지만 View에 바인딩할 Observable데이터를 가지고 있기 때문에 View가 이를 옵저빙하므로서 Ui를 갱신할 수 있다.

• View와 Model 사이에 의존성이 없으며, ViewModel도 View에 의존성을 가지지 않음
• 참조는 View > ViewModel > Model 순으로 단방향으로만 일어남

 

Google

google은 2017년 구글 I/O에서 개발자들이 안드로이드 여러 컴포넌트와 복잡한 생명주기를 잘 다룰수 있도록 아키텍처 컴포넌트와 가이드 투 아키텍처를 발표했다. 이는 2018년 Android Jetpack을 발표하므로서 확장되었고 안드로이드 앱 아키텍처라는 개념이 만들어졌다.

안드로이드 앱 아키텍처는 android architecture component를 활용해서 MVVM 패턴을 구성하는 것이다.

 

Model은 room을 통해 구축이 되고 Activity와 Fragment는 View로 작동한다. View는 ViewModel의 LiveData를 옵저빙하게 했다.

Android app architecture의 ViewModel은 앞서 말한 MVVM의 ViewModel이 아니라 android architecture component의 특정한 라이브러리를 의미한다. 안드로이드 개발자들이 이 아키텍처 패턴을 따르므로서 MVVM 라이트 구조를 앱에 도입할 수 있고 이는 앱의 안전성을 향상시키며, 최종적으로 playstore 생태계를 건강하게 만든다. Google이 안드로이드 아키텍처 패턴에 개발을 투자하는 이유이다.

 

구글은 2022년 앱을 UI Layer, Domain Layer, Data Layer로 나눈 그림을 공개했다.

Ui Layer에는 View와 ViewModel

Domain에는 UseCase

Data Layer에는 Repository와 DataSource 이 위치한다.

UseCase가 없다면 ViewModel의 비지니스 로직을 가지고 있어 ViewModel이 너무 비대해진다.