App Size Optimization w tworzeniu aplikacji mobilnych: podstawy, metody i praktyki

Czym jest App Size Optimization

App Size Optimization — dyscyplina tworzenia aplikacji mobilnych mająca na celu minimalizację rozmiaru pakietu instalacyjnego aplikacji. Obejmuje usuwanie martwego kodu i zasobów, kompresję obrazów, optymalizację bibliotek, fragmentację kompilacji dla różnych architektur oraz wykorzystanie technologii dostawy na żądanie.

Rozmiar aplikacji wpływa nierównomiernie na różne segmenty użytkowników. W regionach z rozwiniętą infrastrukturą mobilną (USA, Europa, Japonia) różnica między 50 a 100 MB może być niezauważalna. W regionach rozwijających się (Indie, Indonezja, Brazylia) każdy dodatkowy megabajt zmniejsza konwersję instalacji z powodu limitów taryfowych i prędkości mobilnego internetu. Google Play ogranicza rozmiar APK do 200 MB, ale zaleca utrzymywanie rozmiaru poniżej 100 MB.

Dla iOS App Store maksymalny rozmiar pobierania przez sieć komórkową to 200 MB (do 2023 roku było 150 MB). Jeśli IPA przekracza ten limit, użytkownik może zainstalować aplikację tylko przez Wi-Fi. Apple obsługuje również App Thinning, który obejmuje Slicing, Bitcode i On-Demand Resources — technologie automatycznie zmniejszające rozmiar instalacji na konkretnym urządzeniu bez udziału programisty.

Dlaczego rozmiar aplikacji ma znaczenie

Rozmiar aplikacji wpływa nie tylko na konwersję instalacji, ale także na retention, częstotliwość aktualizacji i szybkość pierwszego uruchomienia. Każdy dodatkowy megabajt to bariera między użytkownikiem a korzystaniem z Twojego produktu.

Wpływ na konwersję instalacji

Według danych Google I/O 2024, zmniejszenie APK o 10 MB zwiększa konwersję instalacji średnio o 3,5%. Dla aplikacji o rozmiarze 150+ MB konwersja może być o 20–30% niższa niż dla aplikacji tej samej klasy o rozmiarze 50 MB. Efekt jest szczególnie widoczny w Google Play, gdzie użytkownik widzi rozmiar przed instalacją. W App Store rozmiar jest wyświetlany na stronie aplikacji, a użytkownicy z limitowanym tarifem odkładają instalację na Wi-Fi, po czym często zapominają o aplikacji.

Częstotliwość aktualizacji i aktualizacja przez sieć

Duża aplikacja rzadziej aktualizuje się przez sieć — użytkownicy odkładają pobieranie poprawek na Wi-Fi, pomijając krytyczne poprawki bezpieczeństwa. Google Play umożliwia korzystanie z Incremental Updates (poprawki o rozmiarze do 10 MB), ale pełna reinstalacja i tak pobiera cały APK lub AAB. Apple App Store używa Delta Updates, przesyłając tylko zmienione pliki, ale nawet delta może być znacząca przy zmianie zasobów.

Pierwsze uruchomienie i rozpakowywanie

Rozmiar bezpośrednio wpływa na czas pierwszego uruchomienia: aplikacja musi rozpakować zasoby, skompilować kod (Android) lub podpisać pamięć podręczną (iOS). Aplikacja o rozmiarze 200 MB może uruchamiać się o 10–15 sekund dłużej niż aplikacja o rozmiarze 50 MB na średnim urządzeniu. To pogarsza Onboarding Experience — użytkownik może zamknąć aplikację, nie czekając na załadowanie.

Optymalizacja zasobów i assetów

Zasoby — obrazy, czcionki, dźwięki, wideo — stanowią 60–80% rozmiaru typowej aplikacji mobilnej. Optymalizacja zasobów daje największy zysk przy minimalnym nakładzie pracy. Główne kierunki: kompresja, usuwanie duplikatów i nieużywanych assetów, wybór odpowiednich formatów.

Optymalizacja obrazów

WebP — format obrazów od Google, zapewniający o 25–35% lepszą kompresję niż PNG i o 15–20% lepszą niż JPEG przy tej samej jakości wizualnej. Android obsługuje WebP natywnie od API 18. Dla iOS WebP jest obsługiwany przez bibliotekę SDWebImage lub Kingfisher, a od iOS 17 pojawiło się natywne wsparcie. AVIF — bardziej nowoczesny format, dający dodatkowe 10–15% oszczędności względem WebP, ale z wolniejszym dekodowaniem.

Usuwanie nieużywanych zasobów — najprostszy sposób na zmniejszenie rozmiaru. W Androidzie użyj refaktoryzacji w Android Studio: Analyze → Run Inspection → Unused Resources. W iOS — Build Settings → Remove Unused Resources. Często w projektach pozostają sprite'y z wcześniejszych wersji, stare ikony, nieużywane obrazy ekranu startowego, które powiekszają rozmiar bez żadnego obciążenia funkcjonalnego.

Optymalizacja czcionek i dźwięków

Niestandardowe czcionki mogą zajmować 5–15 MB, szczególnie jeśli podłączona jest cała garnitura (wszystkie kroje: Regular, Bold, Italic, BoldItalic). Używaj tylko niezbędnych krojów i podzbiorów znaków poprzez subsetting — usuwanie glifów dla języków nieobsługiwanych przez aplikację. Usługi takie jak Google Fonts i Transfonter pozwalają utworzyć minimalny zestaw znaków. Dla dźwięków używaj AAC/HE-AAC zamiast WAV i nieskompresowanych formatów — oszczędność do 90% bez utraty jakości.

Optymalizacja kodu i bibliotek

Kod stanowi 20–40% rozmiaru aplikacji, ale jego optymalizacja jest trudniejsza niż zasobów, ponieważ wymaga analizy zależności, obfuskacji i usuwania martwego kodu bez ryzyka złamania funkcjonalności.

ProGuard i R8 dla Androida

ProGuard — narzędzie dla Androida wykonujące obfuskację, minifikację i optymalizację kodu. R8 — jego następca, wbudowany w Android Gradle Plugin, działający szybciej i wydajniej. R8 usuwa nieużywane klasy i metody, skraca nazwy zmiennych i przepisuje kod w celu zmniejszenia liczby instrukcji. Typowe zmniejszenie rozmiaru plików DEX za pomocą R8 to 30–50%.

// build.gradle — konfiguracja R8 do minifikacji
android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt')
            shrinkResources true
        }
    }
}

Optymalizacja bibliotek i zależności

Biblioteki — częsta przyczyna rozdmuchanego rozmiaru. Jedna biblioteka może ciągnąć zależności tranzytowe, które zwiększają rozmiar o 5–20 MB bez bezpośredniej korzyści dla aplikacji. Używaj Gradle Version Catalog dla Androida i Swift Package Manager dla iOS z jawnym określeniem zależności. Analizuj rozmiar za pomocą Build Analyzer w Android Studio lub Xcode Build Timeline. Zastępuj ciężkie biblioteki lżejszymi alternatywami: na przykład OkHttp (3 MB) zamiast Apache HTTP (15 MB).

Usuwanie nieużywanego kodu w iOS

Dead Code Stripping — automatyczne usuwanie nieużywanych metod i klas na etapie linkowania w Xcode. Włącza się przez Build Settings → Dead Code Stripping = YES. Bitcode — reprezentacja pośrednia, którą Apple może przekompilować dla różnych architektur, usuwając nieużywane funkcje. Jednak od Xcode 14 Bitcode stał się opcjonalny, a jego wkład w zmniejszenie rozmiaru wynosi 5–15% dla projektów Objective-C i mniej dla Swift.

App Thinning i dostawa na żądanie

App Thinning — technologia Apple automatycznie zmniejszająca rozmiar instalowanej aplikacji poprzez dostarczanie tylko tych zasobów, które są niezbędne konkretnemu urządzeniu. Składa się z trzech komponentów: Slicing, On-Demand Resources i Bitcode. W Androidzie odpowiednikiem jest Android App Bundle (AAB) z Dynamic Delivery.

Android App Bundle (AAB)

AAB — format publikacji w Google Play, w którym sklep generuje APK dla każdego urządzenia osobno, uwzględniając tylko zasoby dla jego architektury (armeabi-v7a, arm64-v8a), gęstości ekranu (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi) i języków. Typowe zmniejszenie rozmiaru instalacji przy przejściu z uniwersalnego APK na AAB wynosi 20–40%. Play Feature Delivery umożliwia pobieranie modułów na żądanie, a moduły Install-time są dołączane do podstawowej instalacji.

// build.gradle — konfiguracja AAB i Dynamic Features
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}

On-Demand Resources w iOS

On-Demand Resources (ODR) — mechanizm iOS, w którym zasoby (poziomy gry, obrazy w wysokiej rozdzielczości, wideo) są pobierane z serwerów Apple tylko wtedy, gdy są rzeczywiście potrzebne użytkownikowi. Rozmiar początkowej instalacji może być zmniejszony o 50–80%. Zasoby dzielą się na trzy kategorie: Initial Install Tags (pobierane podczas instalacji), Prefetched Tag Order (pobierane w tle po instalacji) i On-Demand (pobierane tylko na żądanie). Apple zaleca używanie ODR dla treści, które nie są potrzebne na pierwszym ekranie: poziomy gry, dodatkowa treść, instrukcje wideo.

SwiftUI obsługuje ODR przez atrybut Bundle.module, a UIKit przez NSBundleResourceRequest. Dla gier na Unity i Unreal Engine ODR jest zintegrowany na poziomie natywnej otoczki. Główne ograniczenie — zasoby ODR są usuwane przez system przy braku miejsca, dlatego dane krytyczne dla działania muszą być dołączone do głównej kompilacji.