Inspect CPU activity with CPU Profiler

Ottimizzare l’utilizzo della CPU della tua app ha molti vantaggi, come fornire un’esperienza utente più veloce e più fluida e preservare la durata della batteria del dispositivo.

È possibile utilizzare il Profiler CPU per ispezionare l’utilizzo della CPU dell’app e l’attività del thread in tempo reale durante l’interazione con l’app, oppure è possibile ispezionare i dettagli in tracce di metodo registrate, tracce di funzione e tracce di sistema.

I tipi specifici di informazioni che il Profiler della CPU registra e mostra sono determinati dalla configurazione di registrazione scelta:

• Traccia di sistema: cattura dettagli a grana fine che consentono di ispezionare howyour app interagisce con le risorse di sistema.

• Tracce di metodo e funzione: per ogni thread nel processo dell’app, è possibile scoprire quali metodi (Java) o funzioni (C/C++) vengono eseguiti in un periodo di tempo e le risorse della CPU che ciascun metodo o funzione consuma durante l’esecuzione. È inoltre possibile utilizzare tracce di metodo e funzione per identificare i chiamanti e i chiamanti. Un chiamante è un metodo o una funzione che invoca un’altra funzione methodor, e un chiamato è uno che viene invocato da un altro metodo orfunction. È possibile utilizzare queste informazioni per determinare quali metodi o functionsare responsabili per richiamare particolari attività pesanti risorse troppo spesso eottimizzare il codice della tua app per evitare lavori inutili.

  Quando si registrano le tracce del metodo, è possibile scegliere sampled o instrumentedrecording. Quando la funzione di registrazione tracce, è possibile utilizzare solo la registrazione campionata.

Per i dettagli sull’utilizzo e la scelta di ciascuna di queste opzioni di traccia, vederescegli una configurazione di registrazione.

Panoramica del Profiler CPU

Per aprire il Profiler CPU, attenersi alla seguente procedura:

1. Selezionare Visualizza> Finestre degli strumenti> Profiler oppure fare clic su Profilo nella barra degli strumenti.

   Se richiesto dalla finestra di dialogo Seleziona destinazione distribuzione, scegliere il dispositivo a cui distribuire l’app per la profilazione. Se hai collegato un dispositivo su Usbma non lo vedi elencato, assicurati di aver abilitato il debug USB.

2. Fare clic in qualsiasi punto della timeline della CPU per aprire il Profiler della CPU.

Quando apri il Profiler della CPU, inizia immediatamente a visualizzare l’attività CPUusage e thread della tua app. Si dovrebbe vedere qualcosa di simile alla figura 1.

Figura 1. Linee temporali nel Profiler CPU.

Come indicato nella figura 1, la vista predefinita per il Profiler CPU include le seguenti timeline:

1. Timeline degli eventi: Mostra le attività nell’app durante la transizione attraverso diversi stati nel loro ciclo di vita e indica le interazioni dell’utente con il dispositivo, inclusi gli eventi di rotazione dello schermo. Per informazioni sull’attivazione della timeline degli eventi sui dispositivi con Android 7.1 (livello API 25) e versioni successive, vedere Abilita profilazione avanzata.
2. CPU timeline: mostra l’utilizzo della CPU in tempo reale della tua app, in percentuale del tempo totale disponibile della CPU, e il numero totale di thread utilizzati dalla tua app. La timeline mostra anche l’utilizzo della CPU di altri processi (come processi di sistema o altre app), in modo da poterlo confrontare con l’utilizzo della tua app. È possibile controllare i dati storici di utilizzo della CPU spostando il mouse lungo l’asse orizzontale della timeline.
3. Thread activity timeline: elenca ogni thread che appartiene al processo dell’app e ne indica l’attività lungo una timeline utilizzando i colori elencati di seguito. Dopo aver registrato una traccia, è possibile selezionare un thread da questa timeline per controllare i suoi dati nel riquadro traccia.
   • Verde: Il thread è attivo o è pronto per l’uso della CPU. Cioè, è in uno stato funzionante o eseguibile.
   • Giallo: Il thread è attivo, ma è in attesa di un’operazione di I/O, come I/O su disco o rete, prima che possa completare il suo lavoro.
   • Grigio: il thread sta dormendo e non sta consumando alcun tempo di CPU. Questo a volte si verifica quando il thread richiede l’accesso a una risorsa che non è ancora disponibile. O il thread entra in sospensione volontaria, o il kernel mette il thread in sospensione fino a quando la risorsa richiesta diventa disponibile.

   La CPU Profiler riporta anche l’utilizzo della CPU di thread che Android Studio e la piattaforma Android aggiungere alla vostra app processo—come JDWPProfile SaverStudio:VMStatsStudio:Perfa e Studio:Heartbeat (anche se il nome esatto visualizzato nel thread attività timeline possono variare). Android Studio riporta questi dati in modo da poter identificare quando l’attività del thread e l’utilizzo della CPU sono effettivamente causati dal codice della tua app.

Registra tracce

Per avviare la registrazione di una traccia, scegliere una configurazione di registrazioneda uno dei menu a discesa sopra o sotto il Profiler CPU e fare clic su Registra.

Figura 2. Il Profiler CPU visualizza lo stato, la durata e il tipo di registrazione effettuata.

Interagisci con la tua app, quindi fai clic su Interrompi quando hai finito. Theprofiler visualizza automaticamente le informazioni di traccia nel riquadro di traccia, asshown in figura 3:

Figura 3. Il Profiler CPU dopo la registrazione amethod traccia.

1. Intervallo selezionato: determina la porzione del tempo registrato da ispezionare nel riquadro traccia. Quando si registra per la prima volta una traccia, il Profiler CPU seleziona automaticamente l’intera lunghezza della registrazione nella timeline della CPU. Per ispezionare i dati di traccia solo per una parte dell’intervallo di tempo registrato, trascinare i bordi della regione evidenziata.
2. Sezione Interazione: visualizza l’interazione dell’utente e gli eventi del ciclo di vita dell’app lungo una timeline.
3. Sezione Thread: visualizza l’attività dello stato del thread(come corsa, sonno, ecc.) e Call Chart (o trace event chart in System Trace) per ogni thread lungo una timeline.
   • Usa il mouse e le scorciatoie da tastiera per navigare nella timeline.
   • Fare doppio clic sul nome del thread o premere Invio mentre un thread è selezionato per espandere o comprimere un thread.
   • Selezionare un thread per visualizzare ulteriori informazioni nel riquadro Analisi. Tieni premuto Maiusc o Ctrl (Comando su Mac) per selezionare più thread.
   • Selezionare una chiamata di metodo (o un evento trace in System Trace) per visualizzare ulteriori informazioni nel riquadro Analisi.
4. Riquadro analisi: Visualizza i dati di traccia per l’intervallo di tempo e la chiamata thread o metodo selezionata. In questo riquadro, è possibile selezionare come visualizzare ogni traccia di stack (utilizzando le schede Analisi) e come misurare il tempo di esecuzione (utilizzando il menu a discesa Riferimento temporale).
5. Schede del riquadro Analisi: scegliere come visualizzare i dettagli della traccia. Per i dettagli su ciascuna opzione, vedere Controllare le tracce.
6. Time reference menu: selezionare una delle seguenti opzioni per determinare come vengono misurate le informazioni di temporizzazione per ogni chiamata (supportate solo nei metodi Java Sample/Trace):
   • Wall clock time: Le informazioni di temporizzazione rappresentano il tempo trascorso effettivo.
   • Tempo del thread: le informazioni di temporizzazione rappresentano il tempo trascorso effettivo meno qualsiasi parte di quel tempo quando il thread non consuma risorse della CPU. Per ogni chiamata data, il suo tempo di thread è sempre inferiore o uguale al suo tempo di orologio da parete. L’utilizzo del tempo di thread offre una migliore comprensione di quanto l’utilizzo effettivo della CPU di un thread viene consumato da un determinato metodo o funzione.
7. Filtro: filtra i dati di traccia per funzione, metodo, classe o nome del pacchetto. Ad esempio, se si desidera identificare rapidamente i dati di traccia relativi a una chiamata specifica, digitare il nome nel campo di ricerca. Nella scheda Grafico Fiamma, vengono enfatizzati gli stack di chiamate che includono una chiamata, un pacchetto o una classe corrispondente alla query di ricerca. Nelle schede Top down e Bottom up, tali stack di chiamate hanno la priorità su altri risultati di traccia. È inoltre possibile abilitare le seguenti opzioni selezionando la casella appropriata accanto al campo di ricerca:
   • Regex: Per includere espressioni regolari nella ricerca, utilizzare questa opzione.
   • Caso di corrispondenza: Se la ricerca è case-sensitive, utilizzare questa opzione.

Scegliere una configurazione di registrazione

Prima di iniziare a registrare le informazioni di traccia, scegliere la configurazione di registrazione appropriata per le informazioni di profilazione che si desidera acquisire:

• Metodi Java di esempio: cattura lo stack di chiamate dell’app a intervalli frequenti durante l’esecuzione del codice basato su Java dell’app. Il profiler confronta i set di dati acquisiti per ricavare informazioni sull’utilizzo delle risorse e sui tempi di esecuzione del codice basato su Java dell’app.

  Un problema inerente al tracciamento basato su campionamento è che se l’app entra in un metodo dopo un’acquisizione dello stack di chiamate e esce dal metodo prima dell’acquisizione successiva, tale chiamata al metodo non viene registrata dal profiler. Se siete interessati a metodi di tracciamento con cicli di vita così brevi, è necessario utilizzare la traccia strumentata.

• Trace Java Methods: Instrumenta la tua app in fase di runtime per registrare un timestamp all’inizio e alla fine di ogni chiamata al metodo. I timestamp vengono raccolti e confrontati per generare dati di tracciamento dei metodi, incluse le informazioni sui tempi e l’utilizzo della CPU.

  Si noti che il sovraccarico associato alla strumentazione di ciascun metodo influisce sulle prestazioni di runtime e può influenzare i dati di profilazione; questo è ancora più evidente per i metodi con cicli di vita relativamente brevi. Inoltre, se l’app esegue un numero elevato di metodi in breve tempo, il profiler potrebbe superare rapidamente il limite di dimensione del file e potrebbe non essere in grado di registrare ulteriori dati di tracciamento.

• Funzioni di esempio C / C++: cattura le tracce campionate dei thread nativi della tua app. Per utilizzare questa configurazione, è necessario distribuire l’app su un dispositivo con Android 8.0 (livello API 26) o superiore.

  Internamente, questa configurazione utilizza simpleperf per tracciare il codice nativo dell’app. Se si desidera specificare opzioni aggiuntive per simpleperf, come il campionamento di CPU specifiche del dispositivo o la specifica delle durate di campionamento con un’elevata precisione, è possibile utilizzare simpleperf dalla riga di comando.

• Trace System Calls: cattura dettagli a grana fine che consentono di controllare come l’app interagisce con le risorse di sistema. È possibile controllare i tempi e le durate esatti degli stati del thread, visualizzare i colli di bottiglia della CPU in tutti i core e aggiungere eventi di traccia personalizzati da analizzare. Tali informazioni possono essere cruciali quando si risolvono problemi di prestazioni. Per utilizzare questa configurazione, è necessario distribuire l’app su un dispositivo con Android 7.0 (livello API 24) o superiore.

  Durante l’utilizzo di questa configurazione di traccia, è possibile contrassegnare visivamente le routine di codice importanti nella timeline del profiler strumentando il codice. Per instrumentare il codice C / C++, utilizzare l’API di tracciamento nativa fornita da trace.h. Per instrumentare il codice Java, utilizzare la classeTrace. Per ulteriori informazioni, vedere Strumento del codice dell’app.

  Questa configurazione di traccia è basata su systrace. È possibile utilizzare l’utilità da riga di comando systrace per specificare opzioni oltre a quelle fornite nel Profiler CPU. I dati aggiuntivi a livello di sistema forniti da systrace possono aiutare a ispezionare i processi di sistema nativi e a risolvere i problemi relativi ai frame persi o ritardati.

  Sui dispositivi con Android 9 (livello API 28) o superiore, è possibile utilizzare un’app di sistema chiamata System Tracing per registrare le tracce di sistema su un dispositivo.

Creare, modificare o visualizzare una configurazione di registrazione

Creare, modificare e visualizzare le configurazioni di registrazione nella finestra di dialogo CPU RecordingConfigurations, che si apre selezionando Modifica configurazionidal menu a discesa Configurazioni di registrazione nella parte superiore del Profiler CPU.

Per visualizzare le impostazioni di una configurazione di registrazione esistente, selezionarla nel riquadro a sinistra della finestra di dialogo Configurazioni di registrazione CPU.

Per creare una nuova configurazione di registrazione, procedere come segue:

1. Fare clic su Aggiungi in alto a sinistra della finestra di dialogo. Questo crea una nuova configurazione con alcuniimpostazioni predefinite.
2. Assegna un nome alla tua configurazione.
3. Selezionare una tecnologia di traccia.
4. Per le configurazioni di registrazione campionate, specificare l’intervallo di campionamento in microsecondi (µs). Questo valore rappresenta il tempo tra ogni esempio di stack di chiamate della tua app. Più breve è l’intervallo specificato, più velocemente il tuoraggiungere il limite di dimensione del file per i dati registrati.
5. Specificare il limite di dimensione del file, in megabyte (MB), per i dati registrati che sono stati scritti sul dispositivo collegato. Quando si interrompe la registrazione, AndroidStudio analizza questi dati e li visualizza nella finestra del profiler. Quindi, se si aumenta il limite e si registra una grande quantità di dati, Android Studio richiede molto più tempo per analizzare il file e potrebbe non rispondere.

   Nota: se si utilizza un dispositivo connesso con Android 8.0 (livello API 26) o superiore, non vi è alcun limite alla dimensione del file dei dati di traccia e thisvalue viene ignorato. Tuttavia, è ancora necessario fare attenzione a quanti datiil dispositivo raccoglie dopo ogni registrazione-Android Studio potrebbe avere difficoltàparsa di file di traccia di grandi dimensioni. Ad esempio, se stai registrando un sampledtrace con un breve intervallo di campionamento o una traccia strumentata mentre appcalls molti metodi in breve tempo, genererai rapidamente file di traccia di grandi dimensioni.

6. Per accettare le modifiche e continuare ad apportare modifiche ad altre configurazioni,fare clic su Applica. Per accettare tutte le modifiche applicate e chiudere la finestra di dialogo, fare clic su Ok.

Registra l’attività della CPU con l’API di debug

Puoi utilizzare l’APIDebug per dare alla tua app la possibilità di avviare e interrompere la registrazione dell’attività della CPU nel Profiler della CPU.

Il Profiler CPU inizia la registrazione quando l’app chiamastartMethodTracing(String tracePath)e il Profiler CPU interrompe la registrazione quando l’app chiamastopMethodTracing(). Whilerecording attività della CPU che viene attivato utilizzando questa API, il profiler CPU showsDebug API come la configurazione di registrazione CPU attiva.

Per controllare la registrazione dell’attività della CPU con l’API Debug, distribuire l’app instrumented su un dispositivo con Android 8.0 (livello API 26) o superiore.

Per ulteriori informazioni, vedegenerate i log di traccia strumentando l’app.

Registra l’attività della CPU durante l’avvio dell’app

Per iniziare a registrare automaticamente l’attività della CPU durante l’avvio dell’app, eseguire le seguenti operazioni:

1. Selezionare Esegui> Modifica configurazioni.
2. Nella scheda Profiling, seleziona la casella accanto a Avvia registrazione di un methodtrace all’avvio.
3. Selezionare una configurazione di registrazione CPU dal menu.
4. Fare clic su Applica.
5. Distribuisci la tua app su un dispositivo con Android 8.0 (livello API 26) o superiore byselecting Run> Profile.

Esporta tracce

Dopo aver registrato l’attività della CPU con il profiler CPU, è possibile esportare i dati asa.trace file da condividere con gli altri o ispezionare in seguito.

Per esportare un file di traccia dalla timeline della CPU, procedere come segue:

1. Nella timeline della CPU, fare clic con il pulsante destro del mouse sulla traccia del metodo registrato o sulla traccia di sistema che si desidera esportare.
2. Selezionare Esporta traccia dal menu.
3. Individuare dove si desidera salvare il file, specificare il nome del file e fare clickOK.

Per esportare un file di traccia dal riquadro Sessioni, effettuare le seguenti operazioni:

1. Nel riquadro Sessioni, fare clic con il pulsante destro del mouse sulla traccia registrata che si desidera esportare.
2. Fare clic sul pulsante Esporta traccia metodo o Esporta traccia sistema alla destra della voce di sessione.
3. Individuare dove si desidera salvare il file, specificare il nome del file e fare clickOK.

Importa tracce

È possibile importare.trace file creati conDebug API o Profiler CPU.

Importa il tuo file di traccia facendo clic su Avvia nuova sessione profiler nel riquadro Sessioni del profiler e quindi selezionando Carica da file.

È possibile ispezionare una traccia importata nel Profiler della CPU proprio come si fa con le tracce acquisite direttamente nel Profiler della CPU, con le seguenti eccezioni:

• L’attività della CPU non è rappresentata lungo la timeline della CPU (tranne che nella Traccia di sistema).
• La timeline nella sezione Thread non mostra stati di thread come esecuzione, attesa o sospensione (tranne nella traccia di sistema).

Ispeziona tracce

La vista traccia nel Profiler CPU fornisce diversi modi per visualizzare le informazionida tracce registrate.

Per le tracce di metodo e le tracce di funzione, è possibile visualizzare il grafico delle chiamate direttamente nella timeline dei thread e le schede Flame Chart, Top Down e Bottom Up dal riquadro Analisi. Per le tracce di sistema, è possibile visualizzare gli eventi di traccia direttamente nella timeline dei thread e le schede Grafico Flame, dall’alto verso il basso e dal basso verso l’alto dalla scheda Analysispane.

Mouse e tasti di scelta rapida sono disponibili per easiernavigation di grafici di chiamata o eventi di traccia.

Ispeziona le tracce utilizzando il grafico delle chiamate

Il grafico delle chiamate fornisce una rappresentazione grafica di una traccia di metodo o di una traccia di funzione, in cui il periodo e la tempistica di una chiamata sono rappresentati sull’asse orizzontale e le sue chiamate sono mostrate lungo l’asse verticale. Le chiamate alle API di sistema sono mostrate in arancione, le chiamate ai metodi della tua app sono mostrate in blu e le chiamate alle API di terze parti (incluse le API del linguaggio Java) sono mostrate in blu. Figura 4 mostra un esempio di call chart e illustra il concetto ofself tempo, bambini tempo, e il tempo totale per un determinato metodo o funzione. Canlearn di più su questi concetti nella sezione su come toinspect tracce utilizzando Top Down e Bottom Up.

Figura 4. Un esempio di grafico di chiamata che illustraesself, children e total time per il metodo D.

Tip: Per saltare il codice sorgente di un metodo o di una funzione, fare clic destro su di esso e selezionare Salta all’origine. Funziona da una qualsiasi delle schede del riquadro Analisi.

Controllare le tracce utilizzando la scheda Grafico fiamma

La scheda Grafico fiamma fornisce un grafico chiamata invertita che aggregatesidentical stack di chiamate. Cioè, metodi o funzioni identici che condividono la stessa sequenza di chiamanti vengono raccolti e rappresentati come una barra più lunga nel grafico aflame (piuttosto che visualizzarli come più barre più corte, come mostrato nel grafico acall). Ciò rende più facile vedere quali metodi o funzioni consumano la maggior parte del tempo. Tuttavia, questo significa anche che l’asse orizzontale non rappresenta atimeline; invece, indica la quantità relativa di tempo che ogni metodo o funzione impiega per essere eseguito.

Per illustrare questo concetto, si consideri il grafico delle chiamate in figura 5. Nota che il metodo D effettua più chiamate a B (B1, B2, andB3) e alcune di queste chiamate a B effettuano una chiamata a C (C1 andC3).

Figura 5. Un grafico di chiamata con più chiamate di metodiche condividono una sequenza comune di chiamanti.

Poiché B1, B2 e B3 condividono la stessa sequenza di chiamanti (A → D → B) vengono aggregati, come mostrato in figura 6. Allo stesso modo, C1 e C3 sono aggregati perché condividono la stessa sequenza di chiamanti (A → D → B → C); si noti che C2 non è includedbecause ha una diversa sequenza di chiamanti (A → D → C).

Figura 6. Aggregare metodi identici che condividonolo stesso stack di chiamate.

Le chiamate aggregate vengono utilizzate per creare il grafico flame, come mostrato in figura 7.Si noti che, per ogni data chiamata in un grafico a fiamma, le chiamate che consumano la maggior parte del tempo della CPU appaiono per prime.

Figura 7. Una rappresentazione grafico fiamma del callchart mostrato in figura 5.

Ispeziona le tracce usando Top Down e Bottom Up

La scheda Top Down visualizza un elenco di chiamate in cui l’espansione di un nodo metodo o funzione visualizza i relativi callee. Figura 8 mostra un grafico dall’alto verso il basso per il callchart in figura 4. Ogni freccia nel grafico punta da un chiamante a un chiamato.

Come mostrato in figura 8, espandendo il nodo per il metodo A nella scheda Top downdisplega i suoi callees, i metodi B e D. Successivamente, espandendo il nodo per methodD espone i suoi callees, i metodi B e C e così via. Simile a Flame charttab, l’albero dall’alto verso il basso aggrega le informazioni di traccia per metodi identici che condividono lo stesso stack di chiamate. Cioè, la scheda Grafico Fiamma fornisce una graficarappresentazione della scheda Top down.

Il Top-Down scheda fornisce le seguenti informazioni per aiutare a descrivere CPUtime speso su ogni chiamata (i tempi sono anche rappresentata come percentuale del thethread tempo totale oltre il range):

• Auto: il tempo, il metodo o funzione chiamata impiegato per l’esecuzione di proprie codeand non che dei suoi chiamati, come illustrato in figura 4 per il metodo D.
• Bambini: il tempo, il metodo o funzione chiamata impiegato per l’esecuzione di itscallees e non il proprio codice, come illustrato in figura 4 per il metodo D.
• Totale: è la somma del metodo di Sé e Bambini il tempo. Thisrepresents the total time the app spent executing a call,as illustrated infigure 4 for method D.

Figura 8. Un albero dall’alto verso il basso.

Figura 9. Un albero dal basso verso l’alto per il metodo C da figura 8.

La scheda Dal basso verso l’alto visualizza un elenco di chiamate in cui l’espansione di una funzione o il nodo del metodo visualizza i suoi chiamanti. Utilizzando la traccia di esempio mostrato in figura 8, figura 9 fornisce un albero dal basso verso l’alto per il metodo C. Aprendo il nodo per il metodo Cin l’albero bottom up visualizza ciascuno dei suoi chiamanti univoci, i metodi B e D. Nota che, sebbene B chiami C due volte, B appare solo una volta quando si espande il nodo formethod C nell’albero bottom up. Successivamente, espandendo il nodo per B visualizzail suo chiamante, i metodi A e D.

La scheda Bottom Up è utile per ordinare metodi o funzioni da quelli checonsumare il tempo di CPU più (o meno). È possibile ispezionare ogni nodo per determinareche i chiamanti trascorrono la maggior parte del tempo della CPU invocando tali metodi o funzioni.Rispetto all’albero top down, le informazioni di temporizzazione per ciascun metodo o funzione nell’albero abottom up fanno riferimento al metodo nella parte superiore di ciascun albero (nodo superiore).Il tempo della CPU è anche rappresentato come percentuale del tempo totale del thread durante la registrazione. La seguente tabella aiuta a spiegare come interpretare timinginformation per il nodo superiore e i suoi chiamanti (sotto-nodi).

	Auto	Bambini	Totale
Metodo o una funzione in alto a basso albero (nodo superiore)	Rappresenta il tempo totale funzione o metodo impiegato per l’esecuzione di un codice proprio e non quello dei suoi chiamati. Rispetto all’albero dall’alto verso il basso, questa informazione di temporizzazione rappresenta una somma di tutte le chiamate a questo metodo o funzione per tutta la durata della registrazione.	Rappresenta il tempo totale che il metodo o la funzione ha trascorso eseguendo i suoi callee e non il proprio codice. Rispetto all’albero dall’alto verso il basso, questa informazione di temporizzazione rappresenta la somma di tutte le chiamate a questo metodo o alle chiamate della funzione per tutta la durata della registrazione.	La somma del tempo di sé e del tempo dei bambini.
Chiamanti (sotto-nodi)	Rappresenta il tempo di auto totale del chiamato quando viene chiamato dal chiamante. Usando l’albero dal basso verso l’alto in figura 9 come esempio, il tempo di auto per il metodo B sarebbe uguale alla somma dei tempi di auto per ogni esecuzione del metodo C quando chiamato da B.	Rappresenta il tempo totale dei figli del chiamato quando viene invocato dal chiamante. Usando l’albero dal basso verso l’alto in figura 9 come esempio, il tempo dei bambini per il metodo B sarebbe uguale alla somma dei tempi dei bambini per ogni esecuzione del metodo C quando chiamato da B.	La somma del tempo di auto e del tempo dei bambini.

Nota: Per una data registrazione, Android Studio interrompe la raccolta di nuovi dataquando il profiler raggiunge il limite di dimensione del file(tuttavia, questo non interrompe la registrazione). Questo accade in genere molto più rapidamente quando si eseguono tracce instrumented perché questo tipo di traccia raccoglie più dati in un tempo più breve, rispetto a una traccia campionata. Se si estende il tempo di ispezione in aperiod della registrazione che si è verificato dopo aver raggiunto il limite, i dati di temporizzazione nel riquadro di traccia non cambiano (perché non sono disponibili nuovi dati). Inoltre, il riquadro traccia visualizza NaN per informazioni di temporizzazione quando si seleziona onlythe porzione di una registrazione che non ha dati disponibili.

Ispezionare le tracce di sistema

Quando si ispeziona una traccia di sistema, è possibile esaminare gli eventi di traccia nella timeline theThreads per visualizzare i dettagli degli eventi che si verificano su ogni thread.Passa il puntatore del mouse su un evento per visualizzare il nome dell’evento e il tempo trascorso in ogni stato. Fare clic su un evento per visualizzare ulteriori informazioni nel riquadro Analisi.

Il riquadro Core CPU (come mostrato in figura 10) mostra l’attività del thread scheduledon ogni core. Passa il puntatore del mouse su un’attività thread per vedere whichthread su cui è in esecuzione questo core in quel particolare momento.

Figura 10. Visualizzazione dell’attività della CPU e degli eventi di traccia per il thread di rendering.

Per ulteriori informazioni sull’ispezione delle informazioni sulla traccia del sistema, consultare la sezione Investigate UI performance problemssection della documentazione systrace.

Ispeziona i dati di rendering dei frame

Puoi controllare quanto tempo impiega la tua app per eseguire il rendering di ogni frame su mainthread eRenderThread per indagare sui colli di bottiglia che causano UI jank e lowframerates.

Per visualizzare i dati di rendering dei frame,registrare una traccia utilizzando una configurazione che consente di tracciare le chiamate di sistema. Dopo aver registrato thetrace, cercare informazioni su ogni fotogramma sotto i fotogrammi timeline inthe Display sezione, come mostrato in figura 11.

Figura 11. Ogni fotogramma che richiede più di 16 msè visualizzato in rosso.