Systrace — cos’è, strumento di tracciamento del sistema Android

Cos’è Systrace

Systrace è un utilità della riga di comando dell’SDK Android che acquisisce e unisce dati da più fonti di tracciamento del kernel (ftrace) e dello spazio utente (atrace) in un unico report HTML. Lo strumento è apparso in Android 4.1 (Jelly Bean) come sostituto del vecchio utilità traceview per la profilazione di sistema ed è rimasto a lungo lo strumento standard di diagnostica delle prestazioni sulla piattaforma Android.

Architettura di Systrace

Systrace si basa su ftrace — un meccanismo di tracciamento del kernel Linux disponibile in Android dalla versione 4.1. All’avvio di Systrace, attiva le categorie di traccia specificate: sched (pianificatore di attività), freq (frequenza CPU), idle (stati di inattività), workq (code di lavoro), binder, gfx e altre. I dati vengono raccolti nel buffer circolare del kernel e dopo l’arresto vengono uniti in un unico file trace.html che può essere aperto in qualsiasi browser.

Systrace nel contesto di Android Studio

A partire da Android Studio 3.1, Systrace è integrato nel CPU Profiler. In modalità Trace System Calls, il profiler avvia Systrace sul dispositivo connesso e mostra i risultati direttamente nella finestra di Android Studio. Ciò elimina la necessità di lavorare con la riga di comando per i casi di base mantenendo al contempo tutte le funzionalità — tutte le categorie di traccia, il filtraggio e la timeline interattiva. Le prestazioni del dispositivo durante il tracciamento diminuiscono in modo insignificante poiché ftrace è progettato per un overhead minimo.

Come funziona Systrace

Systrace utilizza due meccanismi di raccolta dati: ftrace a livello di kernel per gli eventi di sistema e atrace nello spazio utente per i marcatori specifici di Android. ftrace registra i cambi di contesto (sched_switch), le variazioni di frequenza della CPU (cpu_frequency), gli interrupt (irq_handler_entry) e altri eventi. atrace aggiunge marcatori dal framework Android — inizio e fine del rendering dei frame, chiamate a SurfaceFlinger e transazioni Binder.

Pipeline di rendering dei frame in Systrace

La caratteristica principale di Systrace è la visualizzazione della pipeline di rendering di ogni frame: applicazione → BufferQueue → SurfaceFlinger → HWC (compositore) → Display. Se si verifica un ritardo in qualsiasi fase, Systrace mostra la causa esatta: l’applicazione non ha preparato il buffer in tempo, SurfaceFlinger era in attesa di VSync o HWC non ha potuto comporre i livelli. Il ciclo di vita del frame sulla timeline è codificato a colori per stato: verde (in tempo), giallo (in ritardo), rosso (perso). Questa visualizzazione è lo strumento principale per ottimizzare le prestazioni dell’interfaccia utente.

Categorie di traccia

Systrace supporta oltre 20 categorie di traccia, ciascuna delle quali include una serie di eventi correlati. Le categorie importanti includono: gfx (rendering grafico), input (elaborazione input), view (sistema View), webview (WebView), power (consumo energetico), hal (livello di astrazione hardware). Per la profilazione dei giochi, è utile la categoria gfx con dettagli dei comandi GPU tramite AGI (Android GPU Inspector).

Caratteristiche principali di Systrace

Systrace fornisce un insieme unico di capacità per Android non disponibili in altri profiler: timeline di sistema, metriche a livello di kernel e rilevamento automatico dei problemi.

Timeline interattiva

Il report HTML di Systrace contiene una timeline multilivello in cui ogni corsia corrisponde a un processo o thread. È possibile ingrandire e ridurre la scala temporale, fare clic sugli eventi per visualizzare i dettagli (durata, processo iniziatore, argomenti aggiuntivi). La codifica a colori aiuta a navigare rapidamente: blocchi verdi — processo in esecuzione, blu — in attesa, arancioni — interruzione, bianchi — inattivo.

Messaggi di avviso

Systrace analizza automaticamente la traccia e visualizza messaggi di avviso che indicano le aree problematiche. Ad esempio: Buffer underrun — SurfaceFlinger non ha ricevuto il buffer prima di VSync o Long Binder transaction — 42 ms nel thread Binder_1. Ogni avviso contiene un collegamento alla sezione corrispondente della timeline e una raccomandazione per la correzione. Ciò consente di risparmiare ore di analisi manuale ed è uno dei motivi principali per utilizzare Systrace invece della registrazione manuale.

Metodo Trace.beginSection

Gli sviluppatori possono aggiungere marcatori personalizzati alla traccia Systrace tramite l’API Trace.beginSection e Trace.endSection. Ciò consente di tracciare l’esecuzione di sezioni critiche del codice direttamente sulla timeline di sistema — ad esempio, marcare l’inizio e la fine del caricamento dei dati o del calcolo del layout. I marcatori appaiono come blocchi separati sulla corsia dell’applicazione e sono visibili insieme agli eventi di sistema.

Come eseguire Systrace

L’esecuzione di Systrace è possibile in due modi: tramite il CPU Profiler di Android Studio (modalità Trace System Calls) o tramite la riga di comando utilizzando lo script Python systrace.py dalla cartella platform-tools. Ogni metodo ha i propri casi d’uso.

Esecuzione tramite Android Studio

Collegare il dispositivo, aprire il Profiler (View → Tool Windows → Profiler), selezionare il processo, andare alla scheda CPU, selezionare la modalità Trace System Calls e fare clic su Record. Dopo 5–30 secondi, fare clic su Stop — Android Studio avvierà Systrace sul dispositivo, attenderà il completamento e caricherà il risultato. Limitazione: la registrazione è possibile solo quando il Profiler è aperto, il che è scomodo per scenari lunghi o automazione.

Esecuzione dalla riga di comando

Per un controllo più flessibile, utilizzare lo script systrace.py. Specificare le categorie di traccia, la durata e il nome del file di output. Esempio: acquisizione dei dati gfx, input e sched per 10 secondi. L’esecuzione richiede Python 2.7+ e un dispositivo connesso con debug USB abilitato. Su Android 12+, Systrace viene sostituito da Perfetto — il comando rimane lo stesso, ma lo script reindirizza le chiamate a perfetto.

# Esecuzione base di systrace per 10 secondi
$ python systrace.py \
    --time=10 \
    -o trace.html \
    gfx input sched

# Solo categoria gfx per analisi UI
$ python systrace.py \
    --time=5 \
    -t gfx \
    -o ui_trace.html

Impostazione di marcatori personalizzati nel codice

Per far apparire il tuo codice sulla timeline di Systrace, avvolgi la sezione critica con Trace.beginSection / Trace.endSection. È importante che beginSection e endSection siano strettamente accoppiati — altrimenti Systrace mostrerà una timeline errata. In Kotlin, è conveniente utilizzare un’estensione inline per garantire la chiusura della sezione anche in caso di eccezione.

import android.os.Trace

fun traceSection(name: String, block: () -> Unit) {
    Trace.beginSection(name)
    try {
        block()
    } finally {
        Trace.endSection()
    }
}

// Utilizzo nel codice
traceSection("load_screen_data") {
    fetchData()
    updateUI()
}

Lettura del report HTML di Systrace

Il report di Systrace è un file HTML autonomo che può essere aperto in Chrome, Edge o Firefox. Contiene una timeline interattiva, un pannello di selezione dei processi, un elenco di messaggi di avviso e metriche chiave (frame rate, utilizzo CPU, transazioni Binder). Comprendere la struttura del report è una competenza chiave per una profilazione efficace.

Timeline e navigazione

La timeline mostra il tempo da sinistra a destra. Ogni processo e thread è una corsia separata. I tasti W/S ingrandiscono/riducono, A/D si muovono nel tempo. Seleziona un’area con il mouse per ingrandire una sezione. Le linee VSync mostrano i confini dei frame (ogni 16,6 ms a 60 FPS). Se un ciclo di rendering completo non rientra tra due linee VSync — il frame viene perso. Presta attenzione alla corsia SurfaceFlinger: se è occupata a lungo (blocco arancione), la composizione dei livelli sta rallentando il rendering complessivo.

Analisi dei messaggi di avviso

Il pannello Avvisi sul lato sinistro del report contiene i problemi rilevati automaticamente. Ogni avviso è cliccabile — al clic, la timeline si sposta al momento problematico. Gli avvisi più comuni: Long Sync (sincronizzazione lunga del thread), Scheduling Delay (ritardo dello scheduler), Buffer Overrun (overflow del buffer SurfaceFlinger). Se un avviso mostra un valore di ~100 ms per Scheduling Delay, indica direttamente che il thread UI era in attesa della CPU a causa del carico di fondo — i calcoli pesanti dovrebbero essere spostati in un Worker Thread.

Ciclo di vita del frame e jank

Per analizzare i frame persi, attiva le corsie SurfaceFlinger e app.gfx. Ogni frame viene visualizzato come un rettangolo: verde (≤16 ms), giallo (16–32 ms), rosso (>32 ms). Se vedi un rettangolo rosso sulla corsia dell’app, fai clic su di esso — Systrace mostrerà quale metodo specifico (o chiamata di sistema) ha superato il limite. Secondo Google (Android Performance Patterns, 2023), il 70% dei problemi di jank è causato da onBindViewHolder lento o GC frequente.

Systrace vs Perfetto: transizione al nuovo formato

Perfetto è il successore di Systrace, introdotto da Google in Android 9 (Pie) come strumento sperimentale e diventato la soluzione principale a partire da Android 12. Perfetto utilizza un moderno formato dati protobuf, supporta sessioni lunghe (ore invece di secondi) e dispone di un’interfaccia Web per visualizzare le tracce. Esaminiamo le differenze principali tra i due sistemi.

Nonostante la transizione a Perfetto, le competenze di Systrace rimangono rilevanti: sui dispositivi con Android 11 e versioni precedenti, viene utilizzato per impostazione predefinita e Perfetto mantiene la compatibilità all’indietro con le categorie Systrace. Nel CPU Profiler di Android Studio, Perfetto viene utilizzato per i nuovi dispositivi e Systrace per quelli vecchi — in modo trasparente per l’utente. Per CI/CD, si consiglia Perfetto poiché il suo formato può essere automaticamente elaborato tramite Python e SQL.

Esempi di utilizzo di Systrace

Per padroneggiare praticamente Systrace, consideriamo due scenari: trovare la causa dei frame persi durante lo scorrimento e diagnosticare GC frequenti che bloccano il thread UI.

Ricerca di jank durante lo scorrimento di RecyclerView

Esegui Systrace con la categoria gfx per 10 secondi, scorri l’elenco nell’app. Nel report, trova le sezioni con frame rossi. Fai clic sul frame problematico e guarda la corsia dell’app — se c’è un blocco inflateLayout o onBindViewHolder più largo di 16 ms, il problema è nell’inflazione del layout o nel binding dei dati. Soluzione: ottimizza il layout (riduci ViewGroup profondi, ViewStub), scarica il caricamento delle immagini su Glide con onAttachedToWindow.

Diagnostica del throughput GC

Systrace con le categorie freq e sched consente di vedere quanto spesso i cicli GC anticipano il thread UI. Trova la corsia dell’applicazione sulla timeline — se vedi blocchi periodici di 20–50 ms denominati Concurrent GC, il garbage collector viene eseguito troppo frequentemente. Aggiungi la categoria dalvik per un’analisi dettagliata. Soluzione: converti Bitmap in ByteBuffer, utilizza un pool di oggetti (ObjectPool) per allocazioni frequenti, riduci la frammentazione dell’heap tramite argomenti ART.

# Esecuzione con categorie per analisi UI + GC
$ python systrace.py \
    --time=15 \
    -o gc_analysis.html \
    gfx sched dalvik freq

# Acquisizione con durata di 30 secondi per test riproducibile
$ python systrace.py \
    --time=30 \
    --app=com.example.app \
    -o app_trace.html