Оптимізація розміру сборки мобільної програми
Розмір програми впливає на конверсію установки прямо: Google дані говорять про падіння конверсії на ~1% на кожен додатковий МБ розміру скачування на пристроях з повільним інтернетом. Android встановлює ліміт скачування без Wi-Fi (200 МБ за замовчуванням). iOS App Store показує попередження при скачуванні через сотовану сеть понад 200 МБ. Це не абстрактні метрики — це реальні бар'єри для установки.
Android: AAB та Play Feature Delivery
Перехід з APK на AAB (Android App Bundle) — перший та найпростіший крок. Google Play динамічно збирає оптимізований APK для кожного пристрою: лише потрібні ABI (arm64-v8a, x86_64), лише потрібні density ресурси (xxhdpi для пристроїв з xxhdpi екраном). Типова економія — 20-40% від розміру universal APK.
Якщо проект ще збирається в APK без AAB — це техдолг, який потрібно закрити в першу чергу.
R8 та ProGuard. R8 включений за замовчуванням у release-сборках з AGP 3.4+. Але minifyEnabled true та shrinkResources true у buildTypes.release потрібно перевірити явно — у legacy-проектах вони часто відключені «щоб не сломалось». Повний ProGuard дає 30-50% скорочення розміру коду.
Після включення мініфікації обов'язково: тестування release-сборки (не debug), додавання правил у proguard-rules.pro для reflection-heavy бібліотек (Gson, Retrofit, Room міграції), Crashlytics з mapping.txt для читабельних стектрейсів.
Ресурси. webp замість PNG/JPEG для всіх растрових зображень, крім випадків де прозорість з артефактами недопустима. Android Studio підтримує конвертацію прямо з IDE. Векторні drawables замість PNG для іконок та простої графіки — розмір вектора 1-3 КБ проти 50-200 КБ набору PNG для різних щільностей.
Unused resources: shrinkResources true видаляє невикористовувані ресурси автоматично. Але ресурси, підключені динамічно через Resources.getIdentifier(), можуть бути помилково видалені — потрібен keep.xml файл.
Нативні бібліотеки (.so). Якщо проект включає NDK-бібліотеки, перевіряємо список ABI: abiFilters 'arm64-v8a', 'x86_64' для production. armeabi-v7a потрібен лише якщо підтримуєте пристрої до 2014 року. Кожен лишній ABI — копія всіх .so файлів.
iOS: App Thinning та Bitcode
App Store автоматично застосовує App Thinning: різні варіанти сборки для різних пристроїв (2x/3x assets, arm64 лише для сучасних пристроїв). У Xcode Organizer → App Size Report можна побачити розмір сборки для конкретних типів пристроїв.
Assets.xcassets. Зображення мають бути саме там, а не в bundle безпосередньо — лише так працює Asset Catalog Compiler та App Thinning. WebP підтримується з iOS 14. PDF для vector assets у Asset Catalog — зручно, але Xcode растеризує їх при сборці, реальних переваг розміру не дає. SVG через UIGraphicsImageRenderer або SwiftUI Image з systemName для SF Symbols.
On-Demand Resources. Для програм з великою кількістю контенту (ігри, освіта) — розбиття ресурсів на теги та завантаження за потребою. Початковий розмір скачування мінімальний, ресурси підтягуються по мірі прохождення.
Дублюючі залежності. CocoaPods та Swift Package Manager можуть включити одну бібліотеку двічі в різних версіях. otool -L на бінарнику або аналіз через bloaty покаже реальний внесок кожного фреймворку.
Аудит залежностей — нередко дає більший ефект
Найпростіший спосіб скоротити розмір — убрати невикористовувані залежності. SDK, який підключили «на всякий випадок», SDK, від якого залишилась одна функція — кандидати на видалення.
| Тип залежності | Типичний внесок у розмір |
|---|---|
| Рекламні SDK (AdMob, IronSource) | 3-8 МБ |
| ML-бібліотеки (TensorFlow Lite, Core ML моделі) | 5-50 МБ |
| Аналітика (Firebase, Amplitude) | 1-3 МБ |
| Карти (Google Maps SDK) | 8-15 МБ |
Firebase можна підключати модульно — лише потрібні компоненти, без pod 'Firebase' який тащить все відразу.
Термін оптимізації: три-сім робочих днів: аудит залежностей та конфігурації сборки, реалізація змін, вимірювання результату.