Traceview: cos’è, strumento di tracciamento e profilazione Android

Cos’è Traceview in Android

Traceview è un profilatore grafico integrato in Android Studio che visualizza le tracce di esecuzione dei metodi delle applicazioni Android come una timeline e una tabella di chiamate. Fa parte dell’Android SDK ed è disponibile tramite Android Profiler a partire da Android Studio 3.0, nonché tramite l’utilità da riga di comando dmtracedump.

Scopo dello strumento

Il compito principale di Traceview è aiutare gli sviluppatori a trovare i metodi che consumano più tempo CPU. A differenza della semplice registrazione, Traceview registra l’ora esatta di entrata e uscita di ogni metodo, costruisce un Call Chart e un albero Top-Down, consentendo il rilevamento visivo di anomalie delle prestazioni. Lo strumento è particolarmente utile durante la profilazione del thread UI, dove un ritardo di 16 ms causa la perdita di un fotogramma.

Storia e sviluppo

Traceview è apparso per la prima volta nelle prime versioni dell’Android SDK come utilità autonoma per visualizzare file .trace. Con il rilascio di Android Studio 3.0 (2017), è diventato parte di Android Profiler, ottenendo l’integrazione con timeline live di CPU, memoria e rete. Secondo Google I/O 2018, il team di Android Studio continua a sviluppare il profilatore, aggiungendo il supporto per codice nativo tramite systrace e perfetto. Nelle versioni attuali di Android Studio, Traceview funziona sopra il formato Perfetto ma mantiene la compatibilità all’indietro con il formato .trace classico.

Come funziona Traceview

Traceview riceve i dati dal meccanismo System Tracing in Android Runtime (ART). Quando un’applicazione viene avviata con il tracciamento abilitato, ART registra i timestamp di inizio e fine di ogni metodo eseguito, inclusi nome della classe, nome del metodo e ID del thread.

// Avvio della traccia nel codice dell'app
Debug.startMethodTracing("app_trace")

// Sezione critica del codice per il profiling
loadHeavyData()

// Arresto della traccia — file salvato sul dispositivo
Debug.stopMethodTracing()

System Tracing opera a livello di macchina virtuale ART e registra ogni chiamata a metodo con precisione di microsecondi. I dati vengono scritti in un buffer circolare per ridurre al minimo l’impatto sulle prestazioni dell’applicazione. Dopo l’arresto del tracciamento, il buffer viene scaricato in un file .trace nella memoria interna del dispositivo.

Formato del file .trace

Un file .trace contiene un’intestazione con la versione del formato e l’ora di inizio, seguita da record per ogni chiamata: ID thread, ID metodo, timestamp di entrata e timestamp di uscita. Android Studio carica automaticamente il file .trace e crea due viste principali: il pannello Timeline per la cronologia e il pannello Profilo per la gerarchia delle chiamate. Per impostazione predefinita, la dimensione massima del buffer è di 8 MB, ma può essere aumentata tramite Debug.startMethodTracing(filename, maxSize).

Caratteristiche principali di Traceview

Traceview fornisce diverse viste di dati complementari, ciascuna delle quali affronta un compito specifico nell’analisi delle prestazioni.

Call Chart (grafico chiamate)

Call Chart è una timeline orizzontale in cui ogni thread viene visualizzato come una corsia separata. I metodi sono mostrati come rettangoli colorati: la larghezza del rettangolo è proporzionale al tempo di esecuzione e l’annidamento riflette la gerarchia delle chiamate. Se un metodo chiama un altro metodo, il rettangolo figlio viene disegnato all’interno del rettangolo padre. Questa visualizzazione consente l’identificazione immediata delle operazioni che hanno bloccato il thread.

Alberi Top-Down e Bottom-Up

L’albero Top-Down mostra il tempo di esecuzione di un metodo incluse tutte le sue chiamate annidate — Inclusive Time. L’albero Bottom-Up, al contrario, mostra quali metodi padre hanno chiamato un determinato metodo — utile per trovare la fonte di un’operazione pesante. La differenza tra Inclusive e Exclusive Time è critica: un metodo può essere eseguito rapidamente ma chiamare un metodo figlio lento, e questo è visibile solo nel Inclusive Time.

Ricerca e filtraggio

Traceview supporta la ricerca per nome del metodo, pacchetto o classe. I risultati vengono evidenziati sulla timeline e il pannello Profilo mostra le statistiche solo per i metodi trovati. Il filtraggio per thread è disponibile anche — è possibile nascondere i thread in background e concentrarsi sul thread principale (UI), dove i ritardi sono più critici.

Esportazione dati

Traceview consente di esportare le tracce in formato CSV per ulteriori analisi in fogli di calcolo o grafici. In Android Studio, è anche possibile copiare un frammento selezionato della timeline come immagine — per inserirlo in segnalazioni di bug o documentazione. Per CI/CD, l’esportazione in formato Perfetto è disponibile tramite l’utilità cmdline-tools.

Come usare Traceview in Android Studio

La profilazione tramite Traceview è disponibile in due modi: tramite Android Profiler con acquisizione live e tramite chiamate programmatiche all’API Debug. Il primo metodo è comodo per l’analisi ad-hoc, il secondo per test di prestazioni riproducibili.

Acquisizione tramite Android Profiler

In Android Studio, apri la scheda Profiler (View → Tool Windows → Profiler), seleziona il dispositivo e il processo dell’applicazione. Fai clic sul segmento CPU, quindi seleziona la modalità “Trace Java Methods” e fai clic su Record. Dopo aver interagito con l’applicazione, fai clic su Stop — Traceview aprirà automaticamente la traccia registrata. La durata predefinita della registrazione è limitata a 30 secondi, ma il limite può essere modificato nelle impostazioni del profilatore.

Avvio programmatico del tracciamento

Per una profilazione precisa di una sezione di codice specifica, utilizza Debug.startMethodTracing e Debug.stopMethodTracing. Il file viene salvato nella memoria esterna dell’applicazione nel percorso restituito da context.getExternalFilesDir(null). Dopo il completamento, trasferisci il file .trace al computer tramite Android Studio Device Explorer, quindi aprilo tramite File → Open in Android Studio.

Debug.startMethodTracing(
    "heavy_computation",
    Debug.TRACE_COUNT_ALLOCS
)

processLargeDataset()

Debug.stopMethodTracing()

Configurazione dei parametri di tracciamento

Debug.startMethodTracing accetta tre parametri: il nome del file (senza estensione), la dimensione massima del buffer (default 8 MB) e i flag. Il flag TRACE_COUNT_ALLOCS aggiunge il conteggio delle allocazioni di oggetti — utile per trovare perdite di memoria. Traceview non è adatto per la profilazione di codice nativo — utilizza SimplePerf o Perfetto. Per test lunghi (oltre 30 secondi), si consiglia di aumentare il buffer a 64–128 MB tramite il parametro maxSize.

Leggere la timeline di Traceview

La timeline di Traceview è composta da due pannelli: il pannello Timeline superiore con rettangoli di chiamate colorati e il pannello Profilo inferiore con una tabella di statistiche. Il pannello Timeline mostra l’esecuzione dei thread da sinistra a destra, dove ogni rettangolo è una singola chiamata a metodo. I colori dei rettangoli sono codificati per tipo di metodo: chiamate di sistema Android (verde), metodi dell’applicazione (blu), chiamate di librerie (arancione).

Come leggere il pannello Profilo

Nel pannello Profilo, ogni riga è un metodo con colonne per Inclusive Time, Exclusive Time, Calls + Recur e CPU Time. Ordina la tabella per Inclusive Time (decrescente) per vedere prima i metodi che hanno impiegato più tempo totale. Se un metodo con Inclusive Time alto ha Exclusive Time basso — il problema è nelle sue chiamate figlie e devi espandere l’albero. Ad esempio, ListView.getView potrebbe avere un Inclusive Time alto a causa di chiamate di caricamento immagini.

Identificazione dei colli di bottiglia

Cerca metodi con Real Time anormalmente alto ma CPU Time basso — questo indica blocco (attesa I/O, operazione di rete, contesa di blocco). I metodi con CPU Time alto richiedono ottimizzazione dell’algoritmo. Per il thread UI, ogni metodo deve essere completato entro 16 ms — se una chiamata supera questa soglia, l’applicazione perde un fotogramma e l’utente vede scatti. Secondo le raccomandazioni Google, il tempo totale di tutte le chiamate nel thread UI per fotogramma non deve superare 8–10 ms, lasciando un margine per le operazioni di sistema.

Traceview vs Systrace: confronto strumenti

Sebbene sia Traceview che Systrace siano strumenti di tracciamento Android, risolvono compiti diversi e vengono utilizzati in diverse fasi di profilazione. La differenza principale è il livello di dettaglio: Traceview opera a livello di metodi Java/Kotlin, Systrace a livello di processi di sistema (CPU, GPU, Binder, SurfaceFlinger).

In pratica, entrambi gli strumenti si completano a vicenda: prima Systrace aiuta a identificare quale componente di sistema sta causando il problema (ad esempio, GC frequente o blocchi Binder), poi Traceview consente di approfondire un metodo specifico all’interno dell’applicazione. In Android Studio, entrambi gli strumenti sono combinati in Android Profiler — CPU Profiler seleziona automaticamente la modalità di registrazione ottimale. Su dispositivi con Android 12+, Systrace e Traceview funzionano su Perfetto, fornendo un formato dati unificato per tutti i tipi di profilazione.

Esempi di codice con Traceview

Una profilazione efficace richiede più del semplice avvio del tracciamento — è necessario posizionare correttamente i punti di acquisizione e interpretare i risultati. Di seguito sono riportati due esempi pratici: profilazione del caricamento di RecyclerView e confronto di due algoritmi in un test di prestazioni.

Profilazione del caricamento di RecyclerView

Il primo esempio è il tracciamento del percorso critico durante lo scorrimento dell’elenco. RecyclerView chiama onBindViewHolder per ogni elemento visibile e se questo metodo richiede più di 16 ms, lo scorrimento diventa a scatti. Il tracciamento intorno a onBindViewHolder mostrerà quali operazioni specifiche al suo interno richiedono tempo.

class MyAdapter : RecyclerView.Adapter<ViewHolder>() {
    override fun onBindViewHolder(
        holder: ViewHolder,
        position: Int
    ) {
        Debug.startMethodTracing("bind_card_$position")

        holder.bind(items[position])

        Debug.stopMethodTracing()
    }
}

Confronto di due algoritmi

Il secondo esempio è un test di velocità A/B di due implementazioni: caricamento di immagini tramite Glide contro BitmapFactory manuale. Questa traccia consente il confronto oggettivo dell’Inclusive Time di entrambe le strategie e la selezione di quella ottimale. È importante eseguire ogni test su un dispositivo riscaldato (dopo 3–5 cicli) in condizioni identiche (carico di background, temperatura).

fun compareImageLoadingStrategies() {
        // Test A: Glide
    Debug.startMethodTracing("glide_test")
    loadWithGlide()
    Debug.stopMethodTracing()

        // Test B: BitmapFactory
    Debug.startMethodTracing("bitmap_test")
    loadWithBitmapFactory()
    Debug.stopMethodTracing()
}

Dopo l’esecuzione, apri entrambi i file .trace in Android Studio e confronta l’Inclusive Time nel pannello Profilo. Se Glide mostra 3x meno Inclusive Time per lo stesso compito — questa è una base oggettiva per scegliere la libreria. Secondo Tony John (sviluppatore di Glide, 2023), la libreria utilizza la memorizzazione nella cache e un pool di thread, fornendo un guadagno fino al 40% sui caricamenti ripetuti.