Risoluzione dei problemi e domande frequenti su Crashlytics
Questa pagina fornisce assistenza per la risoluzione dei problemi e risposte alle domande frequenti sull'utilizzo di Crashlytics. Se non riesci a trovare ciò che stai cercando o hai bisogno di ulteriore assistenza, contatta l'assistenza Firebase.
Domande frequenti/risoluzione dei problemi generali
Visualizzazione di formati diversi
(e a volte "varianti") per alcuni problemi nella tabella Problemi
Potresti notare due formati diversi per i problemi elencati nella tabella Problemi nella console Firebase. Potresti anche notare una funzionalità chiamata "varianti" in alcuni dei tuoi problemi. Ecco perché.
All'inizio del 2023 abbiamo implementato un motore di analisi migliorato per il raggruppamento degli eventi, nonché un design aggiornato e alcune funzionalità avanzate per i nuovi problemi (come le varianti). Dai un'occhiata al nostro recente
post del blog
per tutti i dettagli, ma continua a leggere per scoprire le novità principali.
Crashlytics analizza tutti gli eventi della tua app (ad esempio arresti anomali, errori non fatali e ANR) e crea gruppi di eventi chiamati problemi: tutti gli eventi in un problema hanno un punto di errore comune.
Per raggruppare gli eventi in questi problemi, il motore di analisi migliorato ora esamina molti aspetti dell'evento, tra cui i frame nella traccia dello stack, il messaggio di eccezione, il codice di errore e altre caratteristiche della piattaforma o del tipo di errore.
Tuttavia, all'interno di questo gruppo di eventi, le analisi dello stack che portano all'errore potrebbero essere diverse. Un'analisi dello stack diversa potrebbe indicare una causa principale diversa.
Per rappresentare questa possibile differenza all'interno di un problema, ora creiamo
varianti all'interno dei problemi: ogni variante è un sottogruppo di eventi in un problema
che hanno lo stesso punto di errore e un'analisi dello stack simile. Con le varianti,
puoi eseguire il debug delle analisi dello stack più comuni all'interno di un problema e determinare se diverse cause principali portano all'errore.
Ecco cosa noterai con questi miglioramenti:
Metadati rinnovati visualizzati nella riga del problema Ora è più facile comprendere e gestire i problemi nella tua app.
Meno problemi duplicati La modifica del numero di riga non genera un nuovo problema.
Debug più semplice dei problemi complessi con varie cause principali Utilizza le varianti per eseguire il debug delle analisi dello stack più comuni all'interno di un problema.
Avvisi e indicatori più significativi Un nuovo problema rappresenta effettivamente un nuovo bug.
Ricerca più efficace Ogni problema contiene più metadati disponibili per la ricerca, come il tipo di eccezione e il nome del pacchetto.
Ecco come verranno implementati questi miglioramenti:
Quando riceviamo nuovi eventi dalla tua app, verifichiamo se corrispondono a un problema esistente.
Se non viene trovata alcuna corrispondenza, applicheremo automaticamente all'evento il nostro algoritmo di raggruppamento degli eventi più intelligente e creeremo un nuovo problema con il design dei metadati rinnovato.
Questo è il primo grande aggiornamento che stiamo apportando al raggruppamento degli eventi. Se hai un feedback o riscontri problemi, comunicacelo inviando un report.
Non vengono visualizzate
le metriche senza arresti anomali e/o gli avvisi sulla velocità
Se non visualizzi le metriche relative alle app senza arresti anomali (ad esempio utenti e sessioni senza arresti anomali)
e/o gli avvisi sulla velocità, assicurati di utilizzare
l'SDK Crashlytics 11.7.0 o versioni successive.
Non vengono visualizzati i log dei breadcrumb
Se non visualizzi i log dei breadcrumb, ti consigliamo di controllare la configurazione dell'app per Google Analytics.
Assicurati di soddisfare i seguenti requisiti:
Visualizzazione di analisi dello stack non simboliche per le app per Android nella dashboard di Crashlytics
Se utilizzi Unity IL2CPP
e visualizzi tracce dello stack non simboliche, prova a svolgere i seguenti passaggi:
Assicurati di utilizzare la versione 8.6.1 o successive dell'SDK Crashlytics Unity.
Assicurati di aver configurato e di eseguire il comando Firebase CLI
crashlytics:symbols:upload per generare e caricare il file del simbolo.
Devi eseguire questo comando CLI ogni volta che crei una build di release o qualsiasi build per la quale vuoi visualizzare le tracce dello stack simboliche nella console Firebase. Scopri di più nella pagina
Generare report sugli arresti anomali leggibili.
Crashlytics può essere utilizzato con le app che utilizzano IL2CPP?
Sì, Crashlytics può visualizzare le tracce dello stack simboliche per le tue app che utilizzano IL2CPP. Questa funzionalità è disponibile per le app rilasciate sulle piattaforme Android o Apple. Ecco cosa devi fare:
Assicurati di utilizzare la versione 8.6.0 o successive dell'SDK CrashlyticsUnity.
Completa le attività necessarie per la tua piattaforma:
Per le app per la piattaforma Apple: non sono necessarie azioni speciali. Per le app per la piattaforma Apple, il plug-in Firebase Unity Editor configura automaticamente il progetto Xcode per il caricamento dei simboli.
Per le app per Android: assicurati di aver configurato ed eseguito il comando Firebasecrashlytics:symbols:upload dell'interfaccia a riga di comando per generare e caricare il file dei simboli.
Devi eseguire questo comando CLI ogni volta che crei una build di release o qualsiasi build per la quale vuoi visualizzare le tracce dello stack simboliche nella console Firebase. Scopri di più nella pagina
Generare report sugli arresti anomali leggibili.
Come vengono calcolati gli utenti senza arresti anomali?
Il valore senza arresti anomali rappresenta la percentuale di utenti che hanno interagito con la tua app, ma non hanno riscontrato arresti anomali in un determinato periodo di tempo.
Ecco la formula per calcolare la percentuale di utenti senza arresti anomali. I relativi valori di input sono forniti da Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100
Quando si verifica un arresto anomalo, Google Analytics invia un tipo di evento app_exception e CRASHED_USERS rappresenta il numero di utenti associati a quel tipo di evento.
ALL_USERS indica il numero totale di utenti che hanno interagito con la tua app nell'intervallo di tempo selezionato dal menu a discesa in alto a destra nella dashboard di Crashlytics.
La percentuale di utenti non interessati da arresti anomali è un'aggregazione nel tempo, non una media.
Ad esempio, immagina che la tua app abbia tre utenti: li chiameremo Utente A, Utente B e Utente C. La seguente tabella mostra gli utenti che hanno interagito con la tua app ogni giorno
e tra questi quali hanno riscontrato un arresto anomalo quel giorno:
Lunedì
Martedì
Mercoledì
Utenti che hanno interagito con la tua app
A, B, C
A, B, C
A, B
Utente che ha riscontrato un arresto anomalo
C
B
A
Mercoledì la percentuale di utenti che non hanno riscontrato arresti anomali è del 50% (1 utente su 2 non ha riscontrato arresti anomali). Due dei tuoi utenti hanno interagito con la tua app mercoledì, ma solo per uno di loro (utente B) non si sono verificati arresti anomali.
Negli ultimi 2 giorni, la percentuale di utenti senza arresti anomali è pari al 33,3% (1 utente su 3
non ha riscontrato arresti anomali). Tre dei tuoi utenti hanno interagito con la tua app negli ultimi due giorni, ma solo uno di loro (utente C) non ha riscontrato arresti anomali.
Negli ultimi 3 giorni, la percentuale di utenti che non hanno riscontrato arresti anomali è pari allo 0% (nessuno degli 3
utenti non ha riscontrato arresti anomali). Tre dei tuoi utenti hanno interagito con la tua app negli ultimi tre giorni, ma nessuno di loro non ha riscontrato arresti anomali.
Il valore degli utenti senza arresti anomali non deve essere confrontato in periodi di tempo diversi.
La probabilità che un singolo utente riscontri un arresto anomalo aumenta con il numero di volte che utilizza la tua app, pertanto il valore degli utenti che non hanno riscontrato arresti anomali è probabile che sia inferiore per periodi di tempo più lunghi.
Chi può visualizzare, scrivere ed eliminare le note relative a un problema?
Le note consentono ai membri del progetto di commentare problemi specifici con domande, aggiornamenti sullo stato e così via.
Quando un membro del progetto pubblica una nota, questa viene etichettata con l'indirizzo email del suo Account Google. Questo indirizzo email è visibile, insieme alla nota, a tutti i membri del progetto con accesso in visualizzazione alla nota.
Di seguito è descritto l'accesso necessario per visualizzare, scrivere ed eliminare le note:
I membri del progetto con uno dei seguenti ruoli possono visualizzare ed eliminare le note esistenti e scrivere nuove note su un problema.
Chi può visualizzare, scrivere ed eliminare le note relative a un problema?
Le note consentono ai membri del progetto di commentare problemi specifici con domande, aggiornamenti sullo stato e così via.
Quando un membro del progetto pubblica una nota, questa viene etichettata con l'indirizzo email del suo Account Google. Questo indirizzo email è visibile, insieme alla nota, a tutti i membri del progetto con accesso in visualizzazione alla nota.
Di seguito è descritto l'accesso necessario per visualizzare, scrivere ed eliminare le note:
I membri del progetto con uno dei seguenti ruoli possono visualizzare ed eliminare le note esistenti e scrivere nuove note su un problema.
L'app utilizza anche l'SDK Google Mobile Ads, ma non si verificano arresti anomali
Se il tuo progetto utilizza Crashlytics insieme all'SDK Google Mobile Ads,
è probabile che i segnalatori di arresti anomali interferiscano con la registrazione degli gestori delle eccezioni. Per risolvere il problema, disattiva la generazione di report sugli arresti anomali nell'SDK Mobile Ads chiamando disableSDKCrashReporting.
Dove si trova il mio set di dati BigQuery?
Dopo aver collegato Crashlytics a BigQuery, i nuovi set di dati che crei vengono collocati automaticamente negli Stati Uniti, indipendentemente dalla posizione del progetto Firebase.
Problemi di regressione
Che cos'è un problema rientrante?
Si è verificata una regressione di un problema che avevi già chiuso, ma
Crashlytics riceve una nuova segnalazione che indica che il problema si è verificato di nuovo.
Crashlytics riapre automaticamente questi problemi con regressione in modo che tu possa risolverli in base alle esigenze della tua app.
Ecco uno scenario di esempio che spiega in che modo Crashlytics classifica un problema come regressione:
Per la prima volta, Crashlytics riceve un report sugli arresti anomali relativo all'arresto anomalo "A". Crashlytics apre un problema corrispondente per l'arresto anomalo (Problema "A").
Correggi rapidamente il bug, chiudi il problema "A" e rilascia una nuova versione della tua app.
Crashlytics riceve un'altra segnalazione relativa al problema"A" dopo che lo hai chiuso.
Se il report proviene da una versione dell'app di cui Crashlyticsera a conoscenza
quando hai chiuso il problema (ovvero la versione ha inviato un report di guasto per qualsiasi guasto), Crashlytics non considererà il
problema come regressivo. Il problema rimarrà chiuso.
Se il report proviene da una versione dell'app di cui Crashlyticsnon
era a conoscenza al momento della chiusura del problema (ovvero la versione non aveva
mai inviato nessun report sugli arresti anomali), then
Crashlytics considera il problema in regressione e lo riaprirà.
Quando un problema peggiora, inviamo un avviso di rilevamento di regressione e aggiungiamo un indicatore di regressione al problema per informarti che Crashlytics lo ha riaperto. Se non vuoi che un problema venga riaperto a causa del nostro algoritmo di regressione, "disattiva" il problema anziché chiuderlo.
Perché vedo problemi di regressione per le versioni precedenti dell'app?
Se un report proviene da una versione precedente dell'app che non ha mai inviato report sugli arresti anomali quando hai chiuso il problema, Crashlytics lo considera rientrato e lo riapre.
Questa situazione può verificarsi nel seguente caso: hai corretto un bug e hai rilasciato una nuova versione della tua app, ma ci sono ancora utenti che utilizzano versioni precedenti senza la correzione del bug. Se per caso una di queste versioni precedenti non ha mai inviato alcun report sugli arresti anomali quando hai chiuso il problema e questi utenti iniziano a riscontrare il bug, questi report sugli arresti anomali attiveranno un problema di regressione.
Se non vuoi che un problema venga riaperto a causa del nostro algoritmo di regressione, "disattiva"
il problema anziché chiuderlo.
Segnalare le eccezioni non rilevate come irreversibili
Crashlytics può segnalare le eccezioni non rilevate come irreversibili (a partire dalla
v10.4.0
dell'SDK Unity). Le seguenti domande frequenti aiutano a spiegare il ragionamento e le migliori pratiche per l'utilizzo di questa funzionalità.
Perché un'app dovrebbe segnalare le eccezioni non rilevate come irreversibili?
Se segnali le eccezioni non rilevate come irreversibili, ottieni un'indicazione più realistica su quali eccezioni potrebbero rendere il gioco non giocabile, anche se l'app continua a funzionare.
Tieni presente che se inizi a registrare arresti anomali, la percentuale di utenti senza arresti anomali (CFU) probabilmente diminuirà, ma la metrica CFU sarà più rappresentativa delle esperienze degli utenti finali con la tua app.
Quali eccezioni verranno segnalate come irreversibili?
Affinché Crashlytics segnali un'eccezione non rilevata come irreversibile, devono essere soddisfatte entrambe le seguenti condizioni:
La tua app (o una libreria inclusa) genera un'eccezione che non viene rilevata. Un'eccezione creata, ma non lanciata, non è considerata non rilevata.
Dopo aver attivato la segnalazione delle eccezioni non rilevate come irreversibili, ora ho molti nuovi errori irreversibili. Come faccio a gestire correttamente queste eccezioni?
Quando inizi a ricevere report sulle eccezioni non rilevate come fatali, ecco alcune opzioni per gestirle:
Le eccezioni vengono create e lanciate per riflettere stati inaspettati o eccezionali.
La risoluzione dei problemi riflessi da un'eccezione lanciata comporta il ritorno del
programma a uno stato noto (un processo noto come gestione
delle eccezioni).
È buona norma intercettare e gestire tutte le eccezioni previste, a meno che non sia possibile ripristinare un programma in uno stato noto.
Esistono diversi modi per registrare le eccezioni in Unity o Crashlytics per contribuire a risolvere il problema.
Quando utilizzi Crashlytics, ecco le due opzioni più comuni e consigliate:
Opzione 1: stampa nella console di Unity, ma non invia report a Crashlytics
durante lo sviluppo o la risoluzione dei problemi
Stampa nella console di Unity utilizzando Debug.Log(exception),
Debug.LogWarning(exception) e Debug.LogError(exception), che
stampano i contenuti dell'eccezione nella console di Unity e non
rilanciano l'eccezione.
Opzione 2: carica su Crashlytics per i report consolidati nella dashboard di Crashlytics per le seguenti situazioni:
Se vale la pena registrare un'eccezione per eseguire il debug di un possibile evento Crashlytics successivo, utilizza Crashlytics.Log(exception.ToString()).
Se un'eccezione deve comunque essere segnalata a Crashlytics nonostante sia stata rilevata e gestita, utilizza Crashlytics.LogException(exception) per registrarla come evento non fatale.
Tuttavia, se vuoi segnalare manualmente un evento irreversibile a Unity Cloud Diagnostic, puoi utilizzare Debug.LogException. Questa opzione stampa l'eccezione nella console di Unity come l'opzione 1, ma la genera anche (indipendentemente dal fatto che sia stata generata o rilevata o meno). L'errore viene generato non localmente. Ciò significa che anche un blocco Debug.LogException(exception)
con try-catch adiacente genera un'eccezione non rilevata.
Pertanto, chiama Debug.LogException se e solo se vuoi eseguire tutte le seguenti operazioni:
Per stampare l'eccezione nella console di Unity.
Carica l'eccezione in Crashlytics come evento irreversibile.
Per lanciare l'eccezione, fai in modo che venga trattata come un'eccezione non rilevata e che venga segnalata a Unity Cloud Diagnostics.
Tieni presente che se vuoi stampare un'eccezione rilevata nella console di Unity e caricarla in Crashlytics come evento non fatale, svolgi i seguenti passaggi:
try
{
methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
// Print the exception to the Unity console at the error level.
Debug.LogError(exception);
// Upload the exception to Crashlytics as a non-fatal event.
Crashlytics.LogException(exception); // not Debug.LogException
//
// Code that handles the exception
//
}
