Оптимизация размера сборки (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+ успешных проектов. Получите бесплатную консультацию: свяжитесь с нами, и мы проанализируем вашу сборку и предложим план оптимизации.