Performance Test nello sviluppo mobile: cos’è, metriche e come si esegue

Cos’è Performance Test?

Performance Test è un tipo di test non funzionale che determina la rapidità e l’efficienza con cui un’applicazione esegue i suoi compiti. A differenza dei test unitari o dei test UI, Performance Test misura caratteristiche quantitative: tempo di risposta, carico CPU, consumo di RAM e utilizzo della batteria. Secondo il rapporto Sauce Labs (2025), il 68% dei team di sviluppo mobile include Performance Test nel proprio ciclo di test regolare, e il 41% lo automatizza in CI.

L’obiettivo principale di Performance Test è garantire che l’applicazione soddisfi i requisiti di prestazione specificati nella documentazione. Se il tempo di avvio dello schermo supera i 500 millisecondi o l’applicazione consuma più di 200 MB di RAM su un dispositivo medio, questo è un segnale di ottimizzazione. La baseline di prestazione viene stabilita al primo rilascio stabile e viene rivista a ogni aggiornamento importante.

Performance Test viene eseguito su dispositivi reali, non su simulatori, poiché l’emulazione non fornisce un’immagine accurata dell’utilizzo di CPU, GPU e risorse di rete. Secondo Apple WWDC (2024), i test sul simulatore mostrano risultati gonfiati rispetto a un dispositivo reale del 15–30%. Un dispositivo reale rimane l’unica fonte affidabile di dati sulle prestazioni.

La frequenza di esecuzione di Performance Test dipende dal ciclo di sviluppo. Secondo le raccomandazioni di Google Android Performance (2024), le misurazioni di base dovrebbero essere eseguite a ogni pull request, e una suite completa prima di ogni rilascio. L’automazione di queste misurazioni consente di rilevare le regressioni di prestazione in fasi precoci.

Metriche chiave di prestazione

Nello sviluppo mobile vengono identificate cinque metriche principali che coprono il 90% degli scenari di Performance Test. Il tempo di avvio (cold start e warm start) è la prima metrica controllata a ogni rilascio. Google Play Console (2024) registra il tempo di avvio per soglia: il cold start non deve superare i 5 secondi, il warm start — 1,5 secondi. Il superamento di queste soglie influisce direttamente sulla valutazione nell’app store.

Tempo di avvio (Cold Start)

Il cold start viene misurato dal momento in cui si tocca l’icona fino alla comparsa del primo frame dell’applicazione. iOS utilizza `dispatch_async` per l’inizializzazione differita, riducendo il tempo di avvio visibile. Il cold start su Android include la creazione del processo, l’inizializzazione di Application e l’avvio di Activity. Secondo Google Performance (2024), ogni 100 ms di ritardo del cold start riduce il tasso di conversione dell’1,2% nelle applicazioni di e-commerce.

Frequenza fotogrammi (FPS)

FPS (Frames Per Second) è la frequenza dei fotogrammi durante animazioni e scorrimento delle liste. Un’interfaccia fluida richiede 60 FPS stabili. Android Studio Profiler e Xcode GPU Report mostrano cali di FPS durante operazioni pesanti — caricamento immagini, parsing JSON o rendering di layout complessi. Un calo sotto i 30 FPS viene percepito dall’utente come rallentamento e porta a una diminuzione del tasso di retention del 22% secondo Adjust (2025).

Consumo di RAM

Il consumo di RAM è la terza metrica critica. Le perdite di memoria sono la causa principale del degrado delle prestazioni in sessioni lunghe. Instruments Allocations e Android Memory Profiler aiutano a rilevare riferimenti ciclici in Swift e Activity non rilasciate in Android. Il consumo della batteria è una metrica spesso trascurata durante i test. Secondo Apple Developer (2024), le applicazioni con elevato consumo energetico vengono limitate in background su iOS. Energy Log in Xcode registra il profilo di potenza dell’applicazione per sessione.

Tipi di test di prestazione

Test di carico (Load Test) verifica il comportamento dell’applicazione sotto il numero previsto di utenti simultanei. Per un backend mobile, questo significa simulare da 1000 a 10000 richieste API simultanee. Il lato server deve gestire il carico di punta senza aumentare il tempo di risposta di oltre il 20% rispetto al valore base. Secondo i benchmark k6 (2024), una configurazione tipica di Load Test include una rampa da 0 a 1000 VU (utenti virtuali) in 5 minuti.

Test di stress (Stress Test) determina il punto di rottura dell’applicazione — il momento in cui il sistema smette di rispondere alle richieste o degrada in modo inaccettabile. A differenza del Load Test, lo Stress Test carica il sistema oltre i limiti normali. Il punto di rottura viene registrato in base a uno dei criteri: il tempo di risposta supera i 10 secondi, la percentuale di errori 5XX supera il 5%, o il consumo di RAM raggiunge il 90% della memoria disponibile.

Test di volume (Volume Test) valuta il comportamento dell’applicazione quando lavora con grandi volumi di dati. Nel contesto mobile, ciò comporta il test con migliaia di record in un database locale, decine di gigabyte di cache o milioni di notifiche push. SQLite su Android e Core Data su iOS mostrano prestazioni diverse quando si superano i 100.000 record.

Strumenti per Performance Test

Xcode Instruments

Xcode Instruments è lo strumento principale per il profiling delle applicazioni iOS. Time Profiler mostra quali metodi consumano più CPU, mentre Allocations traccia l’allocazione e il rilascio della memoria. Instruments supporta la registrazione in sessioni lunghe (fino a 30 minuti) e l’esportazione di trace per il confronto tra build. Activity Monitor all’interno di Instruments mostra il carico complessivo del sistema in tempo reale.

Android Studio Profiler

Android Studio Profiler è il profiler integrato per Android. Combina i profiler di CPU, Memoria, Rete ed Energia in un’unica interfaccia. Una caratteristica di Android Profiler è il supporto per sessioni interattive: gli sviluppatori possono eseguire azioni nell’applicazione e vedere la risposta immediata delle metriche. Secondo Google I/O (2024), Profiler supporta la registrazione in formato .perf, che può essere confrontato con una baseline in CI.

Charles Proxy

Charles Proxy e Proxyman sono strumenti per analizzare il traffico di rete. Mostrano il tempo di ogni richiesta HTTP, la dimensione della risposta e le intestazioni. Per Performance Test, è importante catturare le richieste che richiedono più di 500 ms — queste sono candidate per la memorizzazione nella cache o l’ottimizzazione. Charles supporta la modalità throttle che simula reti lente: 3G, Edge e LTE. Proxyman è un’alternativa più leggera per macOS con architettura Swift nativa.

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()
        }
    }
}

Performance Test nella pipeline CI/CD

Integrare Performance Test in CI/CD è lo standard di settore per il 2025–2026. La pipeline di prestazione include tre fasi: pre-commit (misurazioni rapide su pull request), nightly (suite di test completa) e pre-release (confronto con la baseline su dispositivi di riferimento). Bitrise e GitHub Actions supportano l’esecuzione di Xcode Instruments CLI e Gradle Profiler.

GitHub Actions (2024) ha pubblicato un template ufficiale per Performance Test su iOS utilizzando `xcodebuild test-without-building`. Il template esegue i test su una delle macchine GitHub e pubblica il report come artefatto. La baseline viene memorizzata in un file JSON nel repository: se la soglia viene superata del 10%, la pipeline fallisce con un errore. Questo approccio impedisce il degrado delle prestazioni senza revisione manuale di ogni build.

Il problema del Performance Test mobile in CI è l’instabilità dei risultati su macchine diverse. Apple Silicon (M1–M4) e Intel Xeon danno tempi di esecuzione diversi. La soluzione è utilizzare un rapporto percentuale rispetto alla baseline anziché valori assoluti. Se un test richiede il 15% in più rispetto alla baseline, la build viene contrassegnata come bisognosa di revisione.

Scrivere Performance Tests su iOS e Android

XCTest Performance su iOS utilizza il metodo `measure(metrics:)`, che esegue un blocco di codice 10 volte e restituisce statistiche: media, mediana, deviazione standard. Per i test di prestazione del database, XCTest utilizza convenientemente XCTMemoryMetric, che cattura il consumo di picco della RAM. La soglia viene impostata tramite `XCTPerformanceReport` dopo il completamento del test.

Android Macrobenchmark è una libreria di Google per misurare le prestazioni a livello di applicazione. Macrobenchmark esegue scenari utente (avvio di Activity, scorrimento RecyclerView, apertura WebView) e misura il tempo di esecuzione. Baseline Profile è un insieme di classi e metodi che il compilatore Android pre-ottimizza. Google Play utilizza Baseline Profile per accelerare il primo avvio del 30%.

@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()
        }
    }
}

Entrambi gli approcci — XCTest Performance e Android Macrobenchmark — utilizzano lo stesso concetto: misurazione ripetuta con calcolo della media e confronto con una soglia. Le prestazioni non possono essere ridotte a un singolo numero. Ogni rilascio deve essere accompagnato da un report sulle prestazioni contenente le tendenze delle metriche delle ultime 5 build. Tale report consente al team di vedere il degrado prima che gli utenti lo notino.