App Size Optimization i mobil utveckling: grunder, metoder och praxis

Vad är App Size Optimization

App Size Optimization — disciplin inom mobil utveckling som syftar till att minimera storleken på appens installationspaket. Det inkluderar borttagning av död kod och resurser, komprimering av bilder, optimering av bibliotek, fragmentering av kompilering för olika arkitekturer och användning av leverans-på-begäran-tekniker.

Appens storlek påverkar ojämnt olika användarsegment. I regioner med utvecklad mobil infrastruktur (USA, Europa, Japan) kan skillnaden mellan 50 och 100 MB vara omärkbar. I utvecklingsregioner (Indien, Indonesien, Brasilien) minskar varje extra megabyte installationskonverteringen på grund av tariffbegränsningar och mobil internethastighet. Google Play begränsar APK-storleken till 200 MB men rekommenderar att hålla storleken under 100 MB.

För iOS App Store är den maximala nedladdningsstorleken via mobilnätet 200 MB (fram till 2023 var det 150 MB). Om IPA överstiger denna gräns kan användaren bara installera appen via Wi-Fi. Apple stöder också App Thinning, som inkluderar Slicing, Bitcode och On-Demand Resources — tekniker som automatiskt minskar installationsstorleken på en specifik enhet utan utvecklarens inblandning.

Varför appens storlek är kritisk

Appens storlek påverkar inte bara installationskonverteringen, utan också retention, uppdateringsfrekvens och hastigheten för första start. Varje extra megabyte är en barriär mellan användaren och användningen av din produkt.

Inverkan på installationskonvertering

Enligt data från Google I/O 2024 ökar en minskning av APK med 10 MB installationskonverteringen med i genomsnitt 3,5%. För appar på 150+ MB kan konverteringen vara 20–30% lägre än för appar i samma klass på 50 MB. Effekten är särskilt märkbar i Google Play, där användaren ser storleken före installation. I App Store visas storleken på appsidan och användare med begränsad taxa skjuter upp installationen till Wi-Fi, varefter de ofta glömmer bort appen.

Uppdateringsfrekvens och uppdatering över luften

En stor app uppdateras mer sällan över luften — användare skjuter upp nedladdning av patchningar till Wi-Fi och missar kritiska säkerhetsuppdateringar. Google Play möjliggör användning av Incremental Updates (patchningar upp till 10 MB), men fullständig ominstallation laddar fortfarande ner hela APK eller AAB. Apple App Store använder Delta Updates, som endast skickar ändrade filer, men även deltat kan vara betydande vid ändring av resurser.

Första start och uppackning

Storleken påverkar direkt tiden för första starten: appen måste packa upp resurser, kompilera kod (Android) eller signera cache (iOS). En app på 200 MB kan starta 10–15 sekunder senare än en app på 50 MB på en genomsnittlig enhet. Detta försämrar Onboarding Experience — användaren kan stänga appen utan att vänta på inladdning.

Optimering av resurser och tillgångar

Resurser — bilder, typsnitt, ljud, video — utgör 60–80% av storleken på en typisk mobilapp. Optimering av resurser ger störst vinst med minimal ansträngning. Huvudriktningarna: komprimering, borttagning av dubbletter och oanvända tillgångar, val av rätt format.

Optimering av bilder

WebP — bildformat från Google som ger 25–35% bättre komprimering än PNG och 15–20% bättre än JPEG med samma visuella kvalitet. Android stöder WebP inbyggt från API 18. För iOS stöds WebP via biblioteket SDWebImage eller Kingfisher, och från iOS 17 finns inbyggt stöd. AVIF — ett mer modernt format som ger ytterligare 10–15% besparing jämfört med WebP, men med långsammare avkodning.

Borttagning av oanvända resurser — det enklaste sättet att minska storleken. I Android, använd omfaktorisering med Android Studio: Analyze → Run Inspection → Unused Resources. I iOS — Build Settings → Remove Unused Resources. Ofta finns det kvar sprites från tidigare versioner, gamla ikoner, oanvända startskärmsbilder som blåser upp storleken utan någon funktionell belastning.

Optimering av typsnitt och ljud

Anpassade typsnitt kan ta upp 5–15 MB, särskilt om hela familjen är ansluten (alla stilar: Regular, Bold, Italic, BoldItalic). Använd endast nödvändiga stilar och delmängder av tecken via subsetting — borttagning av glyfer för språk som inte stöds av appen. Tjänster som Google Fonts och Transfonter gör det möjligt att skapa en minimal teckenuppsättning. För ljud, använd AAC/HE-AAC istället för WAV och okomprimerade format — besparing upp till 90% utan kvalitetsförlust.

Optimering av kod och bibliotek

Kod utgör 20–40% av appens storlek, men dess optimering är svårare än resurser eftersom det kräver analys av beroenden, obfuskering och borttagning av död kod utan risk att bryta funktionaliteten.

ProGuard och R8 för Android

ProGuard — verktyg för Android som utför obfuskering, minifiering och optimering av kod. R8 — dess efterföljare, inbyggd i Android Gradle Plugin, arbetar snabbare och effektivare. R8 tar bort oanvända klasser och metoder, förkortar variabelnamn och skriver om kod för att minska antalet instruktioner. Typisk minskning av DEX-filstorlek med R8 är 30–50%.

// build.gradle — konfiguration av R8 för minifiering
android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt')
            shrinkResources true
        }
    }
}

Optimering av bibliotek och beroenden

Bibliotek — en vanlig orsak till uppblåst storlek. Ett enda bibliotek kan dra med sig transitiva beroenden som ökar storleken med 5–20 MB utan direkt nytta för appen. Använd Gradle Version Catalog för Android och Swift Package Manager för iOS med explicit angivande av beroenden. Analysera storleken med Build Analyzer i Android Studio eller Xcode Build Timeline. Byt ut tunga bibliotek mot lättare alternativ: till exempel OkHttp (3 MB) istället för Apache HTTP (15 MB).

Borttagning av oanvänd kod i iOS

Dead Code Stripping — automatisk borttagning av oanvända metoder och klasser i länkningsfasen i Xcode. Aktiveras via Build Settings → Dead Code Stripping = YES. Bitcode — mellanrepresentation som Apple kan kompilera om för olika arkitekturer, och ta bort oanvända funktioner. Från och med Xcode 14 har Bitcode dock blivit valfritt och dess bidrag till storleksminskning är 5–15% för Objective-C-projekt och mindre för Swift.

App Thinning och leverans på begäran

App Thinning — Apples teknik som automatiskt minskar storleken på den installerade appen genom att endast leverera de resurser som behövs för en specifik enhet. Består av tre komponenter: Slicing, On-Demand Resources och Bitcode. I Android är motsvarigheten Android App Bundle (AAB) med Dynamic Delivery.

Android App Bundle (AAB)

AAB — publiceringsformat i Google Play, där butiken genererar APK för varje enhet separat, med endast resurser för dess arkitektur (armeabi-v7a, arm64-v8a), skärmdensitet (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi) och språk. Typisk minskning av installationsstorlek vid övergång från universell APK till AAB är 20–40%. Play Feature Delivery gör det möjligt att ladda ner moduler på begäran, medan Install-time-moduler ingår i basinstallationen.

// build.gradle — konfiguration av AAB och Dynamic Features
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}

On-Demand Resources i iOS

On-Demand Resources (ODR) — iOS-mekanism där resurser (spelnivåer, högupplösta bilder, video) laddas ner från Apples servrar endast när de verkligen behövs av användaren. Storleken på den initiala installationen kan minskas med 50–80%. Resurser delas in i tre kategorier: Initial Install Tags (laddas ner vid installation), Prefetched Tag Order (laddas ner i bakgrunden efter installation) och On-Demand (laddas ner endast på begäran). Apple rekommenderar att använda ODR för innehåll som inte behövs på första skärmen: spelnivåer, extra innehåll, videoinstruktioner.

SwiftUI stöder ODR via attributet Bundle.module, och UIKit via NSBundleResourceRequest. För spel på Unity och Unreal Engine integreras ODR på nivån av det inbyggda gränssnittet. Den huvudsakliga begränsningen — ODR-resurser tas bort av systemet vid brist på utrymme, därför måste data som är kritiska för funktionen inkluderas i huvudkompileringen.