BuildConfig 와 ProductFlavor 정리 # BuildTypes BuildConfigField

오늘은 BuildConfig와 ProductFlavor에 대해서 정리해 보고자 하는데요.

이 두가지 클래스들은 각각 빌드별로 다른 값을 가지거나, 기본앱과는 다른 타입의 앱을 출시해서 사용하도록 하는데 사용할 수 있는데요.

먼저 빌드별로 다른 값을 가지도록 할 때 사용하는, buildConfig클래스의 buildConfigField에 대해서 알아보도록 하겠습니다.

 

1. buildConfig 클래스

1-1. BuildConfigField 구현

빌드가 될 때, 안드로이드의 빌드 시스템인 Gradle은 BuildConfig클래스를 생성합니다.

이는 현재 빌드에 대한 정보를 확인할 수 있도록 하기 위함인데요.

BuildConfig클래스의 buildConfigField()메소드를 이용하면, 인자에 원하는 값을 넣어서 접근할 수 있습니다.

주의해야 할 것은 runtime시에 값이 들어가므로, 코딩시 컴파일러가 에러를 보정해 줄 수 없는데요.

그래서 테스트를 꼭 거치거나, boolean값처럼 null에러가 나지 않는 정도의 값들을 이용하는 것이 좋습니다.

 

app레벨의 build.gradle에서 buildConfig클래스를 구현 하게 되는데요.

라이브러리가 많이 사용되는 요즘에는, 아래와 같이 buildTypes의 debug에서는 minify를 false로하고 release에서는 minify를 true로 설정해 놓습니다.

 

 

이 상태에서 debug와 release에 각각 다른 값을 주기 위해 buildConfigField메소드를 사용해 보겠습니다.

아래에서 보이는 것처럼, 인자로 type과 name 그리고 value값을 적어주면 되는군요.

컴파일러가 철자오류를 찾아주는 것이 아니고, String으로 모든 타입과 값을 써야 하므로 주의를 기울여서 타입과 값을 적어주어야 합니다.

 

 

첫번째 인자로 들어가는 type에는 String, boolean, int, long, float 그리고 double을 사용할 수 있습니다.

아래에서는 debug빌드에서 IS_FOR_TEST 값을 true로 나오게 하고,

release빌드에서는 false로 잡아주었습니다.

 

 

 

 

 

이제 코드에서 로그를 찍어보도록 하겠습니다.

아래와 같이 정상적으로 동작하는 것을 볼 수 있네요.

 

 

1-2.resValue

buildCofigFiled와 비슷하지만, app의 resource value를 빌드별로 다르게 가지도록 하는데는 resValue메소드를 사용해주면 되는데요.

사용방법은 buildCofigFiled와 비슷합니다.

 

 

 

아래와 같이 코드내에서 해당 type name을 사용하려고 하면, 컴파일러가 접근 가능한 string임을 보여줍니다.

 

log도 정상적으로 찍히는 것을 알 수 있습니다.

 

 

2. ProductFlavor

2-1. Product Flavor 언제 사용할까?

위에서는 buildType을 debug과 production으로 구분해서 각각의 빌드에 다른 값을 가지도록 하였었는데요.

productFlavor의 경우는 기본적인 앱 코드는 같으나, 약간 다른 형태로 앱을 출시해야할  때 사용하기에 좋습니다.

가장 많이 생각할 수 있는 것이 앱의 무료 버전과 유료버전입니다.

앱자체의 기본적인 기능은 같지만, 광고를 활성화 하거나 비활성하는 차이를 줄 수 있는데요.

ProductFlavor를 사용할 수 있는 대표적인 예라고 할 수 있을 것 같습니다.

 

또한 dev, cbt, market버전등으로 앱 버전등을 나누어서 아래와 같이 사용할 때도 사용할 수 있는데요.

특히, android는 sdkversion을 16으로 보통 잡고 시작하는데요.

요즘같이 라이브러리를 많이 사용할 때는 최적화가 않된 debug단계에서 method count가 한계치(65k)를 넘는경우가 많습니다.

release시에야 R8을 이용해서 필요없는 method들이 줄어들고 최적화가 되서 괜찮은데,

debug단계에서는 metod count가 넘을 때는 product Flavor를 21로 설정해주면,

multidex를 굳이 할 필요없이 debug모드에서 테스트하면서 개발하다가 최종적으로 출시할 때는 miSdkVersion을 16으로 잡고 할 수 있는 것이지요. (물론, 최적화를 하고 난 market버전에서도 method count가 65k를 넘어간다면 의미가 없는 것이지만요)

저의 경우는 이런식으로 대부분의 문제가 해결되는 것 같습니다.

 

 

 

2-2. 설정할 수 있는 값들

ProductFlavor에서는 위에서 본 minSdkVersion이 applicationId등에 대한 설정뿐만이 아니라,

versionCode, versionName등 build.gradle의 android tag에서 설정할 수 있는 모든 값들을 설정할 수 있습니다.

위에서 언급하지는 않았지만,  flavorDimensions값을 다르게 줘서 좀더 여러 타입의 앱을 생성할수도 있지만,

개인적으로는 아직 그정도까지 필요한 적은 없었던 것 같습니다.

 

2-3. BuildType과 ProductFlavor

ProductFlavor에 따라서 각각 다른 앱으로 구분되어지게 되구요.

그 앱들은 BuildType에 따라서 아래와 같이 나누어 지게 됩니다.

위와 같은 경우, buildType이 debug와 Release라면 아래와 같이 총 6가지의 APK를 선택해서 생성할 수 있겠지요.

 

- devDebug - cbtDebug - marketDebug - devRelease - cbtRelease - marketRelease

 

3. 정리

BuildType과 ProductFlavor를 이용해서, debug와 release에서 다른 값을 가지게 하거나,

무료 및 유료앱같이 기본코드베이스는 같지만 약간 변경된 값을 가지는 다른 앱들을 만들 수 있게 되었습니다.