Оптимізація розміру збірки (App Size) мобільного застосунку
Ваш застосунок важить 120 МБ, і конверсія при завантаженні через мобільну мережу падає на 30%? Ми стикалися з такими проєктами не раз. За даними Google, кожен додатковий мегабайт знижує конверсію приблизно на 1% на пристроях з повільним інтернетом. Android встановлює ліміт завантаження без Wi-Fi у 200 МБ, iOS App Store попереджає при завантаженні через стільникову мережу понад 200 МБ. Це не абстрактні метрики — це реальні бар'єри для встановлення. Наш досвід показує, що оптимізація розміру збірки під ключ дозволяє зменшити APK/IPA на 30-60% без втрати функціональності, при цьому вкладаючись у 3-7 робочих днів. Ми гарантуємо вимірюваний результат: до та після.
Чому App Size важливий для конверсії?
Кожен мегабайт — це потенційно втрачений користувач. Особливо в регіонах з повільним інтернетом або дорогим тарифом. Багато користувачів завантажують застосунки тільки при Wi-Fi, а попередження про великий розмір знижують ймовірність встановлення. На сертифікованих iOS та Android пристроях ми бачили пряму кореляцію: зменшення розміру на 10 МБ збільшувало конверсію на 5-10%.
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 допомагає зменшити розмір?
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 файл.
Що робити з нативними бібліотеками?
Якщо проєкт включає 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' який тягне все одразу.
Порівняння технік оптимізації
| Метод | Типове скорочення | Трудомісткість |
|---|---|---|
| R8/ProGuard + shrinkResources | 30-50% | 1-2 дні |
| AAB (Android) | 20-40% | 1 день |
| WebP та векторизація | 10-30% | 1-2 дні |
| Видалення невикористовуваних залежностей | 5-30% | 1-3 дні |
| App Thinning + ODR (iOS) | 15-30% | 2-3 дні |
Процес роботи
- Аналіз вихідної збірки — вимірюємо розмір на різних пристроях за допомогою APK Analyzer, App Size Report.
- Визначення пріоритетних напрямків — виявляємо «жирні» компоненти.
- Реалізація змін — налаштування AAB, ProGuard, конвертація ресурсів.
- Тестування — релізна збірка на всіх цільових пристроях без падінь та багів.
- Деплой в stores — публікація оптимізованої версії.
Що входить в роботу?
- Аудит поточної конфігурації збірки (Gradle, Xcode)
- Аналіз залежностей та рекомендації щодо видалення
- Налаштування ProGuard/R8 з підтримкою всіх бібліотек
- Конвертація ресурсів в WebP
- Перехід на AAB (Android) та налаштування App Thinning (iOS)
- Документація внесених змін
- Підтримка при публікації в App Store та Google Play
Строки та вартість
Строк оптимізації — від 3 до 7 робочих днів. Вартість розраховується індивідуально після оцінки проєкту. Ми виконуємо роботи віддалено або на вашому майданчику. Наш досвід — 10+ років у мобільній розробці, 200+ успішних проєктів. Отримайте безкоштовну консультацію: зв'яжіться з нами, і ми проаналізуємо вашу збірку та запропонуємо план оптимізації.