Lags in mobiele ontwikkeling: wat het is, oorzaken en oplossingen

Wat is lag in mobiele ontwikkeling

Lag (van het Engels lag) in een mobiele app is een subjectief voelbare vertraging tussen de actie van de gebruiker (aanraking, swipe, tekstinvoer) en de reactie van de interface. Technisch wordt lag gemeten als de tijd tussen de invoergebeurtenis en het volledig renderen van het frame: comfortabele drempel — tot 100 ms, merkbaar — vanaf 200 ms, kritisch — meer dan 500 ms.

Verschil tussen lag, bug en traagheid

In de gebruikersterminologie worden „lagnet” en „traag” vaak als synoniemen gebruikt, maar technisch is lag een vaste vertraging (bijv. 300 ms bij elke klik), terwijl „traag” een onregelmatige vertraging is: de app werkt soms vloeiend, soms bevriest hij een seconde. Een bug heeft, in tegenstelling tot lag, niet te maken met snelheid maar met de correctheid van de weergave.

Impact van lags op app-metrics

Google Play en App Store houden rekening met prestatie-indicatoren bij het rangschikken van apps. ANR-rate, jank-frequentie en opstarttijd beïnvloeden de zichtbaarheid in zoekopdrachten en de conversie van installaties. Een app met constante lags verliest tot 40% van de gebruikers na de eerste lancering.

Oorzaken van lags en vertragingen in apps

Lags ontstaan wanneer de hoofd-UI-thread frames niet kan verwerken met een snelheid van 60 FPS (16.6 ms per frame) of 120 FPS (8.3 ms). Laten we de belangrijkste bronnen van vertraging bekijken.

Blokkering van de hoofdthread

Elke synchrone bewerking in de UI-thread — lezen uit SharedPreferences, werken met de database via Room zonder suspend, decoderen van een afbeelding naar Bitmap — blokkeert het renderen van het frame. Op Android leidt dit tot overgeslagen frames (jank), op iOS tot vertraging van Core Animation-rendering.

Geheugenlekken en frequente GC-pauzes

Wanneer de Garbage Collector op Android of ARC op iOS geheugen vrijmaakt, worden alle threads onderbroken. Frequente GC-pauzes ontstaan bij het maken van veel tijdelijke objecten — bijvoorbeeld bij elke aanroep van een lijstadapter wordt een nieuwe ViewHolder-instantie gemaakt. Dit uit zich als schokkerig scrollen.

Zware layouthiërarchieën

Geneste ConstraintLayout, meerdere LinearLayout, overlappende Views — elke nesting verhoogt de tijd voor measure en layout pass. Xcode geeft aan dat een diepe laaghiërarchie (meer dan 10 niveaus) een FPS-daling van 20-30% veroorzaakt.

• Android — overmatige requestLayout, inefficiënte ConstraintLayout-ketens, grote Bitmap zonder downscale
• iOS — Auto Layout constraints met conflicten, zware CALayer, shadowPath zonder rasterization
• Cross-platform — synchrone HTTP-aanroepen in de UI-thread, zware JSON-parsing, niet-optimale afbeeldingen met hoge resolutie

Hoe prestatievertragingen te diagnosticeren

Voor het identificeren van oorzaken van lags worden profilers in de IDE en systeembewakingstools gebruikt. Elk instrument lost zijn eigen taak op.

CPU Profiler in Android Studio

CPU Profiler laat zien welke methoden processortijd in beslag nemen en in welke threads ze worden uitgevoerd. Als een methode met zware berekeningen in de main thread wordt uitgevoerd — is dat de kern van het probleem. Het opnemen van een trace met ingeschakelde sample Java Method maakt het mogelijk om op elk moment de call-stack te zien en „hete punten” te vinden.

Time Profiler in Xcode Instruments

Het analoge instrument voor iOS — Time Profiler — verzamelt elke milliseconde stack-samples en laat zien welk percentage CPU-tijd elke methode in beslag neemt. De combinatie met de vlag Main Thread Only filtert alleen bewerkingen op de hoofdthread, wat direct de bronnen van lags aangeeft.

Network Profiler en analyse van verzoeken

Trage netwerkverzoeken geven de indruk van lags, zelfs als de UI-thread niet is geblokkeerd. Network Profiler in Android Studio en Network Link Conditioner in Xcode maken het mogelijk om een trage verbinding te simuleren en te zien hoe de app zich gedraagt in reële omstandigheden. Chunked-antwoorden zonder voortgang en grote JSON-ladingen zijn typische bronnen van schijnbare lags.

Voorbeeld van profilering van een netwerkverzoek met OkHttp met tijdsmeting:

class TimingInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val start = System.nanoTime()
        val response = chain.proceed(chain.request())
        val duration = (System.nanoTime() - start) / 1_000_000
        Log.d("Timing", "Verzoek duurde $duration ms")
        return response
    }
}

Methoden om lags op Android en iOS te verhelpen

Het verhelpen van lags vereist systematisch werk: van optimalisatie van één methode tot architectuurwijzigingen. Laten we de meest effectieve technieken bekijken.

Asynchrone verwerking via coroutines en GCD

Kotlin Coroutines met dispatcher Dispatchers.IO voor netwerkverzoeken en Dispatchers.Default voor berekeningen garanderen dat de hoofdthread vrij blijft voor de UI. Op iOS is Grand Central Dispatch met queue .global(qos: .userInitiated) voor achtergrondtaken en .main voor UI-updates de standaardaanpak. Vermijd sync-bewerkingen tussen wachtrijen.

Optimalisatie van adapters en lijsten

RecyclerView op Android en UICollectionView op iOS vereisen correcte configuratie: ViewHolder met minimale objectcreatie in onBindViewHolder, DiffUtil voor het berekenen van wijzigingen, prefetching voor het vooraf laden van gegevens. Gebruik op iOS diffable data source voor geanimeerde updates zonder handmatig beheer.

Caching van gegevens en afbeeldingen

Het laden van dezelfde afbeelding bij elke scrollbeweging is een gegarandeerde lag. Coil (Android) en Kingfisher (iOS) cachen afbeeldingen in het geheugen en op schijf, wat zorgt voor onmiddellijke weergave bij een herhaald verzoek. Gebruik voor gegevens Room met een cachelaag op basis van Flow of Combine.

Voorbeeld van het configureren van afbeeldingscaching met Coil op Android:

val imageLoader = ImageLoader(context) {
    memoryCachePolicy(CachePolicy.ENABLED)
    diskCachePolicy(CachePolicy.ENABLED)
    crossfade(true)
    size(512, 512)
}

// Laden met ingeschakelde automatische caching
imageView.load("https://example.com/image.jpg") {
    placeholder(R.drawable.placeholder)
    error(R.drawable.error)
}

Preventie van lags in de ontwikkelingsfase

Lags voorkomen is goedkoper dan ze in productie te repareren. Preventieve maatregelen worden ingebouwd in het ontwikkelingsproces op het niveau van tools en architectuur.

StrictMode op Android

StrictMode — een ingebouwde Android-tool die toevallige invoer-uitvoeroperaties en netwerkaanroepen op de hoofdthread detecteert in de ontwikkelingsfase. Schakel het in in Application.onCreate met het beleid penaltyDeath voor kritieke overtredingen. Dit is de enige manier om te garanderen dat de ontwikkelaar het probleem ziet vóór de commit.

Main Thread Checker op iOS

De analoog voor iOS — Main Thread Checker in Xcode, onderdeel van Runtime Sanitization. Het controleert automatisch of alle UIKit- en AppKit-aanroepen vanuit de hoofdthread worden uitgevoerd. Schakel het in in het Debug-buildschema en streef naar nul waarschuwingen in CI.

Prestatiebenchmarks in CI

Voeg in de CI-pijplijn het uitvoeren van Macrobenchmark (Android) en XCTMetrics (iOS) toe voor het meten van opstarttijd, scroll-FPS en geheugengebruik. Stel drempels in: als een nieuwe commit de opstarttijd met meer dan 5% verhoogt — faalt de build.

• Android — Macrobenchmark, Baseline Profiles, Jetpack Benchmark Library
• iOS — XCTMetrics, os_signpost, MetricKit voor het verzamelen van metrieken van gebruikersapparaten
• Algemene aanpak — profilering voor en na elke significante wijziging, regressie-prestatietests