Android Profiler: cos’è, funzionalità di CPU, Memory e Network

Cos'è Android Profiler?

Android Profiler è un componente di Android Studio che ha sostituito i vecchi Android Monitor e DDMS. Fornisce un'interfaccia unificata per profilare tutti gli aspetti dell'applicazione: CPU Profiler per l'analisi del processore, Memory Profiler per il lavoro con la memoria, Network Profiler per le richieste di rete ed Energy Profiler per il consumo energetico. I dati vengono raccolti automaticamente all'avvio dell'applicazione tramite Android Studio.

Il profiler funziona sia sull'emulatore che su un dispositivo fisico connesso via USB. Secondo Google I/O 2023, Android Profiler è utilizzato in oltre il 70% dei progetti Android ed è considerato lo strumento standard per la diagnostica delle prestazioni. Il vantaggio principale rispetto alle soluzioni di terze parti è l'integrazione zero: non è necessario aggiungere dipendenze in build.gradle o modificare il codice dell'applicazione.

L'architettura di Android Profiler è basata su Perfetto — il tracer di sistema di Android che raccoglie dati a livello di kernel e applicazione. Perfetto garantisce un sovraccarico minimo (meno dell'1% di CPU) e supporta la registrazione a lungo termine fino a 30 minuti. Ciò consente di profilare non solo operazioni rapide, ma anche scenari lunghi — transizioni tra schermate, sincronizzazione in background, consumo di memoria durante un'ora di utilizzo.

Quali dati raccoglie Android Profiler

Il profiler raccoglie quattro tipi di dati: CPU — carico di ogni core e thread, Memory — Java Heap, Native Heap, Stack, Graphics, Network — tutte le richieste in entrata e in uscita, Energy — categorie di consumo energetico (Idle, Light, Medium, Heavy). I dati sono sincronizzati sulla timeline — è possibile vedere simultaneamente come il cambiamento della CPU influisce sulla memoria e sul consumo energetico.

CPU Profiler: analisi del processore e dei thread

CPU Profiler mostra il carico del processore in tempo reale sulla timeline, suddiviso per thread dell'applicazione. Ogni thread è rappresentato da una linea o area colorata — più ampia è l'area, più tempo processore occupa il thread. Le aree rosse significano lavoro dell'applicazione, blu — chiamate di sistema, grigie — attesa.

Per l'analisi dettagliata, CPU Profiler supporta tre modalità di registrazione: Trace Java Methods (tracciamento di tutti i metodi Java), Trace C/C++ Functions (tracciamento delle funzioni native NDK) e Sample Java Methods (campionamento, modalità consigliata). Il campionamento offre il sovraccarico minore ed è adatto per il profiling quotidiano, mentre il tracciamento completo è utilizzato per trovare problemi complessi.

// Esempio: l’analisi CPU Profiler mostrerà questo metodo come collo di bottiglia
class DataProcessor {
    suspend fun processLargeDataset(items: List<Item>): List<Result> {
        // CPU Profiler mostrerà un carico CPU elevato in inBackgroundThread
        return withContext(Dispatchers.Default) {
            items.map { it.computeHeavyTransformation() }
        }
    }
}

// Raccomandazione dopo il profiling:
// computeHeavyTransformation occupa l’80% del tempo — memorizziamo nella cache il risultato
class DataProcessorOptimized {
    private val cache = LruCache<String, Result>(100)

    suspend fun processLargeDataset(items: List<Item>): List<Result> {
        return withContext(Dispatchers.Default) {
            items.mapNotNull { cache.get(it.id) ?: it.computeHeavyTransformation().also { cache.put(it.id, it) } }
        }
    }
}

Dopo la registrazione, CPU Profiler mostra l'Top-Down Tree — un albero di chiamate con il tempo di esecuzione di ogni metodo. Prestate attenzione alla colonna Self Time/Total: se il Self Time di un metodo supera 16 ms e viene chiamato dal thread UI — è un calo di frame garantito. La soluzione è spostare i calcoli pesanti in un thread in background tramite Dispatchers.IO o Default.

Modalità di tracciamento CPU

Sample Java Methods — modalità consigliata per il profiling quotidiano con sovraccarico del 3–5%. Trace Java Methods — tracciamento completo di ogni chiamata, sovraccarico fino al 15%, utilizzato per registrazioni brevi (5–10 secondi). Trace C/C++ Functions — tracciamento del codice NDK tramite Linux Perf, indispensabile per l'analisi di giochi e librerie C++. Cambiate modalità in base al tipo di problema.

Memory Profiler: lavoro con la memoria e ricerca di perdite

Memory Profiler monitora tutte le categorie di memoria dell'applicazione: Java Heap (oggetti JVM), Native Heap (allocazioni C/C++ tramite JNI), Stack (stack dei thread) e Graphics (texture, buffer GPU). La visualizzazione principale è il grafico temporale del consumo di memoria, dove ogni categoria è mostrata con il proprio colore. Se il grafico non diminuisce dopo la garbage collection — sospettate una perdita.

Per trovare perdite, utilizzate la funzione Capture Heap Dump. Al momento del dump, Android Profiler sospende l'applicazione per ~100 ms e crea un file HPROF — un'istantanea completa di tutti gli oggetti vivi del Java Heap. Dopo aver aperto il dump, potete ordinare gli oggetti per Retained Size (volume di memoria che verrà liberato alla rimozione dell'oggetto) e cercare istanze di Activity, Fragment o Bitmap che avrebbero dovuto essere distrutte.

Secondo Google I/O 2022, Memory Profiler in combinazione con LeakCanary copre il 95% degli scenari di rilevamento delle perdite di memoria su Android. LeakCanary funziona automaticamente — rileva le perdite in background. Memory Profiler è necessario per l'analisi manuale: vedete il quadro completo delle allocazioni, non solo le perdite.

Come interpretare un dump HPROF

Dopo aver catturato il dump, ordinate gli oggetti per Retained Size — è il volume di memoria che verrà liberato alla rimozione dell'oggetto. Cercate istanze di Activity, Fragment e Bitmap con un grande Retained Size che non dovrebbero essere in memoria. Andate alla scheda Reference Tree per vedere la catena di riferimenti che mantiene l'oggetto — di solito è un campo statico di singleton o un callback non pulito. Una metrica importante è il tasso di allocazione (numero di allocazioni al secondo). Se il tasso di allocazione supera 10.000 oggetti/s, l'applicazione dedica troppo tempo alla creazione e rimozione di oggetti temporanei, sovraccaricando il GC e causando micro-freeze. In questo caso, utilizzate lo strumento View Inspector e trovate i punti con creazione frequente di oggetti nei cicli.

Network Profiler: monitoraggio delle richieste di rete

Network Profiler mostra tutte le richieste di rete dell'applicazione in tempo reale sulla timeline. Ogni richiesta è visualizzata come una barra orizzontale — la sua lunghezza corrisponde al tempo di esecuzione, il colore — al tipo di richiesta (GET, POST, PUT, DELETE). Lo scorrimento della scala permette di vedere come le richieste sono distribuite nel tempo e se sono duplicate.

Tutte le librerie popolari sono supportate: OkHttp, Retrofit, Volley, Ktor. Per Ktor e OkHttp, il profiler mostra lo stack di chiamate completo, inclusi intercettori e convertitori. Per ogni richiesta sono disponibili Intestazioni della richiesta e Intestazioni della risposta, il corpo della risposta (fino a 1 MB), il codice di stato e la durata.

Problemi tipici identificati da Network Profiler: assenza di caching (lo stesso URL viene richiesto ad ogni apertura), richieste duplicate (due componenti caricano gli stessi dati simultaneamente), dimensione eccessiva della risposta (il server invia 5 MB quando servono 50 KB). Network Profiler aiuta a vedere questi problemi letteralmente con un'occhiata sulla timeline.

Per simulare reti lente, utilizzate Network Conditioning in Android Studio — consente di limitare la larghezza di banda a 3G/2G e aggiungere latenza. Questo è criticamente importante per testare il comportamento dell'applicazione in cattive condizioni di rete, specialmente per applicazioni che operano in regioni con internet instabile.

Energy Profiler: analisi del consumo energetico

Energy Profiler valuta l'impatto dell'applicazione sulla batteria basandosi sui dati di Perfetto. Lo strumento non misura il consumo effettivo in milliampere, ma classifica ogni operazione in una delle cinque categorie di consumo energetico: Idle, Light, Medium, High e Overloaded. La timeline di Energy Profiler è evidenziata a colori: verde (carico leggero), giallo (medio), rosso (elevato).

Principali cause delle zone rosse: WakeLock (l'applicazione mantiene il processore attivo), Posizione GPS (richieste costanti di coordinate con alta precisione), connessioni Keep-Alive (frequenti scambi di dati con il server), grandi trasferimenti di dati (invio di file, streaming). Energy Profiler mostra esattamente quale operazione in quale momento ha causato il picco di consumo energetico.

Secondo Android Developers, un'applicazione tipica non dovrebbe trascorrere più del 5% del tempo nella categoria High. Se Energy Profiler mostra zone rosse per più del 10% del tempo di profilazione — l'applicazione non supererà la revisione secondo il criterio di consumo eccessivo della batteria. Raccomandazione — utilizzate WorkManager per le attività in background, limitate le richieste di Posizione alla precisione minima necessaria e aggregate le richieste di rete in lotti.

Come usare Android Profiler: guida pratica

L'avvio di Android Profiler avviene con un clic: in Android Studio, aprite View → Tool Windows → Profiler o fate doppio clic sull'icona Profiler nel pannello destro. Dopo aver avviato l'applicazione sul dispositivo connesso, Android Studio si collegherà automaticamente al processo e inizierà la raccolta dei dati. Sulla timeline appariranno immediatamente i grafici di CPU, Memory, Network ed Energy.

Per un'analisi dettagliata, selezionate la scheda desiderata (CPU, Memory, Network o Energy) e iniziate la registrazione. Per la CPU, raccomando la modalità Sample Java Methods con una durata di registrazione di 30 secondi — è sufficiente per uno scenario tipico. Per la memoria — un dump dell'heap dopo l'esecuzione dello scenario (Capture Heap Dump). Per Network, la registrazione si avvia automaticamente, basta premere il pulsante Stop dopo aver completato lo scenario.

Dopo aver fermato la registrazione, esportate i dati: File → Save As salva l'intera sessione in un file .perf. È comodo per confrontare le metriche prima e dopo l'ottimizzazione. Create una sessione di baseline sulla prima versione stabile e confrontate ogni nuova sessione con essa — questo è l'unico modo per valutare oggettivamente i cambiamenti delle prestazioni.

Automazione del profiling in CI

Android Profiler può essere eseguito dalla riga di comando tramite Android Studio CLI e Firebase Test Lab. Firebase Test Lab supporta il profiling delle prestazioni come parte dei test dell'interfaccia utente: ottenete le metriche di CPU, Memory e Network insieme al risultato del test. Configurate la pipeline in modo che, quando le metriche calano del 10% rispetto alla baseline, la pipeline CI venga bloccata fino alla verifica da parte dello sviluppatore.