Condivisione della tecnologia

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Panoramica degli strumenti relativi alla raccolta e all'analisi delle prestazioni

Esistono molti strumenti per raccogliere, analizzare e visualizzare i dati sulle prestazioni delle applicazioni mobili, che possono essere suddivisi approssimativamente nelle seguenti categorie. Ad esempio, strumenti di prestazione mobile in grado di raccogliere più indicatori di prestazione, perfdog e Solopi, tra cui Solopi è open source e pefdog è uno strumento commerciale. Strumenti in grado di eseguire analisi degli arresti anomali, come il commerciale Firebase Crashlytics e lo strumento open source Sentry. Se devi analizzare i dati relativi alla rete, puoi utilizzare Charles o Wireshark. Inoltre, sono disponibili strumenti completi di gestione delle prestazioni, come Dynatrace. In generale, le capacità, la precisione e l'esperienza utente degli strumenti commerciali sono decisamente migliori degli strumenti open source. Come studio e ricerca personale, posso solo iniziare da strumenti open source. Pertanto, quando scriveremo questo blog, utilizzeremo anche strumenti open source come esempi.

Strumento di test delle prestazioni mobile：
PerfDog: uno strumento per monitorare le prestazioni delle applicazioni, la CPU, la memoria, il consumo energetico e altri dati, supportando test delle prestazioni e monitoraggio in tempo reale delle applicazioni mobili.
Solopi: si concentra sul test e sul monitoraggio delle prestazioni delle applicazioni mobili, compreso il monitoraggio in tempo reale di frame rate, CPU, memoria e altri indicatori.

Strumento di analisi degli incidenti：
Firebase Crashlytics: un potente strumento di segnalazione e analisi degli arresti anomali fornito da Google in grado di monitorare gli arresti anomali dell'applicazione in tempo reale.
Sentry: uno strumento di tracciamento degli errori open source che supporta più piattaforme, tra cui la segnalazione degli errori e il monitoraggio delle prestazioni delle applicazioni mobili.

Strumenti per testare le prestazioni della rete：
Charles Proxy: uno strumento proxy di debug della rete che acquisisce e analizza i dati di richiesta e risposta di rete per le applicazioni mobili.
Wireshark: uno strumento di analisi di rete open source che supporta l'acquisizione e l'analisi dei pacchetti di rete delle applicazioni mobili.

Strumenti dell'APM(Gestione delle prestazioni delle applicazioni):
Dynatrace: una soluzione di monitoraggio delle prestazioni full-stack nativa del cloud che supporta il monitoraggio delle prestazioni delle applicazioni mobili e l'analisi dell'esperienza utente.

Quali parametri di prestazione vengono raccolti e come

  Prima di eseguire l'analisi delle prestazioni, è necessario comprendere il significato di ciascun indicatore di prestazione. Prendendo come esempio gli indicatori di prestazione raccolti da Solopi, diamo un'occhiata agli indicatori comuni delle prestazioni delle applicazioni mobili e al modo in cui questi indicatori possono essere raccolti.

Frequenza dei fotogrammi

La formula per calcolare il frame rate è:Frame rate = numero di fotogrammi disegnati/periodo di tempo,Il frame rate target per la maggior parte degli sviluppatori di applicazioni e giochi è60 FPS( fotogrammi/secondo), perché il frame rate target è 60FPS? Poiché la frequenza di aggiornamento dello schermo della maggior parte dei moderni smartphone e tablet è di 60 Hz, finché la frequenza dei fotogrammi raggiunge i 60 FPS, ovvero il numero di fotogrammi disegnati al secondo è 60, gli effetti visivi dell'utente saranno più fluidi e non ci sarà alcun ritardo. Il minimo non può essere inferiore a 30 FPS. Questo perché il monitor visualizza ripetutamente l'immagine del fotogramma precedente in attesa di un nuovo fotogramma, rendendo l'immagine non uniforme. Quelli alti possono raggiungere i 90FPS (ad esempio, per dispositivi con frequenze di aggiornamento elevate).

Come raccogliere informazioni sulla frequenza dei fotogrammi

  Esistono due modi per raccogliere la frequenza dei fotogrammi. Il primo consiste nell'utilizzare la classe Choreographer per raccogliere le statistiche sulla frequenza dei fotogrammi. Ciò richiede la scrittura del codice all'interno dell'applicazione e può raccogliere solo le informazioni sulla frequenza dei fotogrammi dell'applicazione.Un altro modo è usare strumento gfxinfo. Prendendo Solopi come esempio, il tempo del frame di timeout entro 1 secondo viene calcolato anche attraverso le informazioni dello strumento gfxinfo e viene dedotto il frame rate effettivo. Pertanto, quando è quasi stazionario, parte del frame rate potrebbe essere visualizzato in modo errato. Si consiglia di condurre test sulla frequenza dei fotogrammi in scenari dinamici come lo scorrimento o il cambio di pagina. Il metodo gfxinfo può raccogliere informazioni sulla frequenza dei fotogrammi di tutte le applicazioni ed è molto adatto come strumento di raccolta dei dati sulle prestazioni. Pertanto, qui ci concentreremo anche su come raccogliere informazioni sulla frequenza dei fotogrammi tramite gfxinfo.

Esistono due passaggi principali per raccogliere informazioni sulla frequenza dei fotogrammi.primo passo: Ottieni informazioni gfxinfo tramite il comando adb,Passo 2 : analizza le informazioni e calcola le informazioni sulla frequenza dei fotogrammi. Il contenuto delle informazioni gfxinfo è più o meno il seguente:

Statistiche dal: ora di inizio delle statistiche, l'unità è nanosecondi.
Fotogrammi totali renderizzati: numero totale di fotogrammi renderizzati.
Fotogrammi Janky: il numero di fotogrammi janky, ovvero il numero di fotogrammi che superano i 16 ms (intervallo di aggiornamento di 60 fotogrammi al secondo).
Percentuale di fotogrammi stravaganti: il rapporto tra fotogrammi stravaganti e il numero totale di fotogrammi.
90° percentile: 90° percentile, che indica che il 90% dei fotogrammi ha tempi di rendering inferiori a questo valore (in millisecondi).
95° percentile: 95° percentile, che indica che il 95% dei fotogrammi ha tempi di rendering inferiori a questo valore (in millisecondi).
99° percentile: 99° percentile, che indica che il 99% dei fotogrammi ha tempi di rendering inferiori a questo valore (in millisecondi).
Numero mancate Vsync: il numero di sincronizzazioni verticali non sincronizzate, ovvero il numero di cadute di fotogrammi causate dal mancato rendering in tempo.
Numero latenza di input elevata: il numero di ritardi di input elevati indica il numero di ritardi causati da un tempo di elaborazione dell'evento di input troppo lungo.
Numero di thread dell'interfaccia utente lenti: il numero di volte in cui il thread dell'interfaccia utente ha risposto lentamente, ovvero il numero di volte in cui il thread dell'interfaccia utente ha impiegato troppo tempo per l'elaborazione.

Prendendo Solopi come esempio, il frame rate viene dedotto attraverso il frame time di timeout nelle informazioni gfxinfo. Per il codice del progetto specifico, è possibile visualizzare il codice sorgente di solopi.

tasso di ritardo/numero di ritardi

Numero di blocchi : Durante il periodo di test, il numero di periodi durante i quali viene rilevato che il frame rate è inferiore alla soglia. Ogni volta che il frame rate scende al di sotto della soglia per un periodo di tempo, viene conteggiato come stutter. La soglia qui può essere personalizzata. Ad esempio, se è inferiore di 60 FPS rispetto al frame rate target, può essere registrata come blocco. Cioè, se il tempo di rendering del fotogramma è maggiore di 16 ms, viene calcolato come bloccato.

tasso di ritardo : La percentuale del tempo di congelamento rispetto al tempo totale del test. Supponiamo che in un test l'applicazione sia stata eseguita per 120 secondi, durante i quali il frame rate è stato inferiore a 16 FPS per 4 volte in totale e il tempo di ritardo totale è stato di 8 secondi, quindi: il numero di ritardi: 4 volte. Tasso di balbuzie: 8/120*100%=6,7%. Nel gfxinfo sopra sono presenti anche informazioni sui dati relativi al tasso di ritardo.

CPU/memoria

  Prendendo solopi come esempio, cpu include la percentuale di utilizzo della CPU del processo in cui si trova l'attività di livello superiore dell'applicazione e la percentuale di utilizzo globale della CPU Per le applicazioni a processo singolo, questi dati rappresentano l'utilizzo della CPU dell'applicazione applicazioni di processo multiprocesso, questi dati rappresentano l'utilizzo della CPU del livello superiore del processo UI, quando si verifica un cambio di processo, Soloπ può passare automaticamente ai nuovi dati di processo.

import subprocess
 
def get_memory_info(pid):
    try:
        # Run adb shell command to read /proc/<pid>/statm
        command = f"adb shell cat /proc/{pid}/statm"
        result = subprocess.check_output(command, shell=True)
        statm_data = result.decode('utf-8').strip().split()
        
        # Parse statm data
        size, resident, shared, text, lib, data, dt = map(int, statm_data)
        
        memory_info = {
            'size': size,         # total program size (pages)
            'resident': resident, # resident set size (pages)
            'shared': shared,     # shared pages (pages)
            'text': text,         # text (code) size (pages)
            'lib': lib,           # library (unused since Linux 2.6; always 0)
            'data': data,         # data + stack (pages)
            'dt': dt              # dirty pages (unused since Linux 2.6; always 0)
        }
        
        return memory_info
    except subprocess.CalledProcessError as e:
        print(f"Error executing command: {e}")
        return None
    except Exception as e:
        print(f"Error: {e}")
        return None
 
# Replace with your application's PID
pid = '12345'
memory_info = get_memory_info(pid)
if memory_info:
    print(f"Memory info for PID {pid}:")
    print(f"Size: {memory_info['size']} pages")
    print(f"Resident set size (RSS): {memory_info['resident']} pages")
    print(f"Shared pages: {memory_info['shared']} pages")
    print(f"Text (code) size: {memory_info['text']} pages")
    print(f"Data + stack size: {memory_info['data']} pages")

Tempo di risposta

  Prendi solopi come esempio, Contiene i dati sui tempi di risposta e di aggiornamento per i clic sull'applicazione. Appartiene ai dati della dimensione dell'applicazione. Il tempo che intercorre tra il clic dell'utente e il primo aggiornamento dell'interfaccia da parte del sistema è il tempo di risposta, mentre il tempo trascorso fino all'interruzione dell'aggiornamento dell'interfaccia da parte del sistema è il tempo di aggiornamento. La logica del conteggio del tempo di risposta è quella di dividere la registrazione dello schermo in fotogrammi. Secondo il sito web ufficiale di Solopi, riconosce automaticamente il fotogramma iniziale e quello finale per contare il tempo di risposta. Quando usi effettivamente Solopi, troverai la pagina statistica il tempo di risposta non è corretto. Ad esempio, quando l'utente fa clic su Start, quando si fa clic sulla pagina dell'applicazione, viene incluso il tempo di funzionamento della velocità della mano di qualcuno al centro e questa parte viene conteggiata nel tempo di risposta. Pertanto, se si desidera calcolare il tempo di risposta della pagina preparata, è più accurato registrare solo lo schermo e identificare manualmente i frame iniziali e finali della pagina. I passaggi specifici per la registrazione dei fotogrammi dello schermo sono i seguenti:

Quanto sopra è una comprensione del significato degli indicatori di prestazione comuni nelle applicazioni mobili, nonché istruzioni dettagliate su come raccoglierli. Per quanto riguarda crash, ecc., lo presenteremo in dettaglio in un blog successivo.