Questa pagina fornisce assistenza per la risoluzione dei problemi e risposte alle domande più frequenti sull'utilizzo di Crashlytics. Se non riesci a trovare quello che stai cercando o hai bisogno di ulteriore aiuto, contatta l'assistenza Firebase .
Risoluzione dei problemi generali/FAQ
Potresti notare due formati diversi per i problemi elencati nella tabella Problemi nella console Firebase. E 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 numeri (come le varianti!). Dai un'occhiata al nostro recente post sul blog per tutti i dettagli, ma puoi leggere di seguito per i punti salienti.
Crashlytics analizza tutti gli eventi della tua app (come arresti anomali, eventi 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, inclusi i frame nell'analisi 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 significare una causa principale diversa. Per rappresentare questa possibile differenza all'interno di un problema, ora creiamo varianti all'interno dei problemi: ciascuna variante è un sottogruppo di eventi in un problema che hanno lo stesso punto di errore e una traccia 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 stanno causando l'errore.
Ecco cosa sperimenterai con questi miglioramenti:
Metadati rinnovati visualizzati nella riga del problema
Ora è più semplice comprendere e valutare i problemi nella tua app.Meno problemi duplicati
Una modifica del numero di riga non comporta un nuovo problema.Debug più semplice di 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 segnali più significativi
Un nuovo problema rappresenta in realtà un nuovo bug.Ricerca più potente
Ogni numero contiene più metadati ricercabili, come il tipo di eccezione e il nome del pacchetto.
Ecco come verranno implementati questi miglioramenti:
Quando riceviamo nuovi eventi dalla tua app, controlleremo se corrispondono a un problema esistente.
Se non c'è corrispondenza, applicheremo automaticamente il nostro algoritmo di raggruppamento degli eventi più intelligente all'evento e creeremo un nuovo problema con il design dei metadati rinnovato.
Questo è il primo grande aggiornamento che stiamo apportando al nostro raggruppamento di eventi. Se hai feedback o riscontri problemi, faccelo sapere inviando una segnalazione.
Se non visualizzi metriche prive di arresti anomali (come utenti e sessioni senza arresti anomali) e/o avvisi di velocità, assicurati di utilizzare l'SDKCrashlytics SDK 11.7.0+.
Se non visualizzi i log breadcrumb , ti consigliamo di controllare la configurazione della tua app per Google Analytics. Assicurati di soddisfare i seguenti requisiti:
Hai abilitato Google Analytics nel tuo progetto Firebase.
Hai abilitato la condivisione dei dati per Google Analytics. Scopri di più su questa impostazione in Gestisci le impostazioni di condivisione dei dati di Analytics
Hai aggiuntoaggiunto l'SDK Firebase per Google Analyticsalla tua app. Questo SDK deve essere aggiunto in aggiunta all'SDK di Crashlytics.
Stai utilizzando le ultime versioni dell'SDK di Firebasele ultime versioni dell'SDK di Firebaseper tutti i prodotti che utilizzi nella tua app.
Se stai utilizzando Unity IL2CPP e visualizzi analisi dello stack non simbolizzate, prova quanto segue:
Assicurati di utilizzare la versione 8.6.1 o successiva dell'SDK Crashlytics Unity.
Assicurati di aver configurato ed eseguito il comando
crashlytics:symbols:uploaddella CLI Firebase per generare e caricare il file di simboli.Devi eseguire questo comando CLI ogni volta che crei una build di rilascio o qualsiasi build per la quale desideri visualizzare tracce di stack simboliche nella console Firebase. Scopri di più nella pagina Ottieni rapporti sugli arresti anomali leggibili .
Sì, Crashlytics può visualizzare analisi dello stack simboliche per le tue app che utilizzano IL2CPP. Questa funzionalità è disponibile per le app rilasciate su piattaforme Android o Apple. Ecco cosa devi fare:
Assicurati di utilizzare la versione 8.6.0 o successiva dell'SDK Crashlytics Unity.
Completa le attività necessarie per la tua piattaforma:
Per le app della piattaforma Apple : non sono necessarie azioni speciali. Per le app della piattaforma Apple, il plug-in Firebase Unity Editor configura automaticamente il tuo progetto Xcode per caricare i simboli.
Per le app Android : assicurati di aver configurato ed eseguito il comando
crashlytics:symbols:uploaddella CLI Firebase per generare e caricare il file di simboli.Devi eseguire questo comando CLI ogni volta che crei una build di rilascio o qualsiasi build per la quale desideri visualizzare tracce di stack simboliche nella console Firebase. Scopri di più nella pagina Ottieni rapporti sugli arresti anomali leggibili .
Il valore senza arresti anomali rappresenta la percentuale di utenti che hanno interagito con la tua app ma non hanno subito arresti anomali in un periodo di tempo specifico.
Ecco la formula per calcolare la percentuale di utenti senza crash. I suoi 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_exceptione CRASHED_USERS rappresenta il numero di utenti associati a quel tipo di evento.ALL_USERS rappresenta il numero totale di utenti che hanno interagito con la tua app nel periodo di tempo che hai selezionato dal menu a discesa in alto a destra nella dashboard di Crashlytics.
La percentuale di utenti senza arresti anomali è un'aggregazione nel tempo e non una media.
Ad esempio, immagina che la tua app abbia tre utenti; li chiameremo Utente A, Utente B e Utente C. La tabella seguente mostra quali utenti hanno utilizzato la tua app ogni giorno e quali di questi utenti hanno avuto un arresto anomalo quel giorno:
| Lunedi | Martedì | Mercoledì | |
|---|---|---|---|
| Utenti che hanno interagito con la tua app | A, B, C | A, B, C | A, B |
| Utente che ha avuto un arresto anomalo | C | B | UN |
Mercoledì, la percentuale di utenti senza arresti anomali è del 50% (1 utente su 2 non ha avuto arresti anomali).
Due dei tuoi utenti hanno interagito con la tua app mercoledì, ma solo uno di loro (Utente B) non ha avuto arresti anomali.Negli ultimi 2 giorni, la percentuale di utenti senza arresti anomali è stata del 33,3% (1 utente su 3 non ha avuto 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 senza arresti anomali è stata dello 0% (0 utenti su 3 non hanno avuto 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 su periodi di tempo diversi. La probabilità che un singolo utente subisca un arresto anomalo aumenta quanto più volte utilizza la tua app, quindi è probabile che il valore degli utenti senza arresti anomali sia inferiore per periodi di tempo più lunghi.
Le note consentono ai membri del progetto di commentare questioni specifiche con domande, aggiornamenti di stato, ecc.
Quando un membro del progetto pubblica una nota, questa viene etichettata con l'e-mail del suo account Google. Questo indirizzo email è visibile, insieme alla nota, a tutti i membri del progetto con accesso per visualizzare la nota.
Di seguito viene descritto l'accesso richiesto per visualizzare, scrivere ed eliminare le note:
I membri del progetto con uno qualsiasi dei seguenti ruoli possono visualizzare ed eliminare le note esistenti e scrivere nuove note su un problema.
I membri del progetto con uno qualsiasi dei seguenti ruoli possono visualizzare le note pubblicate su un problema, ma non possono eliminare o scrivere una nota.
Consulta Comprendere le metriche senza arresti anomali .
Le note consentono ai membri del progetto di commentare questioni specifiche con domande, aggiornamenti di stato, ecc.
Quando un membro del progetto pubblica una nota, questa viene etichettata con l'e-mail del suo account Google. Questo indirizzo email è visibile, insieme alla nota, a tutti i membri del progetto con accesso per visualizzare la nota.
Di seguito viene descritto l'accesso richiesto per visualizzare, scrivere ed eliminare le note:
I membri del progetto con uno qualsiasi dei seguenti ruoli possono visualizzare ed eliminare le note esistenti e scrivere nuove note su un problema.
I membri del progetto con uno qualsiasi dei seguenti ruoli possono visualizzare le note pubblicate su un problema, ma non possono eliminare o scrivere una nota.
Integrazioni
Se il tuo progetto utilizza Crashlytics insieme a Google Mobile Ads SDK, è probabile che i crash reporter interferiscano durante la registrazione dei gestori delle eccezioni. Per risolvere il problema, disattiva la segnalazione degli arresti anomali nell'SDK Mobile Ads chiamando disableSDKCrashReporting .
Dopo aver collegato Crashlytics a BigQuery, i nuovi set di dati creati vengono automaticamente posizionati negli Stati Uniti, indipendentemente dalla posizione del tuo progetto Firebase.
Problemi regrediti
Si è verificata una regressione di un problema dopo averlo chiuso in precedenza, ma Crashlytics riceve un nuovo report indicante che il problema si è ripresentato. Crashlytics riapre automaticamente questi problemi regrediti in modo che tu possa risolverli in modo appropriato per la tua app.
Di seguito è riportato uno scenario di esempio che spiega in che modo Crashlytics classifica un problema come regressione:
- Per la prima volta in assoluto, Crashlytics riceve un rapporto sull'incidente relativo al Crash "A". Crashlytics apre un problema corrispondente per quell'arresto anomalo (problema "A").
- Correggi rapidamente questo bug, chiudi il problema "A" e quindi rilasci una nuova versione della tua app.
- Crashlytics riceve un altro rapporto sul problema "A" dopo che hai chiuso il problema.
- Se il report proviene da una versione dell'app di cui Crashlytics era a conoscenza quando hai chiuso il problema (il che significa che la versione aveva inviato un report di arresto anomalo per qualsiasi arresto anomalo), Crashlytics non considererà il problema regredito. La questione resterà chiusa.
- Se il rapporto proviene da una versione dell'app di cui Crashlytics non era a conoscenza quando hai chiuso il problema (il che significa che la versione non ha mai inviato alcun rapporto sugli arresti anomali per alcun arresto anomalo), Crashlytics considera il problema regredito e lo riaprirà .
Quando un problema regredisce, inviamo un avviso di rilevamento della regressione e aggiungiamo un segnale di regressione al problema per farti sapere che Crashlytics ha riaperto il problema. Se non desideri che un problema si riapra a causa del nostro algoritmo di regressione, "disattiva" il problema invece di chiuderlo.
Se un rapporto proviene da una versione precedente dell'app che non ha mai inviato alcun rapporto sugli arresti anomali quando hai chiuso il problema, Crashlytics considererà il problema regredito e lo riaprirà.
Questa situazione può verificarsi nella seguente situazione: hai corretto un bug e rilasciato una nuova versione della tua app, ma hai ancora utenti con versioni precedenti senza la correzione del bug. Se, per caso, una di quelle versioni precedenti non avesse mai inviato alcun rapporto sugli arresti anomali quando hai chiuso il problema e quegli utenti iniziassero a riscontrare il bug, quei rapporti sugli arresti anomali attiverebbero un problema regredito.
Se non desideri che un problema si riapra a causa del nostro algoritmo di regressione, "disattiva" il problema invece di chiuderlo.
Segnalazione delle eccezioni non rilevate come fatali
Crashlytics può segnalare le eccezioni non rilevate come irreversibili (a partire dalla versione 10.4.0 dell'SDK Unity). Le seguenti domande frequenti aiutano a spiegare le motivazioni e le migliori pratiche per l'utilizzo di questa funzionalità.
Segnalando le eccezioni non rilevate come fatali, ottieni un'indicazione più realistica di quali eccezioni potrebbero rendere il gioco ingiocabile, anche se l'app continua a funzionare.
Tieni presente che se inizi a segnalare incidenti fatali, 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.
Affinché Crashlytics possa segnalare un'eccezione non rilevata come irreversibile, devono essere soddisfatte entrambe le seguenti condizioni:
Durante l'inizializzazione nell'app, la proprietà
ReportUncaughtExceptionsAsFataldeve essere impostata sutrue.La tua app (o una libreria inclusa) genera un'eccezione che non viene rilevata. Un'eccezione creata, ma non generata , non è considerata non rilevata.
Quando inizi a ricevere segnalazioni di eccezioni non rilevate come irreversibili, ecco alcune opzioni per gestire queste eccezioni non rilevate:
- Considera come iniziare a rilevare e gestire queste eccezioni non rilevate.
- Considera diverse opzioni per la registrazione delle eccezioni nella console di debug Unity e in Crashlytics.
Cattura e gestisci le eccezioni generate
Le eccezioni vengono create e generate per riflettere stati imprevisti o eccezionali . Risolvere i problemi riflessi da un'eccezione generata implica riportare il programma a uno stato noto (un processo noto come gestione delle eccezioni ).
È buona norma individuare e gestire tutte le eccezioni previste, a meno che non sia possibile riportare il programma a uno stato noto.
Per controllare quali tipi di eccezioni vengono intercettate e gestite da quale codice, racchiudi il codice che potrebbe generare un'eccezione in un blocco try-catch . Assicurarsi che le condizioni nelle dichiarazioni catch siano quanto più restrittive possibile per gestire le eccezioni specifiche in modo appropriato.
Registra le eccezioni in Unity o Crashlytics
Esistono diversi modi per registrare le eccezioni in Unity o Crashlytics per facilitare il debug del problema.
Quando utilizzi Crashlytics, ecco le due opzioni più comuni e consigliate:
Opzione 1: stampa nella console Unity, ma non segnalarlo a Crashlytics, durante lo sviluppo o la risoluzione dei problemi
- Stampa sulla console Unity utilizzando
Debug.Log(exception),Debug.LogWarning(exception)eDebug.LogError(exception)che stampano il contenuto dell'eccezione sulla console Unity e non generano nuovamente l'eccezione.
- Stampa sulla console Unity utilizzando
Opzione 2: caricamento in Crashlytics per la creazione di 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, utilizzare
Crashlytics.Log(exception.ToString()). - Se un'eccezione deve essere comunque segnalata a Crashlytics nonostante sia stata rilevata e gestita, utilizzare
Crashlytics.LogException(exception)per registrarla come evento non fatale.
- Se vale la pena registrare un'eccezione per eseguire il debug di un possibile evento Crashlytics successivo, utilizzare
Tuttavia, se desideri segnalare manualmente un evento irreversibile a Unity Cloud Diagnostics, puoi utilizzare Debug.LogException . Questa opzione stampa l'eccezione sulla console Unity come l'Opzione 1, ma genera anche l'eccezione (indipendentemente dal fatto che sia stata lanciata o rilevata o meno). Genera l'errore in modo non locale. Ciò significa che anche un'eccezione Debug.LogException(exception) circostante con blocchi try-catch risulta comunque in un'eccezione non rilevata.
Pertanto, chiama Debug.LogException se e solo se desideri eseguire tutte le operazioni seguenti:
- Per stampare l'eccezione sulla console Unity.
- Per caricare l'eccezione in Crashlytics come evento irreversibile.
- Per generare un'eccezione, trattala come un'eccezione non rilevata e segnalala a Unity Cloud Diagnostics.
Tieni presente che se desideri stampare un'eccezione rilevata sulla console Unity e caricarla su Crashlytics come evento non irreversibile, procedi invece come segue:
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
//
}