[Android] Module 구조

#1 Module?

#1-1 What

하나의 build.gradle에 종속된 코드의 범위
= 빌드의 최소 단위
= 라이브러리의 최소 단위

안드로이드 앱은 Gradle로 빌드되고, 그 빌드의 명세는 build.gradle에 적힌다. 모듈이 build.gradle 파일에 종속된다는 말은 즉 모듈은 "빌드의 최소 단위"라고 뜻이 된다.

 

#1-2 Why

왜 이런 단위를 쓸까? 다시 말해, 왜 "빌드의 최소 단위"로서 모듈을 쓸까? 자체적인 빌드 구성을 가지고 있다(= build.gradle 파일을 가지고 있다)는 말은, 자체적으로 컴파일한 결과물을 생산할 수 있다는 얘기다. 즉, 외부(타인)에서 실행할 수 있도록 배포(= 라이브러리화)가 가능한 최소 단위가 된다.

 

라이브러리화가 가능하다는 이야기는 기능들을 분리하여 각각 독립적으로 개발할 수 있다는 얘기다. "왜 객체지향을 사용하는가? (장점이 무엇인가?)"라는 질문에 대한 대답과 같은 맥락이다.

 

그렇다면 '객체지향의 문제점(단점)'도 비슷하게 공유할 것이다. 복수의 모듈로 이루어진 프로젝트는 그 모듈들의 build.gradle이 Java 버전, Kotlin 옵션, dependency 등에 차이가 있을 수 있다. 이 파편화는 잠재적인 에러를 유발할 것이고, 이를 방지하기 위해 귀찮은 작업을 해야될 수도 있다.

 

#1-3 package와의 비교

안드로이드 앱의 소스코드는 package라는 이름의 폴더로 카테고리화된다. package는 파일 트리 안에서 논리적으로 객체를 분리하는 것이다. 그리고 package는 논리적 분리만을 수행할 뿐, 빌드의 범위와는 관련이 없다. 따라서 라이브러리화가 가능한 module과 달리 package는 라이브러리화가 불가능하다 (좀 더 정확히는, 애초에 가능ㆍ불가능을 논할 수 없다).

 

#2 Module의 종류

#2-1 AAR 파일과 APK 파일

안드로이드 프로젝트를 빌드했다고 반드시 (스마트폰 상에서) 실행시킬 수 있는 건 아니다. 왜냐하면 빌드의 결과물은 AAR(Android ARchive) 파일 또는 APK(Android PacKage) 파일인데, 이 중 APK 파일만이 실행 가능한 파일이기 때문이다.AAR 파일은 이름(Android ARchive)에서 알 수 있듯, 라이브러리로 사용되기 위한 파일이다. AAR 파일은 APK 파일에 또는 또 다른 AAR 파일에 종속된 라이브러리로 사용된다. APK 파일은 필요한 경우 AAR 파일을 취하지만, 기본적으론 독립 실행이 가능한 빌드 결과물이다.

 

#2-2 App Module

빌드했을때 APK 파일이 나오는 모듈이다. 안드로이드 스튜디오에서 빈 프로젝트를 생성했을 때 "app"이라는 이름으로 기본 생성되는 모듈이 바로 App Module이다. build.gradle을 보면 applicationId, target sdk, version code, version name, ... 등 독립 실행을 위해 필요한 다양한 정보를 확인할 수 있다

 

#2-3 Library Module

빌드했을때 AAR 파일이 나오는 모듈이다. build.gradle을 보면 App Module과는 달리 누락된 정보가 많다. 가령, applicationId가 없다. applicationId는 Google Play Store에서 앱을 구분하는 용도, 시스템에서 앱을 식별하는 용도로 쓰이는데 Library Module은 애초애 독립 실행이 안되므로 굳이 applicationId과 같은 식별자가 필요없기 때문이다.

 

#2-4 빌드 순서

App module과 Library module이 섞인 프로젝트에서의 빌드는 아래와 같은 순서를 따른다.

1. 라이브러리 모듈 1: 소스 코드 + 리소스 (+ 필요한 AAR) → AAR 파일
2. 라이브러리 모듈 2: 소스 코드 + 리소스 (+ 필요한 AAR) → AAR 파일
3. 라이브러리 모듈 3: 소스 코드 + 리소스 (+ 필요한 AAR) → AAR 파일
...
n. 앱 모듈: 소스 코드 + 리소스 + (+ 필요한 AAR) → APK 파일

 

#3 모듈 구현해보기

완성된 프로젝트는 #4에서 전체 소스코드를 다운로드할 수 있다. 

 

#3-1 레퍼런스 코드

[Android] Retrofit - MVVM 구조

예전에 만들어둔 코드를 리팩토링해서 2개의 모듈로 나누겠다. 먼저 위 게시글에 있는 '완성된 앱'을 그대로 가져왔다. 기본 모듈인 "app"에 들어있는 retrofit 관련한 코드들을, "network"라는 새 모듈로 옮길 작정이다 (멀티 모듈화).

 

#3-2 모듈 만들기

[Project 탭에서 빈 공간 우클릭] -> [New] -> [Module]
또는 [File] -> [New] -> [New Module...]

 

[Create New Module] -> [Android Library] -> [모듈 이름 설정 (여기서는 "network")] -> [나머지는 그대로 두고 Finish]

어쨌든 이렇게 새 모듈을 추가하는 건 기본 모듈인 "app" 모듈을 복제하는 것과 같은 과정이다. 갓 만들어진 network 모듈을 보면 res 폴더가 없다. 물론 네트워크 관련 코드를 넣을 것이므로 res 폴더가 있을 이유도 없겠지만, 필요하다면 app 모듈이 res 폴더를 지니고 있는 것과 마찬가지로 그냥 생성해주면 그만일 것이다.

 

#3-3 코드 나누기

"app" 모듈에 있던 "retrofit" 패키지의 모든 파일을 "network" 모듈로 옮겼다. 이어서, "retrofit" 패키지는 삭제한다. 

 

implementation("com.squareup.retrofit2:retrofit:2.9.0")
implementation("com.squareup.retrofit2:converter-gson:2.9.0")

옮긴 코드들은 retrofit 및 gson 라이브러리에 종속되어 있다. 따라서 "network" 모듈 속 build.gradle 파일의 dependencies { ... }에 위와 같이 retrofit 및 gson 라이브러리를 추가한다.

 

#3-4 가시성 확보

#3-3에서 코드를 옮겼다고 끝난 걸까? 아니다. 왜냐하면, "app" 모듈은 "network" 모듈의 존재를 모르기 때문이다. 애초에 서로 독립적으로 빌드되는, 모듈의 단위가 다르기에 서로 알 이유도 없다 (import문 한 줄로 바로 코드를 가져올 수 있었던 package 단위와 대비된다).

 

"app" 모듈이 "network" 모듈의 코드를 참조할 수 있게 하려면 (= 가시성을 확보하려면), "app" 모듈 속 build.gradle의 dependencies { ... }에 "network" 모듈의 정보를 적어주어야 한다.

 

implementation(project(":network"))

위와 같은 코드를 적으면, "app" 모듈이 "network" 모듈을 참조할 수 있게 된다.

 

주의할 점은, 당연하게도 private 접근제어자가 붙은 코드는 무슨 짓을 해도 참조할 수 없다는 것이다. 파일 단위의 참조 범위를 지니는 private 그리고 모듈 단위의 참조 범위를 지니는 internal 모두 참조할 수 없다. Library Module을 만들 때는, 또 다른 Library Module 또는 App Module에 공개적으로 제공할 API만을 public 접근제어자로 둬야할 것이다.

#4 완성된 앱

android-practice/architecture/ModuleSample at master · Kanmanemone/android-practice

 

#5 참고

• [Google Developer] 프로젝트 개요
• [Google Developer] Android 앱 모듈화 가이드
• [Youtube] Multi-module Android App Tutorial
• [Google Developer] Android 라이브러리 만들기