Prestaties in mobiele ontwikkeling: wat het is, welke metrieken en hoe te verbeteren

Waarom is de app traag?

App-prestaties zijn direct gerelateerd aan jank — een merkbare vertraging tussen gebruikersactie en UI-reactie. Belangrijkste oorzaken: blokkering van de hoofdthread (zware bewerkingen op de UI-thread), frequente hertekeningen van de lay-out (overdraw), geheugenlekken (frequente GC), niet-optimale algoritmen (O(n²) op grote datasets). Frame Rate (FPS) — aantal frames per seconde. Voor een comfortabele ervaring zijn stabiele 60 FPS (Android) of 120 FPS (iPhone Pro, iPad Pro) nodig. VSync synchroniseert het renderen met de verversingssnelheid van het scherm.

Jank treedt op wanneer het renderen van een enkel frame 16,6 ms (voor 60 FPS) of 8,3 ms (voor 120 FPS) overschrijdt. GPU-profilering (Profile GPU Rendering op Android, Core Animation op iOS) laat zien welke renderfasen de meeste tijd in beslag nemen. Belangrijkste fasen: Layout (positionering van elementen), Draw (tekenen), Display (overdracht naar framebuffer). Het meest voorkomende probleem is lay-outinflatie in XML, vooral bij het gebruik van complexe geneste ConstraintLayouts.

Time-to-Interactive (TTI) — de tijd die de app nodig heeft om volledig klaar te zijn voor interactie. TTI omvat Cold Start, gegevens laden en bibliotheekinitialisatie. Google adviseert TTI onder 5 seconden, Apple — onder 2 seconden voor hoofdschermen. Lazy Loading — techniek van uitgesteld laden van inhoud en bibliotheken, cruciaal voor het verbeteren van TTI. Bij IT Sectr gebruiken we standaard lazy initialisatie in alle projecten.

ANR en Crash

ANR en Crash zijn de belangrijkste vijanden van mobiele app-prestaties. ANR (Application Not Responding) — dialoogvenster op Android dat verschijnt als de hoofdthread langer dan 5 seconden is geblokkeerd. Oorzaken: synchrone netwerkverzoeken op de UI-thread, databasewerk zonder coroutines, grote bitmapdecodering zonder downsampling, deadlock op de hoofdthread. De ANR-aanroepstack wordt opgeslagen in /data/anr/traces.txt en maakt het mogelijk de exacte blokkeringslocatie te bepalen.

Crash — onverwacht beëindigen van de app. Op Android — een Exception (Java/Kotlin) of Signal (native code). Op iOS — NSException of signaal (EXC_BAD_ACCESS — toegang tot vrijgemaakt geheugen). Crash Reporting-tools: Firebase Crashlytics, Sentry, BugSnag. Ze verzamelen stacktrace, apparaatgegevens en reproductiestappen. Stack Overflow — overloop van de aanroepstack door oneindige recursie. OutOfMemoryError — wanneer de heap vol is.

StrictMode — Android-tool voor het detecteren van threadveiligheidsschendingen. Hiermee kunnen regels worden ingesteld: ThreadPolicy (schijf/netwerk op de hoofdthread verbieden), VmPolicy (lekken van Activity, SQLite, CloseGuard detecteren). StrictMode moet alleen worden ingeschakeld in debug-builds — in de release zou het niet moeten werken. Het iOS-equivalent is Main Thread Checker (Xcode), die automatisch UIKit-aanroepen detecteert die niet op de hoofdthread plaatsvinden.

Geheugenbeheer (GC, ARC, Retain Cycle)

Geheugenlek

Een geheugenlek (Memory Leak) is een situatie waarin een object in het geheugen blijft, ook al gebruikt de app het niet meer. Dit vermindert direct de app-prestaties. Op Android kan GC (Garbage Collection) een object niet verzamelen als er een sterke referentie naar bestaat. Typische oorzaken: statische referenties naar Activity, niet-geannuleerde callbacks/observers, innerlijke klassen met impliciete referentie naar de buitenste klasse, Handler met niet-gewiste berichten. LeakCanary — bibliotheek voor automatische lekdetectie.

Retain Cycle

ARC (Automatic Reference Counting) — geheugenbeheermodel in iOS. Elk object heeft een referentieteller (retain count). Wanneer de teller nul bereikt, wordt het geheugen vrijgemaakt. Een Retain Cycle treedt op wanneer twee objecten sterke referenties naar elkaar hebben (A → B en B → A). ARC zal de tellers nooit op nul zetten. Oplossing: zwakke (weak) of ongeëigende (unowned) referenties. Weak wordt automatisch nil wanneer het object wordt vrijgemaakt. Unowned wordt niet nil maar garandeert dat het object leeft.

GC vs ARC

GC (Garbage Collection) werkt op Android (Java/Kotlin). GC pauzeert periodiek de uitvoering (Stop-the-World-pauze) om onbereikbare objecten te vinden en vrij te maken. GC-trigger: wanneer de heap een bepaald percentage vulling bereikt. ARC werkt op iOS (Swift/Objective-C) en heeft geen pauzes — tellers worden atomair bijgewerkt bij elke toewijzing. ARC is voorspelbaarder, maar kan overmatige retain/release-bewerkingen ophopen bij hoge toewijzingsfrequentie.

Zwakke referentie (Weak Reference) en sterke referentie (Strong Reference) — het referentietype bepaalt of GC/ARC het object kan vrijmaken. Strong Reference — het object wordt niet verzameld zolang deze referentie bestaat. Weak Reference — GC/ARC kan het object verzamelen; de zwakke referentie wordt nil (in Swift/Java WeakReference). Unowned Reference (Swift) — wordt niet nil bij vrijgave; toegang erna na de dood van het object veroorzaakt een crash. Op Android wordt java.lang.ref.WeakReference gebruikt voor zwakke referenties.

Voorbeeld van lekdetectie op Android met LeakCanary:

// Утечка: анонимный класс держит ссылку на Activity
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        val handler = object : Handler(Looper.getMainLooper()) {
            override fun handleMessage(msg: Message) {
                // Используем `this@MainActivity`, сохраняя ссылку на Activity
                Log.d("TAG", "Handler received message")
            }
        }
        handler.sendEmptyMessageDelayed(0, 60000)
    }
}

// Исправление: статический Handler + WeakReference
class SafeHandler(activity: MainActivity) : Handler() {
    private val weakActivity =
        WeakReference(activity)

    override fun handleMessage(msg: Message) {
        weakActivity.get() ?: return
        Log.d("TAG", "Handler received message")
    }
}

Profilering (Instruments, Android Profiler)

Profilering is het proces van het meten van app-prestaties: CPU, geheugen, netwerk, energieverbruik. Zonder profilering is blinde optimalisatie nutteloos — u weet niet welk deel van de code daadwerkelijk traag is.

Instruments (Xcode) — de krachtigste tool voor iOS. Time Profiler toont welke functies het meest CPU verbruiken. Allocations volgt het maken en vrijmaken van objecten. Leaks vindt automatisch retain cycles. Profileringstappen: (1) start Instruments; (2) selecteer sjabloon (Time Profiler voor CPU); (3) voer het problematische scenario uit; (4) analyseer de aanroepstack — de breedste kolom is de heetste functie.

Android Profiler is ingebouwd in Android Studio (View → Tool Windows → Profiler). CPU Profiler toont de belasting van elke thread. Memory Profiler — heap dump en toewijzingstracking. Network Profiler — alle HTTP-verzoeken met timing. Energy Profiler — energieverbruik: WakeLock, Location, Network. Voor gedetailleerde tracering wordt Systrace (Android 10+) of Perfetto gebruikt — systeemtracering met microsecondeprecisie.

App-opstart (Cold/Warm/Hot Start)

App-opstart is een van de belangrijkste prestatie-indicatoren. Het is onderverdeeld in drie typen: Cold Start — de app wordt vanaf nul gestart: proces wordt aangemaakt, Application.onCreate (Android) / AppDelegate.applicationDidFinishLaunching (iOS), klassen laden, bibliotheken initialiseren. Warm Start — het proces bestaat, maar de Activity/ViewController is vernietigd (bijvoorbeeld bij schermrotatie of terugkeer uit geheugen). Hot Start — Activity/ViewController is in geheugen, de app wordt gewoon weergegeven (overschakelen van een andere app).

Cold Start is de belangrijkste metriek. Op Android omvat het: (1) launch Activity — XML laden, View initialiseren; (2) eerste frame — tijd tot eerste render. Google adviseert: launch Activity < 200 ms, eerste frame < 500 ms, TTI < 5 seconden. Cold Start-optimalisatie: verminder Application.onCreate (coroutines voor lazy initialisatie), gebruik SplashScreen API (Android 12+), stel bibliotheekinitialisatie uit (WorkManager, DI), verwijder overbodige ContentProviders.

Op iOS omvat Cold Start: laden van Mach-O binair bestand, dyld (dynamische linker), initialisatie van Objective-C runtime, application delegate, eerste controller. Chrome Custom Tabs (Android) en Universal Links (iOS) — technologieën voor het snel openen van externe inhoud in de app zonder volledige Cold Start. Het wordt aanbevolen Cold Start te testen op echte middenklasse apparaten.

Grootte-optimalisatie

App-grootte is een prestatiefactor voor installatie en updates. Het beïnvloedt de conversie: elke 10 MB vermindert de conversie met 1%. Google Play adviseert APK-grootte onder 150 MB; App Store — onder 200 MB (mobiele netwerken — 100 MB). Belangrijkste optimalisatiemethoden: beeldcompressie (WebP in plaats van PNG bespaart 25-35%), vectorisatie (VectorDrawable op Android, SF Symbols op iOS), verwijdering van ongebruikte code (R8/ProGuard), verwijdering van ongebruikte bronnen (lint → unused resources).

App Bundle (Android) — een publicatieformaat waarbij Google Play een geoptimaliseerde APK voor elk apparaat genereert. App Bundle vermindert de downloadgrootte met 20-40%. Dynamic Delivery — modules die op aanvraag worden gedownload (on-demand feature modules). Het iOS-equivalent is On-Demand Resources (ODR): bronnen die na de eerste start worden gedownload (spelniveaus, video's).

Lazy Loading — techniek waarbij modules en bibliotheken niet bij het opstarten worden geladen, maar naar behoefte. Split APK (Android) en App Slicing (iOS) — verdeling van de app in architectuurslots: arm64-v8a, x86_64. App-grootte optimalisatie — een continu proces: analyseer de APK-samenstelling (Analyze APK in Android Studio), verwijder dubbele pictogrammen, gebruik SVG in plaats van meerdere PNG-dichtheden. Bij IT Sectr nemen we de buildgroottecontrole op in CI/CD voor elke MR.