In questa guida
Android vitals è la dashboard di Google con i dati tecnici di qualità della tua app, raccolti da dispositivi reali sul campo. Si trova nella Play Console. Per un piccolo team, l'approccio sensato è tenere d'occhio alcuni numeri, capire cosa significano e usarli per decidere cosa correggere per primo.
Le metriche principali
La documentazione per sviluppatori Android di Google elenca questi come i vitals più importanti:
- Stabilità: tasso di crash percepito dall'utente e tasso di ANR percepito dall'utente (Application Not Responding, app non risponde).
- Batteria: wake lock parziali eccessivi.
- Memoria: uso della memoria e uso della memoria dei bitmap.
Inizia dalla stabilità. Crash e ANR sono i numeri su cui la maggior parte degli sviluppatori può agire direttamente.
Soglie, e perché contano
La stessa documentazione indica le soglie di "bad behavior" (comportamento scorretto). Per massimizzare la visibilità su Google Play, mantieni questi valori sotto soglia:
| Metrica | Complessivo (media su tutti i dispositivi) | Per modello di telefono |
|---|---|---|
| Tasso di crash percepito dall'utente | 1,09% | 8% |
| Tasso di ANR percepito dall'utente | 0,47% | 8% |
Se superi una soglia, Google dice che Play può ridurre la visibilità della tua app e può mostrare un avviso sulla scheda dello store. Le soglie possono cambiare, quindi controlla la pagina attuale prima di citarle.
Vale la pena tenere separate due letture: il tasso complessivo ti dice se l'app è sana in media; il tasso per modello ti dice se una famiglia di dispositivi è molto rotta, anche quando la media sembra buona.
Dove guardare
I dati su crash e ANR compaiono nella dashboard Android vitals della Play Console. Gli stessi dati sono disponibili tramite la Google Play Developer Reporting API. Per indagare su un problema specifico di un dispositivo, Google indica le sezioni Reach and Devices (Raggiungibilità e dispositivi) nella Play Console.
Vitals più segnalazioni dei tester
I vitals ti dicono che qualcosa fallisce e con quale frequenza. Raramente ti dicono cosa stava facendo la persona. Una segnalazione del tester colma questa lacuna.
- Individua un picco nei vitals dopo una release.
- Chiedi ai tester del tipo di dispositivo colpito di ripetere i flussi principali e di annotare i passaggi esatti.
- Confronta i loro passaggi con lo stack trace nei cluster dei vitals.
- Correggi, poi osserva il numero alla release successiva.
I vitals riflettono le build rilasciate, quindi non possono sostituire i test prima di una release. Hanno anche poco da dire per un'app nuova con pochi utenti: campioni piccoli fanno saltare le percentuali. In quella fase, il feedback dei tester pesa di più.
Trasformare i numeri in priorità
- Correggi prima i cluster di crash che colpiscono più utenti. Vedi come dare priorità ai report di crash.
- Tratta gli ANR come un problema separato con cause proprie (thread principale bloccato, I/O lento). Vedi errori ANR su Android.
- Verifica un picco specifico di un modello su un dispositivo reale o simile prima di cambiare il codice.
- Annota il numero a ogni release, così vedi se una modifica ha aiutato.
Parte della guida al test di app Android. Correlati: test su dispositivi cloud e tester reali e la checklist di rilascio Android.
Vuoi che i tester riproducano un problema sui loro telefoni? Inizia gratis e raccogli feedback privato e strutturato.