앱에 기능이 추가되고 복잡해짐에 따라 최종 파일 크기가 크게 증가하는 것은 흔한 일입니다. 앱 크기가 너무 크면 많은 사용자가 설치 버튼을 누르기 전에 망설 이거나, 심지어 다운로드 도중에 포기하는 경우가 발생하기 때문에 이는 심각한 문제입니다. 더욱이, 대용량 앱은 휴대폰의 저장 공간을 더 많이 차지하여 궁극적으로 시스템 응답 속도에 영향을 미칠 수 있습니다.
프로젝트가 지나치게 커지는 것을 방지하기 위해 코드 정리부터 이미지 최적화까지 다양한 전략이 있습니다. 이 글에서는 R8과 ProGuard 같은 도구 와 앱 번들(App Bundles)의 강력한 기능을 활용하여 앱을 최대한 가볍고 빠르게 만들어 저사양 기기에서도 원활하게 실행되도록 하는 방법을 자세히 살펴보겠습니다.
앱에서 진정으로 중요한 것이 무엇인지 이해하기
시작하기 전에 데이터의 대부분이 어디에 있는지 알아야 합니다. 애플리케이션 크기는 일반적으로 네 가지 주요 블록으로 나뉩니다. 첫째, 자바 또는 코틀린 바이트코드 와 해당 라이브러리가 있으며, 이는 보통 30%에서 40%를 차지합니다. 다음으로 레이아웃 및 애니메이션과 같은 리소스가 비슷한 비중을 차지합니다. 또한 다양한 아키텍처용으로 컴파일된 네이티브 라이브러리(C/C++)가 15%에서 25%를 차지하고, 마지막으로 에셋 또는 원시 파일이 5%에서 15%를 차지합니다.
추측을 피하려면 Android Studio의 APK 분석기 (빌드 > APK 분석)를 사용하는 것이 가장 좋습니다. 이 도구를 사용하면 DEX 클래스, 리소스 폴더 및 네이티브 라이브러리의 크기를 정확하게 확인할 수 있으므로 현재 버전과 이전 버전을 비교하여 파일 크기 증가의 원인이 되는 변경 사항을 정확히 찾아낼 수 있습니다. 이 주제를 더 자세히 알아보려면 Android의 파일 계층 구조 와 파일 구성 방식을 이해하는 것이 도움이 됩니다 .
코드 정리: ProGuard에서 R8로의 도약
코드 축소는 바이트 크기를 줄이는 가장 효과적인 방법임이 분명합니다. 바로 이 점에서 ProGuard와 그 최신 버전인 R8이 중요한 역할을 합니다. ProGuard는 오랫동안 표준으로 자리매김하며 사용되지 않는 클래스, 필드, 메서드를 제거 하고 , 바이트코드를 최적화하고, 이름을 난독화하여 더 짧게 만들어 (해킹하려는 사람이 읽기 어렵게) 만들었습니다.
현재 R8은 기본 컴파일러 이며 ProGuard가 수행했던 모든 기능을 훨씬 더 효율적이고 빠르게 제공합니다. R8은 더욱 적극적인 트리 셰이킹을 구현하고 , 유사한 기능을 가진 클래스를 병합하며, 열거형을 정수로 변환하여 최적화합니다. 또한, 이전 버전의 Android에서도 최신 Java 8 함수를 사용할 수 있도록 디슈가링(desugaring) 기능을 제공합니다.
build.gradle 파일의 기술 구성
릴리스 버전에서 이러한 최적화를 활성화하려면 빌드 파일을 다음과 같이 구성해야 합니다. minifyEnabled를 true로 설정 규칙 파일을 연결하는 것도 중요합니다. proguard-android-optimize.txt 최적화 기능을 최대한 활용하기 위해. 기본적인 구성 예시는 다음과 같습니다. 애플리케이션 클래스를 유지 관리합니다. 또는 다음과 같이 표시된 것들 @Keep R8이 실수로 삭제하는 것을 방지하기 위해서입니다.
외부 라이브러리에 대한 규칙 관리
때때로 R8은 너무 효율적이어서 리플렉션을 통해 사용된 코드를 삭제하여 다음과 같은 오류를 발생시킬 수 있습니다. ClassNotFoundException그래서 서점 같은 곳들이 있는 겁니다. Retrofit, OkHttp 또는 Gson을 사용하려면 특정 규칙이 필요합니다.예를 들어 Gson을 사용할 때는 JSON 역직렬화 오류를 방지하기 위해 데이터 모델에서 필드 이름을 유지하는 것이 매우 중요합니다. 난독화 후 오류가 발생하는 경우 해당 파일을 확인하세요. 매핑.txt 스택 트레이스를 해석하고 오류가 발생한 위치를 파악하는 데 있어 최고의 조력자입니다.
지능형 자원 최적화
자원은 종종 공간 낭비가 가장 심한 곳에서 나타납니다. 간단하지만 강력한 기법은 자원을 활성화하는 것입니다. shrinkResources build.gradle 파일에서 이 설정을 변경하면 코드에서 참조되지 않는 파일이 제거됩니다. 하지만 리소스를 동적으로 호출하는 경우에는 이 점을 유의해야 합니다. getIdentifier파일에 해당 내용을 선언해야 합니다. keep.xml 사라지지 않도록 하기 위해서입니다.
이미지 및 그래픽: 간결함이 미덕
PNG 형식은 불필요하게 용량을 많이 차지합니다. 현재 권장 사항은 모든 이미지를 WebP 형식으로 변환하는 것입니다. WebP 형식은 품질을 유지하면서 훨씬 뛰어난 압축률을 제공합니다. Android Studio에서 이미지를 마우스 오른쪽 버튼으로 클릭하여 직접 변환할 수 있습니다. 아이콘이나 간단한 도형에는 벡터 드로어블이 이상적입니다 . 하나의 XML 파일로 다양한 밀도의 이미지 5개를 대체할 수 있어 유지 관리가 간편하고 파일 크기도 줄어듭니다.
언어와 밀도를 줄임
많은 외부 라이브러리에는 앱에서 지원하지 않는 50개 언어로 번역된 버전이 포함되어 있습니다. 이를 정리하려면 속성을 사용하세요. defaultConfig의 resConfigs실제로 사용하는 언어만 지정하세요(예: "es", "en"마찬가지로, 대상 고객이 최신 기기를 사용하는 것을 알고 있다면 리소스를 제거하여 포함되는 화면 밀도를 제한할 수 있습니다. ldpi 또는 mdpi 이제 아무도 사용하지 않는 것.
고급 유통 전략
APK 파일 크기를 확실히 줄이려면 유니버설 APK 사용을 중단하고 Android 앱 번들(.aab) 로 전환해야 합니다 . Google Play는 모든 콘텐츠를 담은 하나의 거대한 파일을 전송하는 대신 각 기기에 최적화된 APK를 생성합니다. 따라서 ARM64 프로세서를 탑재한 스마트폰과 xxhdpi 해상도의 화면을 사용하는 사용자는 자신의 하드웨어에 필요한 앱만 다운로드하게 되어 다운로드 크기를 최대 40%까지 줄일 수 있습니다.
동적 기능 모듈 및 인스턴트 앱
모든 코드를 처음부터 제공할 필요는 없습니다. 동적 기능 모듈(Dynamic Feature Modules)을 사용하면 앱의 일부 기능(예: 고급 사진 편집기 또는 오프라인 모드)을 분리하여 사용자가 해당 기능에 접근할 때만 다운로드되도록 할 수 있습니다. 반면, 인스턴트 앱(Instant Apps)은 URL이나 Google Play 버튼을 통해 매우 가벼운 기본 모듈을 로드하여 사용자가 앱을 설치하지 않고도 사용해 볼 수 있도록 합니다.
종속성 감사 및 최종 세부 정보
때로는 문제가 코드 자체가 아니라 외부에서 가져오는 라이브러리에 있을 수 있습니다. Guava나 Jackson 같은 라이브러리는 용량이 매우 클 수 있으므로 kotlinx.serialization이나 Gson처럼 더 가벼운 대안 으로 교체하는 것을 고려해 보세요 . 또한, 여러 가지 글꼴 변형을 사용하는 경우 용량이 큰 TTF 파일을 에셋에 포함하는 대신 Google Fonts에서 다운로드 가능한 글꼴을 사용하는 것이 좋습니다. 이렇게 하면 몇 메가바이트를 절약할 수 있습니다.
최적화 과정을 완료하려면 Android Go 시장이 성장하고 있다는 점을 기억해야 합니다. 1GB 미만의 RAM을 가진 기기에서도 앱이 최적의 성능을 발휘하려면 앱 크기를 40MB 미만으로 유지하는 것이 좋습니다. Android Lint를 사용하여 사용되지 않는 리소스를 감지하고 일관된 정리 루틴을 유지하면 기기 성능에 관계없이 앱이 효율적으로 작동하고 설치 속도가 빠르며 원활한 사용자 경험을 제공할 수 있습니다.
