-한두명이 아닌, 여러명이 공통 개발을 할 때, 각자의 담당하는 바를 간섭하지 않고 개발하기란(without stepping on each other's toes) 어렵다. 그래서 이를 방지하고자 이런 모듈들로 나눠서 만들 수 밖에 없다는 의미.
(2) maintainability 유지보수성
- 만약 monolithic application, 즉 하나의 거대한 아키텍쳐를 가진 앱을 마주하게 된다면? 안드로이드 개발자가 수십 수백개의 레이어들을 마주하게 되고 이를 파악하고 분석하는 것은 매우 어려운 일이다. 대신에, 만약 이 레이아웃들을 각 특징(feature)에 기반하여 그룹화 한다면, 용도의 파악이 용이진다. 또한 굉장히 길고 이상한 이름(weird name)으로 목록이 생기지 않는다.
(3)Faster compilation 빠른 컴파일
- 왼쪽은 monolithic application의 예, 오른쪽은 modulaized application된 예다. 만약 '(designer_news_)comment.xml'라는 파일을 1개 수정했다고 가정 했을때, 컴파일시 커버 범위는 다음과 같다.
(4)Faster CI(Continuous Integration) 빠른 지속적 통합
- 만약 다음과 같은 모듈 구조를 가진 앱이 있다고 가정하자.
- 이 중에서 module5를 수정 한다고 했을때, 변화가 올바른지 확인하기 위해서 테스트를 해야하는 부분은 오로지, module5가 depend 하고 있는 app부분만 확인하면 된다. 따라서 테스트를 할 때, 연관되지 않은 다른 부분들을 실행할 필요가 없다.
- 이에 대해서 '우리는 incremental CI이 없다!'라고 말할 수 있다. 그래서 AndroidX 개발에서 의존성 그래프에 대한 플러그인, 파일들이 변화된 위치와 해당 파일들이 포함된 모듈이 무엇인지에 대한 Git History를 알 수 있도록 하는 플러그인들을 작성했다. 그리고 영향받은 모듈들에 대한 모든 테스트를 실행하였다. 해당 작업에 대한 링크는 다음과 같다. http://goo.gle/androidx-dependency-tracker
(5)Good for business
- APK 사이즈가 작아지는 장점이 있다. Play store의 통계에 따르면, APK 사이즈에 따라 사람들이 설치를 시작하고 중단하는 비율이 다음과 같다. 즉 앱의 사이즈가 작으면 보다 많은 이용자를 끌어들일 수 있다.
- 또한 PM이 "내가 정말 멋진 라이브러리를 찾아가지고 왔어!"라고 아이디어를 들고 와도, 이것이 좋은지 안좋은지 싸울 필요가 없다. 다이나믹하게 개발하고 A/B 테스트를 진행하면 됨.
- 앱 모듈을 라이브러리 모듈로 변환할 때, 기존 앱 모듈의 build.gradle 파일을 열면 맨 위에 다음과 같이 표시 되어 있다.
apply plugin: 'com.android.application'
- 이를 다음처럼 플러그인 할당을 변경하고 sync를 맞춘다.
apply plugin: 'com.android.library'
- 모듈의 전체 구조는 동일하게 유지되지만, 이제 Android 라이브러리로 작동하며 빌드에서 이제 APK 대신 AAR 파일이 생성됩니다.
app은 application으로 plugin하고, module은 library로 plugin한다app은 module1이라는 라이브러리에 의존한다. 즉, app은 module1으로부터 코드와 리소스를 접근한다.그러나 다른 모듈들은 dynamic feature modules일 수 있다. dynamic feature modules들은 dynamic delivery를 경유하여 로딩되는 on-demand code로 사용될 수 있다.
dynamic feature modules은 app에 의존한다. 즉, app으로부터 코드와 리소스를 접근한다.app은 이런 모듈들을 build.gradle 파일에 dynamic feature modules로 선언한다.여기서 중요한 점은, app은 사실 module2와 module3에 의존하지 않는다는 점이다. 이는 이 app 안의 feature module의 메인 제약(restriction)이다. 그래서 app이 실제로는 코드와 리소스를 접근하지 않음에도, 이 옵션은 feature modules의 on-demand delivery를 허용한다. dynamic delivery를 통해서, 사용자는 요구에 따라 동적인 특징들(dynamic features)을 다운로드하고 설치할 수 있다.
요구에 의해 꺼지는 modules은 당신의 APK의 부분으로써 자동적으로 추가된다. 그리고 만약 당신이 on-demand delivery를 enable 한다면, 이것은 Google Play Store로부터 해당 모듈의 다운로드를 관리할 필요가 있다는 것을 의미한다.
공유된 코드와 리소스는 코어 라이브러리의 부분이 된다.
on-demand delivered modules의 이점은 3rd-party 라이브러리를 의존할 수 있다는 것이다. 그리고 정말로 모듈에 다운로딩 될 때만 다운로드 된다. 이는 APK 사이즈를 줄일 수 있다는 것을 의미한다.
하지만 어떻게 우리는 dynamic feature module인 것과 아닌 것을 결정하는가? 이를 위해, 화자는 80/20 원리(80%의 유저가 app의 20%를 사용한다)를 설명한다.그렇다면, app의 나머지 80%는 app의 core flow 부분이 아니다. 이를 expert features 혹은 paid features라고 하자. 이 features는 나중에 다운받아질 수 있다.
유사하게, OnBoarding과 같이 나중에 삭제될 수 있는 feature도 있을 수 있다. 그래서 onDemand는 fase가 될 것이다. 이처럼 약간의 공간을 청소할 수 있다. 그렇다면 About Screen과 같은 app의 core flow가 아닌 경우를 이야기 하자. 이 경우는 on demand이어야 하는가, 아니어야하는가? dynamic feature여야 하는가 아닌가? 이에 화자는 이처럼 작은 경우, Aout Screan에 즉각적인 접근이 되는 것을 원한다면 안드로이드 라이브러리쪽인게 보다 좋을 것이라 이야기 한다. 만약 좋은 사용자 경험을 확실하게 하고 싶고, 사용자가 이걸 기다리게 하는 것을 원하지 않는다면 말이다. 물론 간단한 about과 같이 dynamic feature module이 가져오는 모든 트러블이 가치있지는 않다.이제 다른 접근으로, 격자(Plaid) 화면 형태인 뉴스 어플리케이션 샘플에 대해 이야기 해보자. 이 앱은 3개의 다른 소스(디자이너 뉴스, 디자이너 커뮤니티 dribbble, Product hunt 서비스)부터 데이터를 합친다. 각각의 소스는 각자의 표현방법과 비지니스 로직을 가진다. 우리가 원하는 것은 on-demand delivery에 대한 가능성이다. 우리가 원할 때마다 이와 같은 데이터들을 다운로드하는게 가능 해야하고, 다른 것들이 추가 될 수 있어야한다.
즉 이는 디자이너 뉴스나 dribble이 dynamic feature module임을 의미한다.
하지만 search나 about과 같은 것을 우리는 보게 되는데, 이것들은 on-demand delivery로부터 이득을 볼 수 없다. 그래서 우리는 이걸 library module로 남겨둔다.
(2) feature modularization
앞서 말한 격자(Plaid) 화면의 Features들은 어떤 종류의 사용자 features을 가지고, 어떤 기술을 필요로 하는가? (그림과 같이) 우선 뉴스 스트림에 대한 지속성과 이를 fetch하는 API 클라이언트 및 feed UI가 있어야한다. 복수의 뉴스 프로바이더들, 프로바이더에 따른 커스텀 스타일, 권한, 사람들이 스토리에 대해 투표와 코멘트하는 기능들..... 등이 필요하다. 이에 대한 아키텍쳐는 아래와 같을 것이다.그렇다면 이와 같은 구조, layering의 종류로부터 어떻게 우리가 이점을 얻을 수 있을까? 한가지 옵션은 isolation이다.
모듈에 대하여 말할 때, 어떤 한 모듈이 다른 모듈에 의존적이라면 이는 'API' 혹은 'Implementation'이라고 말할 수 있다. API의 경우: 모듈A에게 모듈B에 의존적인 API가 있다면, 이는 B로부터 제공받는 모든 public 기능들은 B로부터 제공받는다는 것이다. 즉 A에 의존하는 모듈들도 B의 public api에 접근할 수 있다. 하지만 implementation의 경우, A에 의존적인 모듈들은 B를 볼 수 없고, B에 대하여 알아야만 한다.
