App Size Optimization у мобільній розробці: основи, методи та практики

Що таке App Size Optimization

App Size Optimization — дисципліна мобільної розробки, спрямована на мінімізацію розміру інсталяційного пакета застосунку. До неї входить видалення мертвого коду та ресурсів, стиснення зображень, оптимізація бібліотек, фрагментація збірки під різні архітектури та використання технологій доставки на вимогу.

Розмір застосунку нерівномірно впливає на різні сегменти користувачів. У регіонах з розвиненою мобільною інфраструктурою (США, Європа, Японія) різниця між 50 та 100 МБ може бути непомітною. У регіонах, що розвиваються (Індія, Індонезія, Бразилія), кожен зайвий мегабайт знижує конверсію встановлень через ліміти тарифів та швидкість мобільного інтернету. Google Play обмежує розмір APK до 200 МБ, але рекомендує тримати його нижче 100 МБ.

Для iOS App Store максимальний розмір завантаження по стільниковій мережі — 200 МБ (до 2023 року було 150 МБ). Якщо IPA перевищує цей ліміт, користувач може встановити застосунок лише через Wi-Fi. Apple також підтримує App Thinning, який включає Slicing, Bitcode та On-Demand Resources — технології, що автоматично зменшують розмір встановлення на конкретному пристрої без участі розробника.

Чому розмір застосунку критичний

Розмір застосунку впливає не тільки на конверсію встановлень, але й на утримання, частоту оновлень та швидкість першого запуску. Кожен додатковий мегабайт — це бар'єр між користувачем та використанням вашого продукту.

Вплив на конверсію встановлень

Згідно з даними Google I/O 2024, зменшення APK на 10 МБ збільшує конверсію встановлень у середньому на 3.5%. Для застосунків розміром 150+ МБ конверсія може бути на 20–30% нижчою, ніж для застосунків того ж класу розміром 50 МБ. Ефект особливо виражений у Google Play, де користувач бачить розмір до встановлення. В App Store розмір показується на сторінці застосунку, і користувачі з лімітованим тарифом відкладають встановлення на Wi-Fi, після чого часто забувають про застосунок.

Частота оновлень та оновлення по повітрю

Великий застосунок рідше оновлюється по повітрю — користувачі відкладають завантаження патчів на Wi-Fi, пропускаючи критичні виправлення безпеки. Google Play дозволяє використовувати Incremental Updates (патчі розміром до 10 МБ), але повне перевстановлення все одно завантажує повний APK або AAB. Apple App Store використовує Delta Updates, передаючи лише змінені файли, але навіть дельта може бути значною при зміні ресурсів.

Перший запуск та розпакування

Розмір безпосередньо впливає на час першого запуску: застосунок повинен розпакувати ресурси, скомпілювати код (Android) або підписати кеш (iOS). Застосунок розміром 200 МБ може запускатися на 10–15 секунд довше, ніж застосунок розміром 50 МБ на середньому пристрої. Це погіршує Досвід входження — користувач може закрити застосунок, не дочекавшись завантаження.

Оптимізація ресурсів та асетів

Ресурси — зображення, шрифти, звуки, відео — становлять 60–80% розміру типового мобільного застосунку. Оптимізація ресурсів дає найбільший виграш при мінімальних трудовитратах. Основні напрямки: стиснення, видалення дублікатів та невикористовуваних асетів, вибір правильних форматів.

Оптимізація зображень

WebP — формат зображень від Google, що забезпечує на 25–35% краще стиснення, ніж PNG, та на 15–20% краще, ніж JPEG, при тій самій візуальній якості. Android підтримує WebP нативно з API 18. Для iOS WebP підтримується через бібліотеку SDWebImage або Kingfisher, а з iOS 17 з'явилася нативна підтримка. AVIF — більш сучасний формат, що дає ще 10–15% економії відносно WebP, але з більш повільним декодуванням.

Видалення невикористовуваних ресурсів — найпростіший спосіб зменшити розмір. В Android використовуйте рефакторинг з Android Studio: Analyze → Run Inspection → Unused Resources. В iOS — Build Settings → Remove Unused Resources. Часто в проектах залишаються спрайти з ранніх версій, старі іконки, невикористовувані launch screen-зображення, які роздувають розмір без будь-якого функціонального навантаження.

Оптимізація шрифтів та звуків

Кастомні шрифти можуть займати 5–15 МБ, особливо якщо підключено всю гарнітуру (всі накреслення: Regular, Bold, Italic, BoldItalic). Використовуйте лише необхідні накреслення та підмножини символів через subsetting — видалення гліфів для мов, не підтримуваних застосунком. Сервіси на кшталт Google Fonts та Transfonter дозволяють створити мінімальний набір символів. Для звуків використовуйте AAC/HE-AAC замість WAV та нестиснених форматів — економія до 90% без втрати якості.

Оптимізація коду та бібліотек

Код становить 20–40% розміру застосунку, але його оптимізація складніша, ніж ресурсів, тому що вимагає аналізу залежностей, обфускації та видалення мертвого коду без ризику зламати функціональність.

ProGuard та R8 для Android

ProGuard — інструмент для Android, що виконує обфускацію, мініфікацію та оптимізацію коду. R8 — його наступник, вбудований в Android Gradle Plugin, що працює швидше та ефективніше. R8 видаляє невикористовувані класи та методи, скорочує імена змінних та переписує код для зменшення кількості інструкцій. Типове зменшення розміру DEX-файлів за допомогою R8 — 30–50%.

// build.gradle — налаштування R8 для мініфікації
android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt')
            shrinkResources true
        }
    }
}

Оптимізація бібліотек та залежностей

Бібліотеки — часта причина роздутого розміру. Одна бібліотека може тягнути транзитивні залежності, які збільшують розмір на 5–20 МБ без прямої користі для застосунку. Використовуйте Gradle Version Catalog для Android та Swift Package Manager для iOS з явним зазначенням залежностей. Аналізуйте розмір за допомогою Build Analyzer в Android Studio або Xcode Build Timeline. Замінюйте важкі бібліотеки на більш легкі альтернативи: наприклад, OkHttp (3 МБ) замість Apache HTTP (15 МБ).

Видалення невикористовуваного коду в iOS

Dead Code Stripping — автоматичне видалення невикористовуваних методів та класів на етапі лінковки в Xcode. Вмикається через Build Settings → Dead Code Stripping = YES. Bitcode — проміжне представлення, яке Apple може перекомпілювати під різні архітектури, видаляючи невикористовувані функції. Однак з Xcode 14 Bitcode став опціональним, а його внесок у зменшення розміру становить 5–15% для Objective-C проектів і менше для Swift.

App Thinning та доставка на вимогу

App Thinning — технологія Apple, що автоматично зменшує розмір встановлюваного застосунку за рахунок доставки лише тих ресурсів, які необхідні конкретному пристрою. Складається з трьох компонентів: Slicing, On-Demand Resources та Bitcode. В Android аналогом є Android App Bundle (AAB) з Dynamic Delivery.

Android App Bundle (AAB)

AAB — формат публікації в Google Play, при якому магазин генерує APK для кожного пристрою окремо, включаючи лише ресурси для його архітектури (armeabi-v7a, arm64-v8a), щільності екрану (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi) та мов. Типове зменшення розміру встановлення при переході з універсального APK на AAB становить 20–40%. Play Feature Delivery дозволяє завантажувати модулі на вимогу, а Install-time модулі — включати в базове встановлення.

// build.gradle — налаштування AAB та Dynamic Features
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}

On-Demand Resources в iOS

On-Demand Resources (ODR) — механізм iOS, при якому ресурси (рівні гри, зображення високої роздільної здатності, відео) завантажуються з серверів Apple лише тоді, коли вони реально потрібні користувачеві. Розмір початкового встановлення може бути зменшений на 50–80%. Ресурси діляться на три категорії: Initial Install Tags (завантажуються при встановленні), Prefetched Tag Order (завантажуються у фоні після встановлення) та On-Demand (завантажуються лише за запитом). Apple рекомендує використовувати ODR для контенту, який не потрібен на першому екрані: рівні гри, додатковий контент, відеоінструкції.

SwiftUI підтримує ODR через атрибут Bundle.module, а UIKit — через NSBundleResourceRequest. Для ігор на Unity та Unreal Engine ODR інтегрується на рівні нативної обв'язки. Головне обмеження — ODR-ресурси видаляються системою при нестачі місця, тому критичні для роботи дані повинні бути включені в основну збірку.