Nuovi approfondimenti e consigli per i problemi relativi alla qualità delle app
Per il momento, sono mostrati problemi di compatibilità dell'app, prestazioni scadenti e alcuni consigli relativi all'esperienza utente. Continueremo a rilevare e segnalare altri problemi di qualità e a fornire ulteriori consigli nel corso del prossimo anno.
Usa Android vitals per comprendere e migliorare stabilità, prestazioni, utilizzo della batteria e altre funzionalità della tua app.
Scegliere come accedere ai dati dell'app
Esistono due modi per utilizzare Android vitals: tramite Play Console e l'API Play Developer Reporting.
L'API fornisce accesso programmatico ad Android vitals per gli sviluppatori che vogliono integrare i dati Android vitals con altri set di dati o incorporarli nei propri flussi di lavoro. Per saperne di più sull'utilizzo di un'API per accedere ad Android vitals, visita la pagina relativa all'API Google Play Developer Reporting.
Per trovare e controllare i dati Android vitals dell'app in Play Console:
- Apri Play Console e vai alla pagina Panoramica di Android vitals (Monitora e migliora > Android vitals > Panoramica).
- Scegli l'intervallo di dati da visualizzare utilizzando il selettore dell'intervallo di date in alto a destra.
Importante: se non ci sono dati disponibili significa che l'app non dispone di punti dati sufficienti all'interno dei filtri specificati per identificare eventuali problemi.
Nella parte superiore della pagina Panoramica di Android vitals puoi trovare dati relativi alle metriche vitals essenziali della tua app. Queste sono le metriche tecniche più importanti e influiscono sulla rilevabilità della tua app su Google Play. Le metriche vitals essenziali includono:
Google Play definisce le soglie relative alle prestazioni scadenti in relazione a queste metriche. Se la tua app supera queste soglie, è probabile che sia meno rilevabile su Google Play. In alcuni casi, nella scheda dello Store dell'app potrebbe essere visualizzato un avviso per definire le aspettative degli utenti.
Puoi utilizzare la sezione "Problemi critici" per identificare rapidamente le aree in cui la tua app può essere migliorata. Esistono due tipi di problemi critici:
- Prestazioni scadenti: metriche che superano le soglie relative alle prestazioni scadenti.
- Anomalie: cambiamenti significativi nei dati, ad esempio un notevole aumento della percentuale di ANR percepiti dagli utenti.
Per ricevere notifiche via email, vai a Configurazione > Notifiche o fai clic su Gestione delle notifiche nell'angolo della sezione "Metriche vitals essenziali" (Monitora e migliora > Android vitals > Panoramica). Tieni presente che al momento le notifiche sono disponibili solo per le anomalie.
Nella parte centrale della pagina Panoramica di Android vitals puoi visualizzare i dati relativi a tutte le metriche vitals, in base alla qualità.
Nella tabella puoi esaminare le metriche per i periodi di tempo corrente e precedente. Puoi anche confrontare la tua app con altre app su Google Play.
Per ulteriori dettagli su una metrica, seleziona Visualizza dettagli (
). Nella schermata successiva puoi controllare:
- Soglie relative alle prestazioni scadenti
- Benchmark di categoria
- Confronti di benchmark dettagliati
- Nella scheda di confronto tra app peer nella parte superiore della pagina, seleziona Modifica il gruppo di app peer per modificare un gruppo di app peer personalizzato. Dopo aver creato un gruppo di app peer personalizzato, puoi confrontare la tua app con altre app su Google Play scelte da te.
- Tendenza delle metriche nel tempo
Per semplificare l'organizzazione, la segmentazione e l'analisi dei dati, le metriche sono suddivise in base a diverse dimensioni. Tutte le metriche sono suddivise come segue:
- Elemento: la versione dell'app in cui si è verificato il problema.
- Versione di Android (SDK): la versione del sistema operativo Android segnalata dal dispositivo dell'utente.
- Fattore di forma: il tipo di dispositivo su cui è stata eseguita l'app (ad esempio, smartphone, tablet, TV, indossabile).
- Modello dispositivo: una descrizione generale del dispositivo, composta da un brand univoco e da un identificatore del dispositivo, ad esempio "Google oriole". Un singolo modello di dispositivo può avere varianti con versioni Android, RAM, spazio di archiviazione o SoC (System on chip) diversi.
- Paese/regione: la località segnalata dal dispositivo dell'utente nel momento in cui si è verificato il problema.
Suggerimento: per analisi dettagliate di aspetti specifici dell'hardware o del software del dispositivo (ad esempio, il modello del dispositivo o la versione di Android), puoi fare clic sul simbolo (
) accanto all'elemento nella tabella.
Alcune metriche presentano analisi aggiuntive:
- Nome wakelock: i tag che sono stati impostati in modo programmatico durante l'uso dell'API PowerManager nella tua app.
- Nome wakeup: i tag che sono stati impostati in modo programmatico durante l'uso dell'API AlarmManager nella tua app.
- Nome attività ANR: il nome completo della classe di attività in cui si è verificato l'errore ANR (se disponibile).
- Tipo di ANR: quando si è verificato l'errore ANR (ad esempio, durante l'esecuzione di un servizio), se disponibile.
Puoi visualizzare maggiori dettagli quando disponibili (ad esempio, i cluster di arresti anomali o ANR associati all'analisi) selezionando Visualizza dettagli () accanto all'elemento.
Suggerimento: puoi passare da una metrica all'altra in una singola categoria utilizzando il pulsante di attivazione/disattivazione nella parte superiore dello schermo e filtrare la pagina.
Metriche e tipi di dati
I dati Android vitals sono disponibili per i 90 giorni precedenti in Play Console e per tre anni nell'API Play Developer Reporting.
I dati vengono raccolti dagli utenti che hanno attivato la condivisione automatica dei dati di utilizzo e diagnostica da un sottoinsieme di dispositivi e versioni del sistema operativo Android. Visita il Centro assistenza Account Google per ulteriori informazioni sulla modalità di attivazione della condivisione di dati da parte degli utenti Android.
Android vitals viene aggiornato quotidianamente. A volte i dati relativi ai dispositivi con Android 10 o versioni successive possono arrivare prima dei dati relativi ai dispositivi con una versione precedente ad Android 10. In questo caso, verranno visualizzati i dati relativi ad Android 10 e versioni successive soltanto per i giorni in cui questi dati sono disponibili.
Nota: le metriche Android vitals escludono i problemi tecnici che si verificano su modelli di dispositivi non certificati o su versioni della tua app che non sono state installate tramite Google Play.
Comprimi tutto Espandi tutto
Stabilità
Le metriche relative alla percentuale di ANR forniscono una panoramica della qualità della tua app. Queste metriche vengono calcolate tenendo conto del numero di utenti con errori ANR e normalizzandoli in base all'utilizzo dell'app. Sono riportate come percentuale di utenti attivi giornalieri, dove un utente attivo giornaliero viene definito come un utente che utilizza l'app in un singolo giorno su un singolo dispositivo. Se un utente utilizza la tua app su più dispositivi in un solo giorno, ogni dispositivo contribuirà al numero di utenti attivi per quel giorno. Se più utenti utilizzano lo stesso dispositivo in un solo giorno, viene conteggiato un singolo utente attivo.
Esistono tre metriche relative alla percentuale di ANR:
- Percentuale di errore ANR percepito dall'utente: la percentuale di utenti attivi giornalieri che hanno riscontrato almeno un errore ANR percepito dall'utente. Un errore ANR percepito dall'utente è un errore ANR che probabilmente è stato notato dall'utente. Attualmente vengono conteggiati solo gli errori ANR di tipo "timeout invio input". Questa metrica sarà sempre inferiore alla percentuale di ANR generale perché è normalizzata per utilizzo giornaliero, ma non conta tutti gli errori ANR.
La percentuale di ANR percepiti dagli utenti è una metrica vitals essenziale, ovvero influisce sulla rilevabilità della tua app su Google Play. È importante perché gli errori ANR che conta si verificano sempre quando gli utenti interagiscono con l'app, causando così il maggior numero di interruzioni.
- Percentuale di ANR: la percentuale di utenti giornalieri che hanno riscontrato almeno un errore ANR. Questa metrica include gli errori ANR che non sono classificati come percepiti dall'utente, ma non possiamo garantire che non interessino gli utenti.
- Percentuale di ANR multipli: la percentuale di utenti giornalieri che hanno riscontrato almeno due errori ANR. Questa metrica consente di evidenziare loop di problemi.
Risolvere un problema
Gli errori ANR che contribuiscono alle metriche della percentuale di ANR vengono riportati nella pagina Arresti anomali e ANR. In questa pagina puoi filtrare gli errori ANR percepiti dagli utenti.
Il sito Android for Developers fornisce indicazioni su come diagnosticare e correggere gli ANR.
Le metriche relative alla percentuale di arresti anomali forniscono una panoramica della qualità della tua app. Queste metriche vengono calcolate tenendo conto del numero di utenti con arresti anomali e normalizzandoli in base all'utilizzo dell'app. Sono riportate come percentuale di utenti giornalieri, in cui un utente giornaliero viene definito come un utente che utilizza l'app in un singolo giorno su un singolo dispositivo. Se un utente ha più di un dispositivo, verrà conteggiato più di una volta. Ad esempio, se due utenti utilizzano l'app per due giorni su un dispositivo ciascuno, saranno generate quattro sessioni giornaliere.
Esistono tre metriche relative alla percentuale di arresti anomali:
- Percentuale di arresti anomali percepita dall'utente: la percentuale di utenti giornalieri che hanno riscontrato almeno un arresto anomalo percepito dall'utente. Un arresto anomalo percepito dall'utente è un arresto anomalo che probabilmente è stato notato dall'utente. Ad esempio, gli arresti anomali che si verificano quando la tua app mostra un'attività o è in esecuzione come servizio in primo piano. Questa metrica sarà sempre inferiore alla percentuale di arresti anomali generale perché è normalizzata per utilizzo giornaliero, ma non conta tutti gli arresti anomali.
La percentuale di arresti anomali percepita dagli utenti è una metrica vitals essenziale, ovvero influisce sulla rilevabilità della tua app su Google Play. È importante perché gli arresti anomali che conta si verificano sempre quando gli utenti interagiscono con l'app, causando così il maggior numero di interruzioni. Per questo motivo, devi assicurarti che la tua app non superi la
soglia relativa alle prestazioni scadenti per questa metrica.
-
Percentuale di arresti anomali: la percentuale di utenti giornalieri che hanno riscontrato almeno un arresto anomalo. Questa metrica comprende gli arresti anomali che non sono classificati come percepiti dall'utente, ma non possiamo garantire che non interessino gli utenti.
-
Percentuale di arresti anomali multipli: la percentuale di utenti giornalieri che hanno riscontrato almeno due arresti anomali. Questa metrica consente di evidenziare loop di problemi.
Risolvere un problema
Il sito Android for Developers fornisce indicazioni su come diagnosticare e correggere gli arresti anomali.
Tempi di avvio e caricamento
Nella pagina Tempi di avvio, puoi trovare informazioni dettagliate relative a quando la tua app si avvia lentamente dagli stati di sistema a freddo, tiepido e a caldo. Il tempo di avvio misura il tempo che intercorre tra l'avvio dell'app da parte dell'utente e il momento in cui appaiono sullo schermo i primi frame. È anche noto come "tempo di attesa per la prima schermata".
Dopo questo tempo, la tua app potrebbe non essere ancora pronta per l'interazione da parte dell'utente, ad esempio se sono previste schermate di caricamento aggiuntive.
Dettagli sulla raccolta dei dati
- I tempi di avvio vengono registrati soltanto quando un utente attiva un'attività.
- Esempio: per quanto riguarda le app per tastiera, il tempo di avvio corrisponde al tempo di avvio dell'app complementare.
- Se un'app viene avviata più volte nell'arco di una giornata dallo stesso stato di sistema, viene registrato il tempo di avvio massimo della giornata.
- I tempi di avvio vengono monitorati al completamento del caricamento del primo frame dell'app, anche se non si tratta di una schermata con cui interagiscono gli utenti.
- Esempio: se un'app si avvia con una schermata iniziale, il tempo di avvio corrisponde al tempo necessario per mostrare la schermata iniziale.
Dettagli relativi alle metriche vitals
- Sessioni interessate: la percentuale di sessioni durante le quali gli utenti hanno riscontrato un tempo di avvio lento per ogni relativo stato di sistema:
- Avvio a freddo lento: a partire da 5 secondi
- Avvio a caldo (warm): a partire da 2 secondi
- Avvio a caldo (hot): a partire da 1 secondo
- Numero di sessioni: numero approssimativo di sessioni registrate.
- 90º/99º percentile: il 10/1% di sessioni giornaliere durante le quali gli utenti hanno riscontrato tempi di avvio lenti dell'app.
Risolvere un problema
Se la tua app ha un numero elevato di tempi di avvio lenti, visita il sito Android for Developers per scoprire le soluzioni consigliate.
Rendering
Metriche su tutto il rendering
Perché è importante
Tramite i dati sulle sessioni lente puoi capire l'andamento della frequenza frame del tuo gioco, che incide sulla fluidità del gioco percepita dagli utenti.
Comprendere i dati dell'app
Nella pagina Sessioni lente troverai dettagli sulla percentuale di sessioni giornaliere in cui gli utenti hanno riscontrato più del 25% dei frame più lenti di 30 FPS o 20 FPS, a seconda del benchmark selezionato. Puoi anche vedere la distribuzione delle sessioni per frequenza frame del tuo gioco. (La frequenza frame a livello di sessione viene misurata al 75° percentile, il che significa che il 75% dei frame raggiunge almeno questa frequenza frame.)
La maggior parte dei giochi su Google Play dovrebbe avere un obiettivo minimo di 30 FPS. Ciò fornisce un'esperienza ragionevole agli utenti, indipendentemente dal tipo di gioco, anche se alcuni preferiscono almeno 60 FPS, in particolare sui dispositivi di fascia alta. Monitora la metrica della percentuale di sessioni lente (30 FPS) per raggiungere questo obiettivo. Tieni presente che questa metrica include solo sessioni in cui a oltre il 25% dei frame mancano 30 FPS, quindi ha una certa tolleranza per la variabilità della frequenza frame.
Sebbene la frequenza di 30 FPS offra un'esperienza ragionevole, in alcuni casi potrebbe essere necessario ridurre la frequenza frame al di sotto o potrebbero essere utili per giocare su telefoni che non supportano la frequenza di 30 FPS. In questi scenari, almeno il 75% dei frame in una sessione dovrebbe comunque raggiungere 20 FPS o più. Monitora la metrica della percentuale di sessioni lente (20 FPS) per assicurarti di raggiungere questo livello.
Android vitals registra le sessioni lente (30 FPS e 20 FPS) per ogni dispositivo così come per tutti i dispositivi e le sessioni. Utilizza la metrica complessiva per comprendere l'esperienza utente complessiva, ma fai attenzione anche alle prestazioni per dispositivo. A tempo debito, Google Play inizierà ad indirizzerà gli utenti lontano dai giochi che non possono raggiungere i 20 FPS sul telefono.
Vitals inizia a monitorare la frequenza frame solo dopo che il gioco è stato in esecuzione per 1 minuto.
Dettagli sulla raccolta dei dati
La metrica relativa alle sessioni lente viene calcolata con i dati raccolti da SurfaceFlinger. Più concretamente, la frequenza frame di una sessione viene stimata in base al tempo che intercorre fra i frame tracciati sulle piattaforme di proprietà dell'app e include i frame il cui rendering è stato eseguito con OpenGL, Vulkan e il toolkit per la UI di Android. Al momento questa metrica è disponibile soltanto per i giochi.
I dati sulla frequenza frame relativi alle sessioni lente vengono raccolti per i dispositivi con Android 9 e versioni successive.
Visualizzazione nella dashboard
- Frame rate aggregata: le prestazioni della frame rate del tuo gioco sui dispositivi con Android 9 o versioni successive, calcolate al 75° percentile. Ciò significa che il 75% delle sessioni ha registrato almeno questa frequenza frame il 75% delle volte.
- Percentuale di sessioni lente nel tempo: una serie temporale che mostra la percentuale di sessioni ritenute lente.
- Distribuzione della frequenza frame: istogramma che mostra la frequenza frame al 75° percentile di tutte le sessioni. Ciò significa che il 75% dei frame in una sessione è stato più veloce della frequenza frame utilizzata per il bucket della sessione.
Risolvere un problema
Se la tua app ha un numero elevato di sessioni lente, visita il sito Android for Developers per scoprire le soluzioni consigliate.
Rendering toolkit dell'interfaccia utente di Android
Comprendere i dati dell'app
Nella pagina Frame lenti eccessivi, troverai i dettagli sulla percentuale di sessioni giornaliere in cui gli utenti hanno riscontrato che oltre il 50% dei frame non ha raggiunto in tempo la scadenza di rendering del dispositivo. Le interazioni degli utenti con la tua app dovrebbero avvenire a 60 frame al secondo senza alcun frame interrotto o in ritardo.
Dettagli sulla raccolta dei dati
Google acquisisce il tempo di rendering di ciascun frame mostrato dall'app quando utilizzi il framework del toolkit dell'UI. I frame visualizzati utilizzando direttamente OpenGL o Vulkan non vengono acquisiti.
Visualizzazione nella dashboard
Quando selezioni una riga, puoi notare che i dati sono suddivisi in percentili.
- Sessioni interessate: la percentuale di sessioni giornaliere in cui gli utenti hanno riscontrato un tempo di rendering superiore a 16 ms per oltre il 50% dei frame. Con "sessione giornaliera" si intende una giornata in cui è stata usata l'app. Ad esempio, se due utenti utilizzano l'app per due giorni, saranno generate quattro sessioni giornaliere.
- Numero di sessioni: numero approssimativo di sessioni registrate.
- 90º/99º percentile: il tempo di rendering è stato inferiore al valore indicato per il 90%/99% del totale dei frame raccolti. Questi valori sono basati su tutti i frame raccolti.
Quando fai clic su una voce nella tabella, viene visualizzato il grafico "Distribuzione del tempo di rendering dell'interfaccia utente". Quando esamini il grafico, devi assicurarti che il tempo indicato per la maggior parte dei frame dell'app sia pari o inferiore a 16 ms.
I dati sotto il grafico danno un'idea delle prestazioni di rendering dell'app e potrebbero aiutarti a individuare la causa principale di eventuali problemi relativi al tempo di rendering. Ad esempio, se la percentuale "Latenza input elevata" è alta, dovresti esaminare il codice dell'app che gestisce l'input utente. Per ulteriori informazioni su queste metriche, vai al test delle prestazioni dell'UI.
- Eventi Vsync persi: per tutti i frame il cui rendering ha richiesto più di 16 ms, il numero di eventi Vsync persi, diviso per il numero di frame.
- Latenza input elevata: per tutti i frame il cui rendering ha richiesto più di 16 ms, il numero di eventi di input che hanno richiesto più di 24 ms, diviso per il numero di frame.
- Thread dell'interfaccia utente lento: per tutti i frame il cui rendering ha richiesto più di 16 ms, il numero di volte per cui sono stati necessari più di 8 ms per completare il thread dell'interfaccia utente, diviso per il numero di frame.
- Comandi di disegno lenti: per tutti i frame il cui rendering ha richiesto più di 16 ms, il numero di volte per cui l'invio alla GPU dei comandi di disegno ha richiesto più di 12 ms, diviso per il numero di frame.
- Caricamenti bitmap lenti: per tutti i frame il cui rendering ha superato i 16 ms, il numero di volte in cui sono stati necessari oltre 3,2 ms per caricare la bitmap nella GPU, diviso il numero di frame.
Risolvere un problema
Se la tua app ha un elevato numero di frame con un tempo di rendering superiore a 16 ms, visita il sito Android for Developers per scoprire le soluzioni consigliate.
Comprendere i dati dell'app
Nella pagina Frame lenti eccessivi, troverai i dettagli sulla percentuale di sessioni giornaliere in cui gli utenti hanno riscontrato che oltre il 50% dei frame non ha raggiunto in tempo la scadenza di rendering del dispositivo. Le interazioni degli utenti con la tua app dovrebbero avvenire a 60 frame al secondo senza alcun frame interrotto o in ritardo.
Dettagli sulla raccolta dei dati
Google acquisisce il tempo di rendering di ciascun frame mostrato dall'app quando utilizzi il framework del toolkit dell'UI. I frame visualizzati utilizzando direttamente OpenGL o Vulkan non vengono acquisiti.
Visualizzazione nella dashboard
Quando selezioni una riga, puoi notare che i dati sono suddivisi in percentili.
- Sessioni interessate: la percentuale di sessioni giornaliere in cui gli utenti hanno riscontrato un tempo di rendering superiore a 16 ms per oltre il 50% dei frame. Con "sessione giornaliera" si intende una giornata in cui è stata usata l'app. Ad esempio, se due utenti utilizzano l'app per due giorni, saranno generate quattro sessioni giornaliere.
- Numero di sessioni: numero approssimativo di sessioni registrate.
- 90º/99º percentile: il tempo di rendering è stato inferiore al valore indicato per il 90%/99% del totale dei frame raccolti. Questi valori sono basati su tutti i frame raccolti.
Quando fai clic su una voce nella tabella, viene visualizzato il grafico "Distribuzione del tempo di rendering dell'interfaccia utente". Quando esamini il grafico, devi assicurarti che il tempo indicato per la maggior parte dei frame dell'app sia pari o inferiore a 16 ms.
I dati sotto il grafico danno un'idea delle prestazioni di rendering dell'app e potrebbero aiutarti a individuare la causa principale di eventuali problemi relativi al tempo di rendering. Ad esempio, se la percentuale "Latenza input elevata" è alta, dovresti esaminare il codice dell'app che gestisce l'input utente. Per ulteriori informazioni su queste metriche, vai al test delle prestazioni dell'UI.
- Eventi Vsync persi: per tutti i frame il cui rendering ha richiesto più di 16 ms, il numero di eventi Vsync persi, diviso per il numero di frame.
- Latenza input elevata: per tutti i frame il cui rendering ha richiesto più di 16 ms, il numero di eventi di input che hanno richiesto più di 24 ms, diviso per il numero di frame.
- Thread dell'interfaccia utente lento: per tutti i frame il cui rendering ha richiesto più di 16 ms, il numero di volte per cui sono stati necessari più di 8 ms per completare il thread dell'interfaccia utente, diviso per il numero di frame.
- Comandi di disegno lenti: per tutti i frame il cui rendering ha richiesto più di 16 ms, il numero di volte per cui l'invio alla GPU dei comandi di disegno ha richiesto più di 12 ms, diviso per il numero di frame.
- Caricamenti bitmap lenti: per tutti i frame il cui rendering ha superato i 16 ms, il numero di volte in cui sono stati necessari oltre 3,2 ms per caricare la bitmap nella GPU, diviso il numero di frame.
Risolvere un problema
Se la tua app ha un elevato numero di frame con un tempo di rendering superiore a 16 ms, visita il sito Android for Developers per scoprire le soluzioni consigliate.
Utilizzo batteria
Nelle pagine Wakelock parziali bloccati e Wakelock parziali bloccati (in background) vengono indicati i wakelock parziali acquisiti dall'app tramite la classe PowerManager. Un wakelock parziale assicura che la CPU sia in esecuzione, ma consente la disattivazione della retroilluminazione dello schermo e della tastiera.
Dettagli sulla raccolta dei dati
- Per motivi di privacy, i tag identificativi dei wakelock parziali sono anonimizzati.
- I dati sui wakelock parziali vengono acquisiti quando il dispositivo non è in carica e lo schermo è spento.
- I dati sui wakelock parziali bloccati (in background) vengono acquisiti solo quando l'app è in esecuzione in background.
- Google calcola la durata massima del wakelock parziale per sessione di batteria in modo da mostrare quante sessioni sono state interessate da un wakelock prolungato. Ad esempio, se un utente attiva un wakelock di due ore, Google utilizzerà un valore massimo di wakelock di un'ora.
- Per le app con il valore
sharedUserId impostato nel file manifest, vedrai i dati solo se è installata al massimo un'app con lo stesso sharedUserId.
Dettagli relativi alle metriche vitals
- Sessioni interessate: percentuale di sessioni di batteria in cui gli utenti hanno riscontrato almeno un wakelock di oltre un'ora.
- Numero di sessioni: numero approssimativo di sessioni registrate.
- 90º/99º percentile: 10%/1% di sessioni giornaliere in cui gli utenti hanno riscontrato durate di wakelock parziali superiori al valore indicato.
- Soglia relativa alle prestazioni scadenti: se la tua app presenta un tasso di occorrenza uguale o superiore a quello della soglia mostrata, significa che fa parte del 25% delle app con prestazioni peggiori tra le 1000 app migliori su Google Play (per numero di installazioni).
Risolvere un problema
Se la tua app ha un numero elevato di wakelock parziali bloccati, visita il sito Android for Developers per scoprire le soluzioni consigliate.
Nella pagina Wakeup eccessivi vengono mostrati i wakeup di Alarm Manager attivati dall'app. Troverai i dati dei wakeup per le classi ELAPSED_REALTIME_WAKEUP o RTC_WAKEUP.
Dettagli sulla raccolta dei dati
- Per motivi di privacy, i tag di identificazione dei wakeup vengono anonimizzati.
- I wakeup vengono acquisiti quando il dispositivo non è in carica.
- Per fornire una metrica normalizzata, il numero di wakeup è confrontato con il tempo per cui il dispositivo usa la batteria. Google calcola il numero di wakeup per utente per ora in modo da mostrare il numero di utenti interessati da una percentuale elevata di wakeup.
- Per le app con il valore
sharedUserId impostato nel file manifest, vedrai i dati solo se è installata al massimo un'app con lo stesso sharedUserId.
Dettagli relativi alle metriche vitals
- Sessioni interessate: la percentuale di sessioni di batteria in cui gli utenti hanno riscontrato più di 10 wakeup all'ora. Una sessione di batteria è l'aggregazione di tutti i rapporti sulla batteria ricevuti entro un determinato periodo di 24 ore. In Android 10, un report sulla batteria fa riferimento all'intervallo tra due ricariche da meno del 20% al di sopra dell'80% o di qualsiasi valore inferiore al 100%. In Android 11 e versioni successive, un report sulla batteria fa riferimento a un periodo fisso di 24 ore. Google raccoglie i dati solo quando il dispositivo è scollegato dal caricabatterie.
- Numero di sessioni: numero approssimativo di sessioni registrate.
- 90º/99º percentile: 10%/1% di sessioni giornaliere in cui gli utenti hanno riscontrato in un'ora wakeup superiori al valore indicato.
- Soglia relativa alle prestazioni scadenti: se la tua app presenta un tasso di occorrenza uguale o superiore a quello della soglia mostrata, significa che fa parte del 25% delle app con prestazioni peggiori tra le 1000 app migliori su Google Play (per numero di installazioni).
Risolvere un problema
Se la tua app presenta wakeup frequenti, visita il sito Android for Developers per scoprire le soluzioni consigliate.
La pagina di ricerche di reti Wi-Fi eccessive (in background) mostra quando le ricerche di reti Wi-Fi generano un elevato utilizzo della batteria.
Dettagli sulla raccolta dei dati
I dati sulla ricerca di reti Wi-Fi vengono raccolti quando il dispositivo non è in carica e l'app è in background.
Dettagli relativi alle metriche vitals
- Sessioni interessate: la percentuale di sessioni di batteria in cui gli utenti hanno riscontrato più di 4 ricerche di reti Wi-Fi all'ora.
- Numero di sessioni: numero approssimativo di sessioni registrate.
- 90º/99º percentile: 10%/1% di sessioni giornaliere in cui gli utenti hanno riscontrato un numero di ricerche orarie di reti Wi-Fi in background superiore al valore indicato.
Risolvere un problema
Se la tua app ha un elevato numero di ricerche di reti Wi-Fi in background, visita il sito degli Sviluppatori Android per scoprire le soluzioni consigliate.
Nella pagina Utilizzo eccessivo della rete viene indicato quando una grande quantità di dati di rete è associata a un servizio in background. Quando l'utilizzo della rete mobile avviene in background, i tuoi utenti non hanno un accesso rapido ai controlli per fermare il trasferimento dei dati.
Dettagli sulla raccolta dei dati
I dati sull'utilizzo della rete mobile vengono acquisiti quando il dispositivo non è in carica e l'app è in background.
Dettagli relativi alle metriche vitals
- Sessioni interessate: la percentuale di sessioni di batteria in cui gli utenti hanno riscontrato più di 50 MB di utilizzo giornaliero della rete in background.
- Numero di sessioni: numero approssimativo di sessioni registrate.
- 90º/99º percentile: 10%/1% di sessioni giornaliere in cui gli utenti hanno riscontrato un maggiore utilizzo giornaliero della rete in background rispetto al valore indicato.
Risolvere un problema
Se la tua app ha un elevato utilizzo della rete in background, visita il sito Android for Developers per scoprire le soluzioni consigliate.
Autorizzazioni
Nella pagina Rifiuti di autorizzazioni puoi trovare informazioni dettagliate sulla percentuale di sessioni di autorizzazione giornaliere durante le quali gli utenti hanno negato le autorizzazioni. Con "sessione di autorizzazione giornaliera" si intende una giornata in cui la tua app ha richiesto almeno un'autorizzazione all'utente.
Dettagli sulla raccolta dei dati
I dati relativi ai rifiuti di autorizzazioni vengono raccolti quando gli utenti rispondono alle richieste di autorizzazioni all'interno della tua app.
Dettagli relativi alle metriche vitals
- Autorizzazioni rifiutate: percentuale di sessioni di autorizzazione giornaliere durante le quali gli utenti non hanno concesso le autorizzazioni.
- Non chiedere più: la percentuale di sessioni di autorizzazione giornaliere durante le quali gli utenti hanno negato le autorizzazioni selezionando l'opzione Non chiedere più.
- Sessioni totali: il numero approssimativo di sessioni registrate.
Risolvere un problema
Se la tua app ha un numero elevato di rifiuti di autorizzazioni, visita il sito Android for Developers per scoprire le soluzioni consigliate.
Google Play ha definito soglie relative alle prestazioni scadenti per le metriche vitals essenziali della tua app.
Se la tua app supera una di queste soglie, è probabile che sia meno rilevabile su Google Play. Se ha prestazioni scadenti su determinati modelli di dispositivi, Google Play indirizzerà gli utenti con quei dispositivi lontano dalla tua app e verso altre più adatte. In alcuni casi, nella scheda dello Store dell'app potrebbe essere visualizzato un avviso per definire le aspettative degli utenti e offrire la possibilità di cercare alternative con una qualità tecnica superiore.
Generalmente Google Play prende in considerazione i dati degli ultimi 28 giorni per valutare la qualità della tua app, ma potrebbe intervenire prima del previsto in caso di picco.
Comprimi tutto Espandi tutto
Stabilità
Google Play ha definito soglie relative alle prestazioni scadenti in base alla percentuale di errore ANR percepito dall'utente:
-
Prestazioni scadenti generali: almeno lo 0,47% degli utenti attivi giornalieri ha riscontrato un errore ANR percepito dall'utente su tutti i modelli di dispositivi.
-
Prestazioni scadenti del dispositivo: almeno l'8% degli utenti attivi giornalieri ha riscontrato un errore ANR percepito dall'utente su un singolo modello di dispositivo.
Per migliorare la percentuale di ANR, correggi i cluster di ANR sottostanti segnalati nella pagina Arresti anomali e ANR. Maggiore è il numero di utenti interessati, più il cluster contribuirà alla percentuale di ANR.
Se aspetti specifici dell'hardware o del software del dispositivo potrebbero contribuire alla percentuale di ANR, Android vitals ti invierà una notifica. Puoi anche esplorare le associazioni autonomamente nella pagina Panoramica relativa a Copertura e dispositivi (Monitora e migliora > Copertura e dispositivi > Panoramica).
Google Play ha definito soglie relative alle prestazioni scadenti in base alla percentuale di arresti anomali percepita dall'utente:
-
Prestazioni scadenti generali: almeno l'1,09% degli utenti giornalieri ha riscontrato un arresto anomalo percepito dall'utente su tutti i modelli di dispositivo.
-
Prestazioni scadenti del dispositivo: almeno l'8% degli utenti giornalieri ha riscontrato un arresto anomalo percepito dall'utente su un singolo modello di dispositivo.
Per migliorare la percentuale di arresti anomali, correggi i cluster di arresti anomali sottostanti segnalati nella pagina Arresti anomali e ANR. Maggiore è il numero di utenti interessati, più il cluster contribuirà alla percentuale di arresti anomali.
Se aspetti specifici dell'hardware o del software del dispositivo potrebbero contribuire alla percentuale di arresti anomali, Android vitals ti invierà una notifica. Puoi anche esplorare le associazioni autonomamente nella pagina Panoramica relativa a Copertura e dispositivi (Monitora e migliora > Copertura e dispositivi > Panoramica).
Contenuti correlati
Scopri le best practice per l'utilizzo di Android vitals per migliorare le prestazioni e la stabilità della tua app.