일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Compose
- pandas
- Rxjava
- 백준
- 프로그래머스
- Coroutine
- MyVoca
- textfield
- 쿠링
- Python
- TEST
- 코드포스
- Coroutines
- architecture
- boj
- livedata
- relay
- AWS
- activity
- Kotlin
- GitHub
- 암호학
- Codeforces
- android
- ProGuard
- androidStudio
- 코루틴
- Hilt
- MiTweet
- Gradle
- Today
- Total
이동식 저장소
[Android] APK와 AAB 본문
안드로이드 앱을 설치하는 파일 확장자는 APK이다. 그런데 Android Studio에서 앱을 빌드하려고 보면, Android App Bundle이라는 형식이 기본으로 지정된다.
심지어 AAB 파일은 안드로이드에서 설치할 수도 없다. 이게 뭐지?
AAB란...
Android App Bundle, 줄여서 AAB는 앱의 코드와 리소스, APK 생성 방법과 서명 정보까지 모두 담고 있는 파일이다. 기기에서 직접 사용할 수는 없지만, Google Play가 AAB를 APK로 변환하는 데 사용된다.
APK로 변환한다는 말을 자세히 설명하면, 기기의 폼 팩터와 언어, API 레벨에 맞게 적절한 APK를 만든다는 뜻이다. 안드로이드 버전에 따라 다른 코드를 적용할 수도 있고, 화면 크기에 따라 다른 레이아웃을 사용할 수도 있고, 기기의 언어에 따라 서로 다른 resource 파일을 포함할 수도 있다. 이전에는 모든 코드와 리소스 등을 포함한 하나의 APK가 배포되었는데, AAB의 등장 이후로 기기에서 필요한 코드와 리소스만 포함된 APK를 받을 수 있는 것이다.
사용자 입장에서 보면 내 기기에 필요한 코드만 받으므로 앱의 크기를 최적화할 수 있다는 장점이 있다.
또, 지정된 조건에서만 포함되는 feature module을 추가하기도 쉬워진다. APK는 Google Play가 알아서 만들어 주기 때문이다.
다운로드 크기 제한
상술했듯이 앱을 AAB로 출시하면 사용자들이 다운로드하는 총 용량이 줄어든다. 사실 Google Play에서 다운로드하는 APK의 크기 제한은 150MB이다(게임의 리소스 등은 별도로 계산). 따라서 앱이 너무 크다면 다음의 방법을 적용하여 앱의 크기를 줄여야 한다.
- 모든 configuration APK에서 ``enableSplit``을 ``true``로 설정하여 필요한 코드와 리소스만 다운로드될 수 있도록 설정한다. 이 옵션은 AAB를 지원하지 않는 다른 스토어에서 특히 유용하다.
- ProGuard를 적용하여 불필요한 코드와 리소스를 제거한다.
- 앱을 경량화하기 위한 일반적인 방법을 적용한다. 일반적인 방법은 큰 효과가 없는 경우가 많긴 하지만..
- 일부 사용자에게만 제공되는 기능을 feature module로 분리한다. 그런데 feature module을 사용하면 앱의 동작 방식을 바꿔야 하므로, 이 방법은 최후의 수단으로 고려하자.
- Feature module이 무엇인지는 다른 글에서 공부해 보겠다.
AAB와 관련된 이슈
- 구글이 인증한 기기(Pixel 시리즈?) 또는 안드로이드 10(API 29) 이상의 기기에서, Google Play가 아닌 다른 스토어에서 앱의 일부만 다운로드한 후 Google Play에서 나머지를 채울 수는 없다. 웬만하면 Play에서 받는 게 안전하다.
- 사실 Google Play의 독점력을 키우기 위해 AAB를 도입했다고 보는 사람들도 있다.
- 리소스를 동적으로 수정하는 도구를 사용하면 AAB에서 생성된 APK가 예상과 다르게 동작할 수 있다.
- 선택적으로 다운로드되는 feature module에서 기본 모듈(base module)의 build configuration 값을 덮어쓸 수 있다. 예를 들어 기본 모듈에서는 ``debuggable``을 ``true``로 설정했는데, feature module에서 ``false``로 설정해도 빌드 에러가 발생하지 않는다. 하지만 런타임에서 예상치 못한 문제가 생길 수 있다.
- 기본적으로 Feature module은 base 모듈의 설정 값을 상속받는다. 따라서 어떤 값을 수정해야 하는지, 어떤 값은 그대로 사용해야 하는지 주의깊게 살펴 보자.
참고문헌
'Primary > Android' 카테고리의 다른 글
[Android] 반응형 UI 구현 방법론 (0) | 2022.10.17 |
---|---|
[Android] AAB 더 알아보기 (0) | 2022.10.14 |
[Android] Proguard가 사람 잡는다 (0) | 2022.10.01 |
Gson에서 null이 반환될 때 with ProGuard (0) | 2022.09.27 |
[Android] 디버깅할 때 앱이 느리다면 (0) | 2022.09.25 |