Latenza e jank con Perfetto su Android: una guida completa

Quando un'app Android sembra lenta, balbetta o presenta animazioni a scatti (disabilitare le animazioni di sistema)C'è quasi sempre un colpevole nascosto in agguato sullo sfondo: la latenza e il temuto jank. Android offre diversi strumenti diagnostici, ma uno dei più potenti e flessibili è perfetto, combinato con il comando classico dumpsys e fonti di dati come ftrace, atrace o heapprofdCapire come usarli correttamente consente di passare dalla vaga sensazione di "la mia app si comporta in modo strano" ad avere numeri, tracce e cause concrete.

In questo articolo analizzeremo, con calma ma direttamente, Come funziona perfetto Su Android, quali modalità di utilizzo ha, quali fonti di dati può attivare e come integra altri comandi chiave come dumpsys gfxinfo, dumpsys meminfo o dumpsys batterystatsL'idea è quella di fornirti una panoramica completa di tutto ciò che puoi misurare e di come utilizzarlo per ottimizzare la latenza, eliminare gli errori e, tra l'altro, migliorare il consumo di memoria, rete e batteria.

Cos'è Perfetto e perché è così utile per la latenza e il jank?

perfetto È uno strumento di tracciamento delle prestazioni integrato in Android. che normalmente viene richiamato dal computer utilizzando Android Debug Bridge (ADB) con comandi come adb shell perfetto ...La sua missione è quella di raccogliere informazioni di basso livello su ciò che accade sul dispositivo: attività del kernel, annotazioni dell'utente, utilizzo della memoria, statistiche di processo, ecc., il tutto in un formato di traccia che è possibile analizzare con visualizzatori come il sito Web di perfetto.dev.

Perfetto attinge a diverse “fonti dati” specializzate, tra cui spiccano:

• ftrace, che cattura gli eventi del kernel (pianificazione dei thread, file system, ecc.).
• atrace, focalizzato sulle annotazioni dallo spazio utente per servizi e applicazioni.
• heapprofd, focalizzato sul campionamento dell'utilizzo della memoria nativa nei servizi e nelle app.

Combinando opportunamente queste fontiÈ possibile registrare esattamente le informazioni necessarie per monitorare problemi di latenza dell'interfaccia utente, frame saltati, picchi della CPU o blocchi correlati all'I/O. Archiviazione UFS.

Sintassi di base di Perfetto e modalità di funzionamento

Perfetto può essere utilizzato in due modalità principali: leggera e normaleEntrambi vengono richiamati da ADB, ma differiscono notevolmente nel modo in cui configurano ciò che viene tracciato e come viene salvato.

L'idea generale è sempre la stessa: eseguire un comando adb shell perfetto specificando durata, dimensione del buffer, origini dati e file di traccia di output. Il file risultante viene in genere generato seguendo il formato del protocollo. trace.proto da AOSP, che potrai poi aprire negli strumenti di analisi di Perfetto.

Opzioni generali quando si richiama Perfetto

Indipendentemente dalla modalità (leggera o normale)Esistono diversi flag comuni che controllano come viene eseguita l'acquisizione, cosa viene fatto con il file generato e come viene integrato con i sistemi di avviso o di caricamento remoto:

• --background o -d: fa perfetto Esci dall'interfaccia della riga di comando e continua a registrare in background.
• --background-wait o -DSimile al precedente, ma attende fino a 30 secondi affinché tutte le fonti dati confermino l'avvio. Il codice di uscita sarà 0 se tutto funziona correttamente e un valore diverso da 0 in caso di errore o timeout.
• --alert-id, --config-id, --config-uid y --subscription-id: identificatori che collegano la traccia agli avvisi o attivano configurazioni definiti nel sistema, utili negli scenari di monitoraggio automatizzato.
• --out OUT_FILE o -o OUT_FILE: percorso completo in cui verrà salvato il file di traccia, oppure - se preferisci che io vada a stdoutUna directory è generalmente utilizzata come /data/misc/perfetto-traces.
• --upload: al termine della cattura, consegna il file di traccia al pacchetto specificato dal messaggio IncidentReportConfig nella configurazione del prototipo.
• --no-guardrails y --reset-guardrails: Controllano i meccanismi di sicurezza e le limitazioni delle risorse quando il caricamento automatico è attivato (--upload), progettato per i test e non tanto per la produzione.
• --rsave-for-bugreport: se la cattura ha un bugreport_score maggiore di 0, salva la traccia in un file e visualizza il percorso al termine, per un facile allegato ai report di errore.
• --query y --query-rawInterrogano lo stato del servizio di tracciamento. Il primo fornisce un output leggibile, il secondo restituisce il contenuto protocodificato di tracing_service_state.proto.
• --help o -h: Stampa la guida integrata dello strumento.

Modalità luce di Perfetto: veloce e simile a Systrace

La modalità luce di Perfetto è progettata per tracce velocimolto simile a come veniva usato storicamente systracePermette di selezionare solo un sottoinsieme di base di fonti: essenzialmente atrace y ftraceed è utile insieme app per ottimizzare le prestazioni.

Sintassi tipica in modalità leggera È più o meno così:

adb shell perfetto ... --out FILE

Tra le opzioni specifiche più rilevanti della modalità luce abbiamo trovato:

• --time TIME o -t TIME: durata della traccia in secondi, minuti o ore. Ad esempio, --time 1m Cattura per un minuto. Se non viene specificato nulla, per impostazione predefinita vengono utilizzati 10 secondi.
• --buffer SIZE o -b SIZE: dimensione del buffer circolare in memoria. Il valore predefinito è solitamente simile a --buffer 32mb.
• --size SIZE o -s SIZE: Limite massimo della dimensione del file su disco. Se non configurato, Perfetto può scrivere solo sul buffer di memoria.
• --app o -a: nome del pacchetto dell'app Android da utilizzare nelle annotazioni di atrace.

Dopo questi flag sono elencati gli “specificatori di evento”che determinano quali categorie o eventi verranno registrati:

• ATRACE_CAT: categorie di atrace che si desidera abilitare (ad esempio, wm (per WindowManager). Un comando tipico sarebbe: adb shell perfetto --out FILE wm.
• FTRACE_GROUP/FTRACE_NAME: eventi specifici di ftraceCome sched/sched_switchPotresti eseguire: adb shell perfetto --out FILE sched/sched_switch.

Modalità normale di Perfetto: massimo controllo e più fonti

La modalità normale di Perfetto è molto più potente e configurabileInvece di passare singole categorie, ti viene fornito un file di configurazione (un proto) che descrive in dettaglio quali origini dati attivare, come campionare, quali buffer utilizzare, ecc.

La sintassi usuale per la modalità normale è:

adb shell perfetto --config CONFIG_FILE --out FILE

I flag specifici che sono fondamentali in questa modalità sono:

• --config CONFIG_FILE o -c CONFIG_FILE: percorso del file di configurazione che segue lo schema di trace_config.proto in AOSP. All'interno di questo prototipo, elementi come TraceConfig y DataSourceConfig (definito in data_source_config.proto) per selezionare e parametrizzare le fonti dati.
• --txt: indica che il file di configurazione è in formato testo pbtxt invece del binario. Molto comodo per la prototipazione locale, ma non consigliato come formato di produzione finale.

Sorgenti dati compatibili Perfetto

La vera forza di Perfetto risiede nelle diverse risorse che può attivare.Ognuno di essi è configurato a partire dal prototipo attraverso un blocco di DataSourceConfigA seconda del dispositivo, della versione di Android e del kernel, avrai a disposizione più o meno opzioni.

Eventi del kernel con ftrace

La fonte ftrace Perfetto consente di catturare eventi interni del kernelche è oro colato quando si vuole capire perché un thread non viene pianificato in tempo o cosa sta bloccando la CPU in un dato momento.

Attivare ftrace dalle impostazioni il campo deve essere definito ftrace_config all'interno DataSourceConfig...selezionando gli eventi specifici che vogliamo monitorare. Alcuni esempi comuni relativi alla pianificazione dei processi sono:

• sched/sched_switch
• sched/sched_wakeup
• sched/sched_wakeup_new
• sched/sched_process_exec
• sched/sched_process_exit
• sched/sched_process_fork
• sched/sched_process_free
• sched/sched_process_hang
• sched/sched_process_wait

È possibile abilitare anche gli eventi del file system e le annotazioni di backtracking.in modo che una singola traccia catturi sia i dati del kernel che gli eventi di livello superiore. L'elenco degli eventi effettivi dipenderà sempre dal dispositivo e dal suo kernel, quindi è consigliabile consultare i protocolli di configurazione pertinenti.

Statistiche di processo e di sistema

Un'altra fonte molto pratica è quella delle statistiche di processo e del sistema stesso.Permette di ottenere contatori periodici dell'utilizzo delle risorse, sia a livello globale che per singolo processo, ideali per correlare picchi di CPU o memoria con eventi jank specifici e con app in background.

Per utilizzarlo è necessario configurare i campi. process_stats_config y sys_stats_config all'interno DataSourceConfigI dati ottenuti includono, tra le altre cose, informazioni sul tempo della CPU, sull'utilizzo della memoria e altre metriche che possono variare a seconda del dispositivo e della versione del sistema operativo.

Profili di memoria nativi con heapprofd

heapprofd È il pezzo chiave quando devi capire l'uso della memoria nativa della tua applicazione o dei servizi di sistema. Funziona tramite campionamento, generando profili che indicano quali parti del codice riservano memoria.

per accendere heapprofd in una traccia di Perfetto Devi compilare la sezione heapprofd_config de DataSourceConfig. Il risultato sono ProfilePackets con informazioni sullo stack delle chiamate, inclusi i framework Java quando disponibili. È un modo efficace per individuare falle native o modelli di allocazione inefficienti.

Documentazione pubblica in perfetto.dev Approfondisce come configurare questi profili, filtrare in base a processi specifici, regolare la frequenza di campionamento, ecc., consentendo di adattare il costo della strumentazione al livello di dettaglio necessario.

Altre fonti di dati aggiuntive

Oltre a quanto sopra, sono disponibili altre fonti a seconda del dispositivo e della versione di Android.Alcuni sono orientati all'energia, altri alla rete o a metriche di framework più specifiche. Per visualizzarli in dettaglio, è necessario esaminare i diversi schemi di configurazione per le sorgenti dati Perfetto pubblicati su AOSP.

In ogni caso, lo schema si ripete sempreScegli la sorgente, configuri il suo blocco DataSourceConfig nel prototipo di TraceConfig e lanci la traccia con perfettoQuindi, si analizza il file risultante con gli strumenti di visualizzazione.

dumpsys: il plugin perfetto per misurare latenza e prestazioni

Sebbene Perfetto sia la star per le tracce di basso livellolo strumento veterano dumpsys Rimane essenziale quando si desidera una diagnostica di alto livello, raggruppata per servizio di sistema: input, grafica, rete, batteria, memoria, ecc.

dumpsys Funziona su dispositivi Android. e viene richiamato da ADB con comandi come adb shell dumpsysSe eseguito senza parametri, il comando scarica informazioni da tutti i servizi di sistema, il che di solito è eccessivo. È meglio specificare il servizio specifico a cui si è interessati per concentrarsi esclusivamente su quella parte.

Sintassi generale del comando dumpsys

Il modo generico di chiamare dumpsys è:

adb shell dumpsys | -c | -h]

Alcuni usi comuni sarebbe:

• adb shell dumpsys: capovolge tutti i servizi (molto prolisso).
• adb shell dumpsys input: stato del sistema di input (tastiere, touch screen, ecc.).
• adb shell dumpsys -l: elenca tutti i servizi disponibili.

Tra le principali opzioni della riga di comando comprendono:

• -t timeout: tempo massimo in secondi concesso a dumpsys per completare l'operazione (predefinito, 10 s).
• --help: strumento di aiuto generico.
• -l: elenco dei servizi di sistema.
• --skip services: indica uno o più servizi che si desidera escludere dall'output quando non ne viene specificato alcuno.
• service Specifica il servizio specifico che desideri ispezionare, con argomenti facoltativi. In caso di dubbi, molti servizi accettano -h per mostrare il proprio aiuto, ad esempio adb shell dumpsys procstats -h.
• -c: fa sì che determinati servizi restituiscano i dati in un formato più adatto all'utilizzo da parte di script o strumenti.
• -h: In alcuni servizi, stampa una guida aggiuntiva specifica.

Diagnostica di input: tocchi, sequenze di tasti e latenze degli eventi

Per problemi di latenza relativi all'input touch o tramite tastieraIl servizio chiave è input. Con adb shell dumpsys input Si ottiene un dump dello stato dei dispositivi di input e del flusso di eventi dal momento in cui vengono generati fino a quando raggiungono le finestre.

L'output include tre importanti blocchi logici: lo stato dell'Event Hub, lo stato di InputReader e lo stato di InputDispatcherOgnuno di essi ti aiuta a individuare i difetti in una parte del percorso dell'evento.

Event Hub: dispositivi disponibili e relativa configurazione

In "Stato hub eventi" sono elencati tutti i dispositivi di input riconosciuti dal sistema., con informazioni quali il percorso del dispositivo, la classe, i file di layout dei tasti, i caratteri chiave e la configurazione, nonché l'identificatore della tastiera integrato (BuiltInKeyboardId).

Quando si esamina questa sezione, è consigliabile controllare:

• Che tutti i dispositivi fisici previsti siano elencati correttamente.
• A ciascun tasto è assegnato un file di layout dei tasti, una mappa dei caratteri e un file di configurazione; se questi file mancano o contengono errori di sintassi, non verranno caricati e l'esperienza di input ne risentirà.
• Che il campo Classes hanno i bit appropriati, mappati su costanti come INPUT_DEVICE_CLASS_TOUCH_MT en EventHub.h.
• Che BuiltInKeyboardId mare -2 Quando non è presente una tastiera integrata, oppure corrisponde all'ID della tastiera interna. Se vedi che non è -2 E dovrebbe esserlo; probabilmente manca una mappa di caratteri speciali per qualche tastierino numerico, che dovrebbe contenere solo type SPECIAL_FUNCTION.

InputReader: come vengono interpretati gli eventi di input

InputReader È responsabile della "traduzione" degli eventi del kernel di basso livello a qualcosa che il framework può comprendere: coordinate del tocco, pressione, dimensione del tocco, ecc. Nel suo dump, vedrai la configurazione dettagliata di ciascun dispositivo (ad esempio, uno specifico touchscreen) e le ultime azioni eseguite.

Nel caso dei touchscreen, è fondamentale controllare:

• Gli intervalli X e Y (minimi, massimi, precisione, tolleranze).
• I parametri di calibrazione (scale dimensionali, pressione, orientamento, ecc.).
• La dimensione della superficie (larghezza e altezza in pixel).
• Fattori di traslazione e scala, che determinano il modo in cui le coordinate grezze vengono mappate sullo spazio dello schermo.

I parametri globali sono elencati anche alla fine di questa sezione. come l'intervallo di tocco, le soglie di velocità del puntatore o le impostazioni dei gesti (tempo di doppio tocco, distanza minima, ecc.), che influiscono direttamente sulla sensazione di fluidità.

InputDispatcher: invio di eventi alle finestre e ANR

InputDispatcher Gestisce l'invio di eventi in arrivo alle diverse finestreIl suo stato mostra quale finestra è in primo piano, quali sono sensibili al tocco, lo stato delle code di input e se è in corso un ANR (applicazione che non risponde).

In pratica questa sezione consente di verificare:

• Quale finestra riceveva i colpi al momento del colpo? dumpsys.
• Se ci sono eventi in sospeso o code bloccate che potrebbero aumentare la latenza percepita.
• Come vengono distribuite le connessioni in entrata tra le diverse finestre e se alcune di esse stanno saturando la coda.

Un controllo semplice ma molto rivelatore Basta un tocco sullo schermo, avvialo subito adb shell dumpsys input e vedere se la linea di TouchStates Identifica correttamente la finestra che hai toccato. In caso contrario, c'è un problema con la gestione della messa a fuoco o con la mappatura dell'area di tocco.

Misurazione delle prestazioni dell'interfaccia utente con gfxinfo e framesstats

Quando la preoccupazione principale è la scarsa qualità delle animazioni e dello scorrimento, il servizio gfxinfo Lui è tuo amico. Attraverso dumpsys gfxinfo È possibile ottenere dati sui frame renderizzati per un'app specifica.

Il comando di base per un'app specifica è:

adb shell dumpsys gfxinfo package-name

Se aggiungi l'opzione framestatsLa diagnosi diventa ancora più dettagliata:

adb shell dumpsys gfxinfo package-name framestats

Questo ti fornirà statistiche sulla latenza frame per frame Questi dati provenienti da animazioni recenti sono molto utili per identificare transizioni o schermate specifiche in cui si verificano picchi nei tempi di rendering. Queste informazioni possono quindi essere integrate in test automatizzati o macrobenchmark per monitorare eventuali regressioni tra le versioni dell'app.

Diagnostica di rete con dumpsys netstats

Per capire se la latenza dell'interfaccia utente è correlata alla lentezza della rete o ai picchi di traffico, il servizio netstats È molto utile. Raccoglie statistiche sull'utilizzo della rete dal momento in cui il dispositivo viene acceso.

Il comando tipico in dettaglio è:

adb shell dumpsys netstats detail

La partenza è organizzata in diverse sezioni.:

• Interfacce attive e interfacce UID attive, dove nomi come wlan0 e il suo identificativo di rete.
• Statistiche "Dev" e "Xt", che mostrano dati storici con intervalli di tempo (ad esempio, in incrementi di un'ora) e campi come byte ricevuti (rb), pacchi ricevuti (rp), byte trasmessi (tb), eccetera.
• Statistiche per UID, in cui è possibile analizzare il consumo di rete di un'app specifica, distinguendo tra dispositivi mobili e Wi-Fi.

Per trovare l'UID della tua appSi usa qualcosa del genere:

adb shell dumpsys package your-package-name | grep userId

Una volta che conosci il valore di userId, puoi guardare l'uscita di netstats le linee con uid=ese_valor e vedere, ad esempio, quanti byte e pacchetti ha utilizzato in ogni periodo di due ore e se era in primo piano (set=DEFAULT) o sullo sfondo (set=BACKGROUND).

Batteria e consumo energetico con batterystats

La latenza e il jank non vengono risolti solo con maggiori prestazioniA volte vale anche la pena di osservare come le ottimizzazioni influiscono sul consumo energetico. dumpsys batterystats Fornisce un rapporto molto completo sull'utilizzo della batteria in base all'UID e al componente.

Il comando base per questo servizio è:

adb shell dumpsys batterystats options

Se vuoi concentrarti su un'app specifica dall'ultimo caricamentoViene utilizzato:

adb shell dumpsys batterystats --charged package-name

La partenza abituale include:

• Cronologia degli eventi relativi alla batteria.
• Statistiche globali sui dispositivi.
• Stime del consumo energetico per UID e per componenti del sistema.
• Tempo di utilizzo della rete mobile per app e pacchetto.
• Statistiche globali degli UID di sistema e app.

Formato di check-in (CSV) per analisi automatizzate

Se è necessario elaborare i dati della batteria utilizzando script o strumenti esterniÈ possibile generare un output "machine-friendly" con:

adb shell dumpsys batterystats --checkin

Questo formato presenta ogni osservazione in una riga CSV.con un identificatore di sezione che determina come interpretare gli altri campi. Alcuni esempi di sezioni sono:

• vers: versioni check-in, pacchi e piattaforma.
• uid: Relazione UID – nome del pacchetto.
• apk, pr, sr, vib, fgecc.: utilizzo di processi, sensori, vibratori, tempo di primo piano, sincronizzazioni, lavori, ecc.
• nt y gn: statistiche di rete (byte e pacchetti mobili/Wi-Fi, uptime, ecc.).
• bt, dc, lvDati sulla batteria quali tempi, livelli e scariche.
• wfl, gwfl, gble: informazioni specifiche su Wi-Fi e Bluetooth, inclusi tempi e consumo stimato in mAh.

Nelle versioni recenti di Android (6.0 e successive)Il consumo energetico di Wi-Fi, radio mobile e Bluetooth è riportato come elementi pwi con etichette dedicate (wifi, blue, cell), mentre nelle versioni precedenti era raggruppato nella sezione m (miscellanea).

Ispezione della memoria nel tempo con procstats

Se sospetti che il problema derivi da perdite di memoria o da app pesanti in esecuzione in background, dumpsys procstats Ti consente di vedere come si comporta la tua applicazione nel tempo: per quanto tempo è stata attiva, in quale stato e con quale consumo di memoria.

Un utilizzo tipico è quello di richiedere statistiche delle ultime ore, ad esempio:

adb shell dumpsys procstats --hours 3

L'output riepiloga i dati per ciascuna app. La percentuale di tempo in cui il processo è stato attivo, insieme ai valori PSS, USS e RSS sotto forma di minimo, medio e massimo, insieme al numero di campioni acquisiti. Mostra anche un riepilogo della memoria per tipo di processo (kernel, nativo, persistente, top, servizi, processi in cache, ecc.).

Questa vista aggregata aiuta a rilevare modelli Ad esempio, le applicazioni che rimangono in background per troppo tempo o che mantengono un PSS medio o massimo molto elevato sono potenziali candidate per l'ottimizzazione o potrebbero addirittura causare una pressione sulla memoria che degrada le prestazioni del sistema.

Istantanea dettagliata della memoria con meminfo

Quando è necessario uno snapshot molto granulare dell'utilizzo della memoria di un processo specifico, la herramienta es dumpsys meminfoCon esso è possibile vedere come la RAM è distribuita tra heap nativi, Dalvik/ART, mappe di codice, buffer grafici, ecc.

La sintassi di base è:

adb shell dumpsys meminfo package_name|pid

l'opzione -d Ulteriori informazioni su Dalvik/ARTmostrando dettagli interni come lo spazio per oggetti di grandi dimensioni (.LOS), sovraccarico GC, cache JIT, spazio Zygote, ecc. Con -h Puoi vedere tutte le bandiere disponibili.

Le colonne chiave da osservare sono solitamente Pss Total y Private DirtyQuesti dati riflettono, rispettivamente, l'utilizzo della RAM regolato dalla condivisione e la quantità di memoria privata modificata che verrà liberata solo al termine del processo. A volte possono anche essere di interesse. Private Clean y Heap AllocSe si rileva un consumo anomalo, controllare come liberare RAM per mitigarli.

Alcune categorie rilevanti nella tabella:

• Native Heap y Dalvik Heap: utilizzo della memoria heap nativa e della VM. Heap Alloc Mostra ciò che gli allocatori ritengono riservato, che potrebbe essere più alto del PSS a causa dell'effetto zigote e della memoria condivisa.
• .so mmap, .dex mmap, .oat mmap y .art mmap: RAM utilizzata dal codice nativo e dal bytecode, comprese le immagini ART e i loro spazi condivisi.
• .Heap, .LOS, .GC, .JITCache, .Zygote, .NonMoving, .IndirectRef (Con -d): analizza ulteriormente l'uso interno della memoria gestita da ART.
• Unknown: pagine che non potevano essere classificate nelle categorie precedenti, spesso compiti nativi visualizzati tramite ASLR.

La riga TOTALE raggruppa il PSS totale del processoche può essere confrontato con il PSS di altri processi e con la RAM disponibile. Private Dirty + Private Clean Indicano la memoria che verrà liberata quando il processo verrà terminato.

Inoltre, alla fine del rapporto sono elencati i contatori degli oggetti di alto livello. come un numero di ViewRootImpl, AppContexts o ActivitiesCiò aiuta a rilevare le perdite tipiche di contesti o attività contenute in riferimenti statici o in viste/disegni che continuano a puntare ad essi.

Vale la pena ricordare uno View o un Drawable Mantengono inoltre il riferimento al Activity da cui hanno origine, quindi una loro conservazione impropria può portare alla perdita di tutte le attività e delle risorse ad esse associate.

Combinando le tracce dettagliate di Perfetto con la diagnostica dumpsys (input, grafica, memoria, rete e batteria) fornisce una visione a 360 gradi del comportamento di un'app Android: da quando un thread è pianificato a quanti millisecondi impiega per il rendering di un frame o quanta memoria ed energia in eccesso consuma. L'utilizzo regolare di questi strumenti in fase di sviluppo e test fa la differenza tra un'app che "più o meno funziona" e una che risulta davvero fluida, stabile ed efficiente, anche su dispositivi di fascia bassa. ottimizzare Android.