App Size Optimization mobilalkalmazás-fejlesztésben: alapok, módszerek és gyakorlatok

Mi az App Size Optimization

App Size Optimization — a mobilalkalmazás-fejlesztés azon területe, amely az alkalmazás telepítőcsomagjának méretének minimalizálására irányul. Magában foglalja a holt kód és erőforrások eltávolítását, a képek tömörítését, a könyvtárak optimalizálását, a fordítás fragmentálását különböző architektúrákra, valamint az igény szerinti szállítási technológiák használatát.

Az alkalmazás mérete egyenlőtlenül befolyásolja a különböző felhasználói szegmenseket. A fejlett mobil infrastruktúrával rendelkező régiókban (USA, Európa, Japán) az 50 és 100 MB közötti különbség észrevehetetlen lehet. A fejlődő régiókban (India, Indonézia, Brazília) minden további megabájt csökkenti a telepítési konverziót a tarifakorlátok és a mobil internet sebessége miatt. Google Play 200 MB-ra korlátozza az APK méretét, de javasolja a méret 100 MB alatt tartását.

Az iOS App Store esetében a mobilhálózaton keresztüli letöltés maximális mérete 200 MB (2023-ig 150 MB volt). Ha az IPA meghaladja ezt a határt, a felhasználó csak Wi-Fi-n keresztül telepítheti az alkalmazást. Az Apple támogatja az App Thinning-et is, amely magában foglalja a Slicing, Bitcode és On-Demand Resources technológiákat — amelyek automatikusan csökkentik a telepítés méretét egy adott eszközön a fejlesztő közreműködése nélkül.

Miért kritikus az alkalmazás mérete

Az alkalmazás mérete nemcsak a telepítési konverziót befolyásolja, hanem a megtartást, a frissítések gyakoriságát és az első indítás sebességét is. Minden további megabájt akadályt jelent a felhasználó és a termék használata között.

Hatás a telepítési konverzióra

A Google I/O 2024 adatai szerint az APK 10 MB-os csökkentése átlagosan 3,5%-kal növeli a telepítési konverziót. A 150+ MB méretű alkalmazások esetében a konverzió 20–30%-kal alacsonyabb lehet, mint az azonos osztályba tartozó 50 MB-os alkalmazásoknál. A hatás különösen a Google Play-ben érezhető, ahol a felhasználó a telepítés előtt látja a méretet. Az App Store-ban a méret az alkalmazás oldalán jelenik meg, és a korlátozott tarifával rendelkező felhasználók elhalasztják a telepítést Wi-Fi-ig, ami után gyakran elfelejtik az alkalmazást.

Frissítések gyakorisága és levegőn keresztüli frissítés

A nagy alkalmazás ritkábban frissül a levegőn keresztül — a felhasználók elhalasztják a javítások letöltését Wi-Fi-ig, kihagyva a kritikus biztonsági javításokat. A Google Play lehetővé teszi a Incremental Updates (legfeljebb 10 MB-os javítások) használatát, de a teljes újratelepítés továbbra is letölti a teljes APK-t vagy AAB-t. Az Apple App Store Delta Updates-t használ, csak a módosított fájlokat küldi el, de még a delta is jelentős lehet az erőforrások változásakor.

Első indítás és kicsomagolás

A méret közvetlenül befolyásolja az első indítás idejét: az alkalmazásnak ki kell csomagolnia az erőforrásokat, le kell fordítania a kódot (Android) vagy alá kell írnia a gyorsítótárat (iOS). Egy 200 MB-os alkalmazás 10–15 másodperccel később indulhat, mint egy 50 MB-os alkalmazás egy átlagos eszközön. Ez rontja az Onboarding Experience-t — a felhasználó bezárhatja az alkalmazást anélkül, hogy megvárná a betöltést.

Erőforrások és eszközök optimalizálása

Erőforrások — képek, betűtípusok, hangok, videók — egy tipikus mobilalkalmazás méretének 60–80%-át teszik ki. Az erőforrások optimalizálása minimális erőfeszítéssel a legnagyobb nyereséget adja. A fő irányok: tömörítés, duplikátumok és nem használt eszközök eltávolítása, megfelelő formátumok kiválasztása.

Képek optimalizálása

WebP — a Google képformátuma, amely 25–35%-kal jobb tömörítést biztosít, mint a PNG, és 15–20%-kal jobbat, mint a JPEG, azonos vizuális minőség mellett. Az Android natívan támogatja a WebP-t az API 18-tól kezdve. iOS-en a WebP az SDWebImage vagy Kingfisher könyvtáron keresztül támogatott, az iOS 17-től pedig natív támogatás is elérhető. AVIF — egy modernebb formátum, amely további 10–15% megtakarítást nyújt a WebP-hez képest, de lassabb dekódolással.

Nem használt erőforrások eltávolítása — a legegyszerűbb módja a méret csökkentésének. Androidon használja a refaktorálást az Android Studio-ban: Analyze → Run Inspection → Unused Resources. iOS-en — Build Settings → Remove Unused Resources. Gyakran a projektekben maradnak sprite-ok korábbi verziókból, régi ikonok, nem használt indítóképernyő képek, amelyek felfújják a méretet funkcionális teher nélkül.

Betűtípusok és hangok optimalizálása

Egyedi betűtípusok 5–15 MB-ot foglalhatnak, különösen ha a teljes család csatlakoztatva van (minden stílus: Regular, Bold, Italic, BoldItalic). Csak a szükséges stílusokat és karakterek részhalmazait használja a subsetting segítségével — a glifék eltávolítását az alkalmazás által nem támogatott nyelvekhez. Az olyan szolgáltatások, mint a Google Fonts és a Transfonter, lehetővé teszik egy minimális karakterkészlet létrehozását. Hangoknál használjon AAC/HE-AAC-ot a WAV és tömörítetlen formátumok helyett — akár 90% megtakarítás minőségromlás nélkül.

Kód és könyvtárak optimalizálása

Kód az alkalmazás méretének 20–40%-át teszi ki, de optimalizálása nehezebb, mint az erőforrásoké, mert függőségek elemzését, obfuszkációt és holt kód eltávolítását igényli a funkcionalitás megtörésének kockázata nélkül.

ProGuard és R8 Androidhoz

ProGuard — Android-eszköz, amely kód obfuszkációt, minifikációt és optimalizálást végez. R8 — az utódja, az Android Gradle Plugin-be építve, gyorsabban és hatékonyabban működik. Az R8 eltávolítja a nem használt osztályokat és metódusokat, lerövidíti a változóneveket, és átírja a kódot az utasítások számának csökkentése érdekében. A DEX-fájlok tipikus méretcsökkentése R8 segítségével 30–50%.

// build.gradle — az R8 konfigurálása minifikációhoz
android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt')
            shrinkResources true
        }
    }
}

Könyvtárak és függőségek optimalizálása

Könyvtárak — a felfújt méret gyakori oka. Egyetlen könyvtár olyan tranzitív függőségeket hozhat magával, amelyek 5–20 MB-tal növelik a méretet anélkül, hogy közvetlen hasznot hoznának az alkalmazás számára. Használjon Gradle Version Catalog-ot Androidhoz és Swift Package Manager-t iOS-hez a függőségek explicit megadásával. Elemezze a méretet a Build Analyzer segítségével az Android Studio-ban vagy az Xcode Build Timeline-ban. Cserélje le a nehéz könyvtárakat könnyebb alternatívákra: például OkHttp (3 MB) az Apache HTTP (15 MB) helyett.

Nem használt kód eltávolítása iOS-ben

Dead Code Stripping — a nem használt metódusok és osztályok automatikus eltávolítása a linkelési fázisban az Xcode-ban. A Build Settings → Dead Code Stripping = YES segítségével kapcsolható be. Bitcode — közbenső reprezentáció, amelyet az Apple újrafordíthat különböző architektúrákra, eltávolítva a nem használt függvényeket. Az Xcode 14-től azonban a Bitcode opcionálissá vált, és a méretcsökkentéshez való hozzájárulása 5–15% az Objective-C projektek esetében, és kevesebb a Swift esetében.

App Thinning és igény szerinti szállítás

App Thinning — az Apple technológiája, amely automatikusan csökkenti a telepített alkalmazás méretét azáltal, hogy csak az adott eszközhöz szükséges erőforrásokat szállítja. Három komponensből áll: Slicing, On-Demand Resources és Bitcode. Androidban az analóg az Android App Bundle (AAB) a Dynamic Delivery-vel.

Android App Bundle (AAB)

AAB — publikációs formátum a Google Play-ben, ahol az áruház minden eszközhöz külön APK-t generál, csak az adott eszköz architektúrájához (armeabi-v7a, arm64-v8a), képernyősűrűségéhez (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi) és nyelveihez szükséges erőforrásokat tartalmazva. A telepítési méret tipikus csökkentése az univerzális APK-ról AAB-re váltáskor 20–40%. A Play Feature Delivery lehetővé teszi a modulok igény szerinti letöltését, míg az Install-time modulok az alap telepítésbe kerülnek.

// build.gradle — az AAB és Dynamic Features konfigurálása
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}

On-Demand Resources iOS-ben

On-Demand Resources (ODR) — iOS-mechanizmus, amelyben az erőforrások (játékszintek, nagy felbontású képek, videók) csak akkor töltődnek le az Apple szervereiről, amikor a felhasználónak valóban szüksége van rájuk. A kezdeti telepítés mérete 50–80%-kal csökkenthető. Az erőforrások három kategóriába oszlanak: Initial Install Tags (telepítéskor töltődnek le), Prefetched Tag Order (telepítés után a háttérben töltődnek le) és On-Demand (csak kérésre töltődnek le). Az Apple az ODR használatát ajánlja olyan tartalmakhoz, amelyek nem szükségesek az első képernyőn: játékszintek, kiegészítő tartalom, videó útmutatók.

A SwiftUI támogatja az ODR-t a Bundle.module attribútumon keresztül, az UIKit pedig az NSBundleResourceRequest-on keresztül. A Unity és Unreal Engine játékok esetében az ODR natív szinten van integrálva. A fő korlátozás — az ODR-erőforrásokat a rendszer törli, ha nincs elég hely, ezért a működéshez kritikus adatokat bele kell foglalni a fő fordításba.