Prestatietest in mobiele ontwikkeling: wat het is, metriek en hoe het wordt uitgevoerd

Wat is een Prestatietest?

Prestatietest is een type niet-functioneel testen dat bepaalt hoe snel en efficiënt de applicatie haar taken uitvoert. In tegenstelling tot unittesten of UI-tests, meet Prestatietest kwantitatieve kenmerken: responstijd, processorbelasting, RAM-verbruik en batterijverbruik. Volgens het rapport van Sauce Labs (2025) neemt 68% van de mobiele ontwikkelingsteams Prestatietest op in de reguliere testcyclus en automatiseert 41% het in CI.

Het hoofddoel van Prestatietest is ervoor te zorgen dat de applicatie voldoet aan de prestatienormen die in de specificatie zijn vastgelegd. Als het openen van een scherm langer dan 500 milliseconden duurt of de applicatie meer dan 200 MB RAM verbruikt op een gemiddeld apparaat, is dit een signaal voor optimalisatie. Baseline van prestaties wordt vastgesteld in de fase van de eerste stabiele release en wordt herzien bij elke grote update.

Prestatietest wordt uitgevoerd op echte apparaten, niet op simulatoren, omdat emulatie geen nauwkeurig beeld geeft van CPU-, GPU- en netwerkresourcegebruik. Volgens Apple WWDC (2024) tonen tests op een simulator 15-30% hogere resultaten vergeleken met een echt apparaat. Echt apparaat blijft de enige betrouwbare bron van prestatiegegevens.

De regelmaat van het uitvoeren van Prestatietest hangt af van de ontwikkelingscyclus. In de aanbevelingen van Google Android Performance (2024) wordt aangegeven dat basisprestatiemetingen moeten worden uitgevoerd bij elke pull request en de volledige set vóór elke release. Automatisering van deze metingen maakt het mogelijk om prestatieregressies in een vroeg stadium te detecteren.

Belangrijkste prestatiewaarden

In mobiele ontwikkeling worden vijf hoofdcategorieën onderscheiden die 90% van de Prestatietest-scenario's dekken. Opstarttijd (cold start en warm start) — de eerste metriek die bij elke release wordt gecontroleerd. Google Play Console (2024) registreert de opstarttijd volgens drempels: cold start mag niet langer dan 5 seconden duren, warm start — 1,5 seconden. Overschrijding van deze drempels heeft direct invloed op de rating in de app store.

Opstarttijd (Cold Start)

Cold start wordt gemeten vanaf het moment van klikken op het pictogram tot het verschijnen van het eerste frame van de applicatie. iOS gebruikt `dispatch_async` voor uitgestelde initialisatie, wat de zichtbare opstarttijd verkort. Android cold start omvat het aanmaken van het proces, initialisatie van Application en het starten van Activity. Volgens Google Performance (2024) vermindert elke 100 ms vertraging van cold start de conversieratio met 1,2% in e-commerce-applicaties.

Frames per seconde (FPS)

FPS (Frames Per Second) — de beeldsnelheid bij animaties en scrollen van lijsten. Voor een soepele interface is stabiele 60 FPS vereist. Android Studio Profiler en Xcode GPU Report tonen FPS-dalingen bij zware bewerkingen — het laden van afbeeldingen, parsen van JSON of renderen van complexe layouts. Een daling onder de 30 FPS wordt door de gebruiker ervaren als vertraging en leidt tot een verlaging van de retentieratio met 22% volgens Adjust (2025).

RAM-verbruik

RAM-verbruik — de derde kritische metriek. Geheugenlekken — de belangrijkste oorzaak van prestatievermindering in langdurige sessies. Instruments Allocations en Android Memory Profiler helpen bij het detecteren van cyclische verwijzingen in Swift en niet-vrijgegeven Activities in Android. Batterijverbruik — een metriek die vaak over het hoofd wordt gezien in de testfase. Volgens Apple Developer (2024) worden applicaties met hoog energieverbruik op iOS beperkt op de achtergrond. Energy Log in Xcode registreert het wattageprofiel van de applicatie gedurende de sessie.

Soorten prestatietesten

Belastingtest (Load Test) controleert het gedrag van de applicatie onder het verwachte aantal gelijktijdige gebruikers. Voor mobiele backend betekent dit simulatie van 1000-10000 gelijktijdige verzoeken aan de API. De serverzijde moet piekbelasting verwerken zonder dat de responstijd meer dan 20% toeneemt ten opzichte van de basiswaarde. Volgens k6 benchmarks (2024) omvat een typische Load Test-configuratie een oprit van 0 tot 1000 VU (virtuele gebruikers) in 5 minuten.

Stresstest (Stress Test) bepaalt het faalpunt van de applicatie — het moment waarop het systeem niet meer reageert op verzoeken of onaanvaardbaar degradeert. In tegenstelling tot Load Test, belast Stress Test het systeem boven normale limieten. Faalpunt wordt geregistreerd op basis van een van de criteria: responstijd overschrijdt 10 seconden, percentage 5XX-fouten overschrijdt 5%, of RAM-verbruik bereikt 90% van het beschikbare geheugen.

Volumetest (Volume Test) beoordeelt het gedrag van de applicatie bij het werken met grote hoeveelheden gegevens. In mobiele context is dit het controleren van het werken met duizenden records in de lokale database, tientallen gigabytes cache of miljoenen pushmeldingen. SQLite op Android en Core Data op iOS tonen verschillende prestaties bij volumes boven 100000 records.

Tools voor Prestatietest

Xcode Instruments

Xcode Instruments — de belangrijkste tool voor het profileren van iOS-applicaties. Time Profiler laat zien welke methoden de meeste CPU verbruiken, en Allocations volgt geheugentoewijzing en -vrijgave. Instruments ondersteunt opname tijdens lange sessies (tot 30 minuten) en export van traces voor vergelijking tussen builds. Activity Monitor in Instruments toont de totale systeembelasting in realtime.

Android Studio Profiler

Android Studio Profiler — de ingebouwde profiler voor Android. Het combineert CPU-, Memory-, Network- en Energy-profilers in één interface. Kenmerk van Android Profiler is ondersteuning voor interactieve sessies: de ontwikkelaar kan acties in de applicatie uitvoeren en de onmiddellijke reactie van metriek zien. Volgens Google I/O (2024), Profiler ondersteunt opname in .perf-formaat, dat in CI met de baseline kan worden vergeleken.

Charles Proxy

Charles Proxy en Proxyman — tools voor netwerkverkeersanalyse. Ze tonen de tijd van elk HTTP-verzoek, de responsgrootte en headers. Voor Prestatietest is het belangrijk om verzoeken te registreren die langer dan 500 ms duren — deze zijn kandidaten voor caching of optimalisatie. Charles ondersteunt throttle-modus die langzame netwerken simuleert: 3G, Edge en LTE. Proxyman — een lichter alternatief voor macOS met native Swift-architectuur.

import XCTest

class PerformanceTests: XCTestCase {

    func testLaunchPerformance() {
        measure(metrics: [XCTClockMetric(),
                         XCTMemoryMetric()]) {
            XCUIApplication().launch()
        }
    }

    func testScrollPerformance() {
        let app = XCUIApplication()
        app.launch()
        let tableView = app.tables["list"]
        measure {
            tableView.swipeUp()
            tableView.swipeDown()
        }
    }
}

Prestatietest in de CI/CD-pijplijn

Het integreren van Prestatietest in CI/CD is de industriestandaard voor 2025-2026. Prestatiepijplijn omvat drie fasen: pre-commit (snelle metingen bij pull request), nightly (volledige testsuite) en pre-release (vergelijking met baseline op referentieapparaten). Bitrise en GitHub Actions ondersteunen het uitvoeren van Xcode Instruments CLI en Gradle Profiler.

GitHub Actions (2024) heeft een officiële sjabloon gepubliceerd voor iOS Prestatietest met behulp van `xcodebuild test-without-building`. De sjabloon voert de tests uit op een van de GitHub-machines en publiceert het rapport in een artifact. Baseline wordt opgeslagen in een JSON-bestand in de repository: bij overschrijding van de drempel met 10% faalt de pijplijn met een fout. Deze aanpak voorkomt prestatievermindering zonder handmatige controle van elke build.

Het probleem van mobiele Prestatietest in CI is de instabiliteit van resultaten op verschillende machines. Apple Silicon (M1-M4) en Intel Xeon geven verschillende uitvoeringstijden. Oplossing is het gebruik van procentuele verhouding tot baseline, niet absolute waarden. Als de test 15% langer duurt dan baseline — wordt de build gemarkeerd als controlerend.

Prestatietests schrijven op iOS en Android

XCTest Performance op iOS gebruikt de methode `measure(metrics:)`, die een codeblok 10 keer uitvoert en statistieken retourneert: gemiddelde, mediaan, standaarddeviatie. Voor het testen van databaseprestaties is het handig om XCTMemoryMetric te gebruiken, die het piek-RAM-verbruik registreert. Drempel wordt ingesteld via `XCTPerformanceReport` na voltooiing van de test.

Android Macrobenchmark — een bibliotheek van Google voor het meten van prestaties op applicatieniveau. Macrobenchmark voert gebruikersscenario's uit (starten van Activity, scrollen van RecyclerView, openen van WebView) en meet de uitvoeringstijd. Baseline Profile — een set klassen en methoden die de Android-compiler vooraf optimaliseert. Google Play gebruikt Baseline Profile om de eerste start met 30% te versnellen.

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {
    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun startup() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(StartupTimingMetric()),
            iterations = 5
        ) {
            pressHome()
            startActivityAndWait()
        }
    }
}

Beide benaderingen — XCTest Performance en Android Macrobenchmark — gebruiken hetzelfde concept: meerdere metingen met middeling en vergelijking met drempel. Prestatie kan niet tot één getal worden herleid. Elke release moet worden vergezeld van een prestatierapport met trends van metriek over de laatste 5 builds. Zo'n rapport stelt het team in staat om degradatie te zien voordat gebruikers het opmerken.