Valutare il rendimento

Utilizza le funzionalità di Perf per valutare le prestazioni di un dispositivo. SimplePerf è uno strumento di profilazione nativo e processi nativi su Android. Utilizza le funzionalità di Profilo CPU per esaminare l'utilizzo della CPU dell'app e l'attività dei thread in tempo reale.

Esistono due indicatori di rendimento visibili all'utente:

• Prestazioni prevedibili e percepibili. L'utente dell'interfaccia utente o di eseguire un rendering costante a 60 f/s? L'audio viene riprodotto senza artefatti o scoppi? Quanto tempo passa tra il tocco da parte dell'utente e il suo tocco lo schermo e l'effetto visualizzato sul display?
• Tempo necessario per operazioni più lunghe (ad esempio aprire le app).

La prima è più evidente della seconda. Gli utenti notano tipicamente i jank ma non saranno in grado di stabilire il tempo di avvio dell'app tra 500 ms e 600 ms a meno che due dispositivi uno accanto all'altro. La latenza del tocco è immediatamente percettibile e contribuisce in modo significativo alla percezione di un dispositivo.

Di conseguenza, in un dispositivo veloce, la pipeline UI è l'aspetto più importante il sistema, tranne quello necessario per mantenere funzionale la pipeline dell'interfaccia utente. Questo significa che la pipeline UI deve prerilasciare qualsiasi altro lavoro non necessario per una UI fluida. Per mantenere un'UI fluida, la sincronizzazione in background e l'invio delle notifiche, e lavori simili devono essere tutti ritardati se è possibile eseguire il lavoro dell'interfaccia utente. È accettabile per negoziare le prestazioni di operazioni più lunghe (tempo di esecuzione HDR+, l'avvio dell'app e così via) per mantenere un'interfaccia utente fluida.

Capacità e jitter

Quando si considerano le prestazioni, la capacità e il jitter del dispositivo sono due metriche significative.

Capacità

La capacità è la quantità totale di alcune risorse di cui il dispositivo possiede oltre per un po' di tempo. Possono essere risorse CPU, risorse GPU, risorse I/O, delle risorse di rete, della larghezza di banda della memoria o di metriche simili. Durante l'esame le prestazioni dell'intero sistema, può essere utile astrarre i singoli componenti e supponiamo che sia una sola metrica a determinare le prestazioni (soprattutto durante l'ottimizzazione dispositivo nuovo perché i carichi di lavoro eseguiti su quel dispositivo sono probabilmente risolti).

La capacità di un sistema varia in base alle risorse di calcolo online. La modifica della frequenza di CPU/GPU è il mezzo principale per modificare la capacità, ma altri, come la modifica del numero di core CPU online. Di conseguenza, la capacità di un sistema corrisponde al consumo di energia; modifica comporta sempre una variazione simile del consumo energetico.

La capacità richiesta in un dato momento è determinata in modo schiacciante dal in esecuzione. Di conseguenza, la piattaforma può fare poco per modificare necessaria per un determinato carico di lavoro e i mezzi per farlo sono limitati a miglioramenti del runtime (framework Android, ART, Bionic, compilatore/driver GPU, ).

Tremolio

Mentre la capacità richiesta per un carico di lavoro è facilmente visibile, il jitter è un concetto nebulosa. Per un'introduzione efficace al tremolio come impedimento alla velocità sistemi, fai riferimento IL CASO DI PRESTAZIONI MANCANTE DEL SUPERCOMPUTER: OTTENERE UN RENDIMENTO OTTIMIZZATO SU GLI 8192 PROCESSI DI ASCl Q. (Si tratta di un'indagine sul perché l'ASCI Q supercomputer non ha raggiunto le prestazioni previste ed è un ottimo un'introduzione all'ottimizzazione di sistemi di grandi dimensioni.)

In questa pagina viene utilizzato il termine tremolio per descrivere ciò che viene chiamato nell'articolo ASCI Q rumore. Il jitter è il comportamento del sistema casuale che impedisce l'esecuzione del lavoro. Spesso è un lavoro che deve essere eseguito, ma potrebbe non avere requisiti di tempo che ne determinano l'esecuzione in un determinato momento. Perché è estremamente difficile confutare l'esistenza di una tremolio per una un determinato carico di lavoro. Inoltre, è estremamente difficile dimostrare che una fonte nota di era la causa di un particolare problema di prestazioni. Gli strumenti più comuni utilizzate per diagnosticare le cause del tremolio (come il tracciamento o la registrazione) possono introdurre il proprio nervosismo.

Cause del tremolio riscontrate nelle implementazioni reali di Android include:

• Ritardo scheduler
• Gestori di interruzioni
• Codice del driver in esecuzione troppo a lungo con prerilascio o interruzioni disattivati
• Softirq di lunga data
• Conflitto blocco (app, framework, driver kernel, blocco binder, mmap blocco)
• Conflitto del descrittore di file in cui un thread a bassa priorità contiene il blocco su un che impedisce l'esecuzione di un thread ad alta priorità
• Esecuzione di codice critico per l'interfaccia utente nelle code di lavoro in cui potrebbe subire ritardi
• Transizioni CPU inattive
• Logging
• Ritardi I/O
• Creazione di processi non necessari (ad esempio, trasmissioni CONNECTIVITY_CHANGE)
• Thrashing della cache della pagina causato da memoria libera insufficiente

La quantità di tempo richiesta per un determinato periodo di jitter può o meno diminuiranno con l'aumento della capacità. Ad esempio, se un conducente lascia delle interruzioni disattivato durante l'attesa di una lettura da un bus i2c, seguirà un indipendentemente dal fatto che la CPU sia a 384 MHz o 2 GHz. In aumento non è una soluzione fattibile per migliorare le prestazioni in caso di jitter coinvolti. Di conseguenza, i processori più veloci di solito non migliorano in situazioni di tremolio.

Infine, a differenza della capacità, il jitter è quasi interamente all'interno del dominio fornitore di sistema.

Consumo della memoria

Il consumo della memoria è tradizionalmente responsabile delle prestazioni scadenti. Mentre il consumo di per sé non è un problema di prestazioni, ma può causare un tremolio l'overhead lowmemorykiller, i riavvii dei servizi e lo thrashing della cache delle pagine. In riduzione il consumo di memoria può evitare le cause dirette di uno scarso rendimento, ma potrebbero essere altri miglioramenti mirati che eludono quelle cause (ad esempio, bloccare il framework per evitare che venga impaginato quando verrà impaginato dopo poco tempo).

Analizzare le prestazioni iniziali del dispositivo

Iniziare da un sistema funzionante ma con prestazioni scadenti e tentare di risolvere il problema il comportamento del sistema esaminando i singoli casi di scarsa visibilità le prestazioni non sono una buona strategia. Perché lo scarso rendimento solitamente non sono facilmente riproducibili (ovvero tremolio) o anche un problema dell'app molte variabili nell'intero sistema impediscono l'efficacia di questa strategia. Come un risultato, è molto facile identificare in modo erroneo le cause e apportare piccoli miglioramenti, mentre non abbiano opportunità sistemiche per correggere il rendimento in tutto il sistema.

Usa invece il seguente approccio generale quando apri una nuova dispositivo:

1. Fai in modo che il sistema si avvii nella UI con tutti i driver in esecuzione e alcuni di base le impostazioni del governatore di frequenza (se le modifichi, ripeti tutti i passaggi riportati di seguito).
2. Assicurati che il kernel supporti il tracepoint sched_blocked_reason nonché altri tracepoint nella pipeline di visualizzazione che indicano quando il frame viene inviato al display.
3. Acquisisci lunghe tracce dell'intera pipeline dell'interfaccia utente (dalla ricezione di input tramite un IRQ) alla scansione finale) durante l'esecuzione di un carico di lavoro leggero e coerente (ad esempio, UiBench o il test con la palla in Latenza tocco).
4. Correggi i rilasci di frame rilevati nella versione leggera e coerente carico di lavoro.
5. Ripeti i passaggi 3-4 finché non riesci a correre senza frame interrotti per più di 20 secondi alla volta.
6. Passa ad altre origini di jank visibili all'utente.

Altre semplici cose che puoi fare nella fase iniziale di richiamo del dispositivo includono:

• Assicurati che il kernel abbia sched_blocco_motivo patch tracepoint. Questo tracepoint è abilitato con la categoria di traccia pianificata in systrace e fornisce la funzione responsabile del sonno quando il thread entra in una modalità di sospensione senza interruzioni. È fondamentale per l'analisi delle prestazioni perché un sonno ininterrotto è un indicatore molto comune di tremolio.
• Assicurati di avere un tracciamento sufficiente per le pipeline della GPU e della visualizzazione. Attivato SOC Qualcomm recenti, i tracepoint vengono abilitati utilizzando:

adb shell "echo 1 > /d/tracing/events/kgsl/enable"
adb shell "echo 1 > /d/tracing/events/mdss/enable"

Questi eventi rimangono abilitati quando esegui systrace per consentirti di visualizzare nella traccia della pipeline di visualizzazione (MDSS) nella Sezione mdss_fb0. Nei SOC Qualcomm, non vengono visualizzate altre informazioni sulla GPU nella visualizzazione di sistema standard, ma i risultati presenti nella traccia stessa (per maggiori dettagli, Comprensione systrace).

In questo tipo di tracciamento del display, ciò che si vuole ottenere è un singolo evento indica direttamente che un frame è stato pubblicato sul display. Da qui, puoi stabilire se hai raggiunto la durata frame correttamente; se evento Xn si verifica meno di 16,7 ms dopo l'evento Xn-1 (supponendo che il display a 60 Hz) allora sai di non avere schiacciato. Se il SOC non fornisce questi indicatori, con il tuo fornitore per ottenerle. Il debug del tremolio è estremamente difficile senza una segnale definitivo di completamento del frame.

Utilizza benchmark sintetici

I benchmark sintetici sono utili per garantire le funzionalità di base di un dispositivo è presente. Tuttavia, considerare i benchmark come un sostituto del dispositivo percepito le prestazioni non sono utili.

In base alle esperienze con i SOC, le differenze nel benchmark sintetico le prestazioni tra i SOC non sono correlate a una differenza simile prestazioni UI percepibili (numero di frame eliminati, frame al 99° percentile tempo ecc.). I benchmark sintetici sono benchmark basati solo sulla capacità, tremolio impatti il rendimento misurato di questi benchmark solo rubando il tempo funzionamento del benchmark. Di conseguenza, i punteggi di benchmark sintetici sono irrilevante come metrica di rendimento percepito dall'utente.

Considera due SOC che eseguono il Benchmark X per il rendering di 1000 frame dell'UI e indica il tempo di rendering totale (è migliore il punteggio più basso).

• Il SOC 1 esegue il rendering di ogni frame del Benchmark X in 10 ms e ottiene un punteggio pari a 10.000.
• SOC 2 esegue il rendering del 99% dei frame in 1 ms, ma dell'1% dei frame in 100 ms e dei punteggi 19.900, un punteggio notevolmente migliore.

Se il benchmark è indicativo delle effettive prestazioni dell'UI, il SOC 2 verrebbe inutilizzabile. Supponendo una frequenza di aggiornamento di 60 Hz, SOC 2 avrebbe un frame scocciante ogni 1,5 secondi di funzionamento. Nel frattempo, SOC 1 (il SOC più lento secondo il Benchmark X) sarebbe perfettamente fluida.

Utilizza le segnalazioni di bug

A volte le segnalazioni di bug sono utili per l'analisi del rendimento, ma poiché sono così pesanti che raramente sono utili per il debug di sporadici problemi di jank. Ti possono fornire suggerimenti su cosa stava facendo il sistema in un dato momento, in particolare se il jank era legato alla transizione di un'app (che ha eseguito l'accesso una segnalazione di bug). Le segnalazioni di bug possono anche indicare quando qualcosa è più ampio dell'impianto, che potrebbe ridurne la capacità effettiva (ad esempio limitazione o frammentazione della memoria).

Usa Latenza tocco

Diversi esempi di prestazioni scadenti provengono dalla latenza touch, che è la carico di lavoro periodico preferito utilizzato per Pixel e Pixel XL. È disponibile su frameworks/base/tests/TouchLatency e dispone di due modalità: latenza al tocco e la palla che rimbalza (per cambiare modalità, fai clic sul pulsante in alto a destra nell'angolo in alto a destra).

Il test della palla che rimbalza è semplice come appare: una palla rimbalza sullo schermo per sempre, indipendentemente dall'input dell'utente. Di solito è anche di gran lunga il test più difficile da eseguire perfettamente, ma più senza registrare frame, migliore sarà il tuo dispositivo. La il test della palla che rimbalza è difficile perché è un test banale ma perfettamente coerente carico di lavoro che viene eseguito a un orologio molto basso (questo presuppone che il dispositivo abbia una frequenza governatore; se invece il dispositivo funziona con orologi fissi, esegui il down CPU/GPU quasi al minimo quando si esegue il test della palla rimbalzante per la prima volta). Quando il sistema si arresta e gli orologi si avvicinano allo stato di inattività, la quantità di CPU/GPU richiesta aumenta il tempo di utilizzo per frame. Puoi guardare la palla, vedere cosa si schiaccia e anche i frame persi in systrace.

Poiché il carico di lavoro è così coerente, è possibile identificare la maggior parte delle origini il tremolio è molto più semplice rispetto alla maggior parte dei carichi di lavoro visibili agli utenti, tenendo traccia di ciò sia esattamente in esecuzione sul sistema durante ogni frame perso, invece che sulla UI una pipeline o un blocco note personalizzato. Gli orologi inferiori amplificano gli effetti del jitter rendendolo è più probabile che un jitter causi la caduta del frame. Di conseguenza, la latenza touch più vicina è di 60 f/s, minore è la probabilità di un guasto del sistema che causano sporadici e difficili da riprodurre su app.

Poiché il jitter è spesso (ma non sempre) invariato la velocità di clock, utilizza un test che funziona a intervalli molto bassi per diagnosticare il tremolio per i seguenti motivi:

• Non tutti i jitter hanno una velocità di clock invariata; molte origini consumano solo CPU nel tempo.
• Il governatore deve ottenere la durata media dell'intervallo in prossimità della scadenza entro il il tempo necessario a eseguire il lavoro non UI può eseguirne il push rilasciando un frame.