Risoluzione dei problemi e domande frequenti su Crashlytics

iOS+ Android Flutter Unity

Questa pagina fornisce assistenza per la risoluzione dei problemi e risposte alle domande frequenti sull'utilizzo di Crashlytics. Se non riesci a trovare quello che cerchi o hai bisogno di ulteriore aiuto, contatta l'assistenza Firebase.

Risoluzione dei problemi generali/domande frequenti

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 della console Firebase. Potresti anche notare una funzionalità chiamata "varianti" all'interno di alcuni problemi. Ecco perché.

All'inizio del 2023 abbiamo implementato un motore di analisi migliorato per il raggruppamento degli eventi, un design aggiornato e alcune funzionalità avanzate per i nuovi problemi (come le varianti). Consulta il nostro recente post del blog per tutti i dettagli, ma puoi leggere di seguito i punti salienti.

Crashlytics analizza tutti gli eventi della tua app (come 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, inclusi i frame nello stack trace, 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 cause principali diverse portano all'errore.

Ecco cosa potrai fare con questi miglioramenti:

• Metadati rinnovati visualizzati all'interno della riga del problema
  Ora è più facile comprendere e gestire 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 indicatori più significativi
  Un nuovo problema rappresenta in realtà un nuovo bug.

• Ricerca più potente
  Ogni problema contiene metadati più ricercabili, come il tipo di eccezione e il nome del pacchetto.

Ecco come vengono implementati questi miglioramenti:

• Quando riceviamo nuovi eventi dalla tua app, verifichiamo se corrispondono a un problema esistente.

• Se non viene trovata una 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 apportiamo al raggruppamento degli eventi. Se hai feedback o riscontri problemi, comunicacelo inviando una segnalazione.

Non visualizzare i log breadcrumb

Se non visualizzi i log breadcrumb, ti consigliamo di controllare la configurazione dell'app per Google Analytics. Assicurati di soddisfare i seguenti requisiti:

• Hai attivato Google Analytics nel tuo progetto Firebase.

• Hai attivato la condivisione dei dati per Google Analytics. Scopri di più su questa impostazione in Gestire le impostazioni di condivisione dei dati di Analytics

• Hai aggiunto l'SDK Firebase per Google Analytics alla tua app. Questo SDK deve essere aggiunto in aggiunta all'SDK Crashlytics.

• Stai utilizzando le ultime versioni dell'SDK Firebase per tutti i prodotti che utilizzi nella tua app.

Non visualizzare gli avvisi di velocità

Se non visualizzi gli avvisi di velocità, assicurati di utilizzare l'SDK Crashlytics 11.7.0 o versioni successive.

Non visualizzare le metriche senza arresti anomali (o visualizzare metriche inaffidabili)

Se non visualizzi le metriche relative agli arresti anomali (ad esempio utenti e sessioni senza arresti anomali) o se le metriche non sono affidabili, controlla quanto segue:

• Assicurati di utilizzare l'SDK Crashlytics 11.7.0 o versioni successive.

• Assicurati che le impostazioni di raccolta dei dati non influiscano sulla qualità delle metriche senza arresti anomali:

  • Se attivi i report con consenso disattivando i report sugli arresti anomali automatici, le informazioni sugli arresti anomali possono essere inviate a Crashlytics solo dagli utenti che hanno attivato esplicitamente la raccolta dei dati. Pertanto, l'accuratezza delle metriche senza arresti anomali sarà interessata, poiché Crashlytics dispone solo delle informazioni sugli arresti anomali di questi utenti che hanno attivato l'opzione (anziché di tutti gli utenti). Ciò significa che le metriche senza arresti anomali potrebbero essere meno affidabili e meno rappresentative della stabilità complessiva della tua app.

  • Se hai disattivato la raccolta automatica dei dati, puoi utilizzare sendUnsentReports per inviare a Crashlytics i report memorizzati nella cache sul dispositivo. L'utilizzo di questo metodo invierà i dati relativi agli arresti anomali a Crashlytics, ma non i dati relativi alle sessioni, il che fa sì che i grafici della console mostrino valori bassi o pari a zero per le metriche senza arresti anomali.

Come vengono calcolati gli utenti senza arresti anomali?

Consulta Comprendere le metriche senza arresti anomali.

Visualizzazione di analisi dello stack senza simboli per le app per Android nella dashboard Crashlytics

Se utilizzi Unity IL2CPP e visualizzi stack trace non simbolici, prova a svolgere le seguenti operazioni:

1. Assicurati di utilizzare la versione 8.6.1 o successive dell'SDK Unity Crashlytics.

2. Assicurati di aver configurato ed eseguito il comando crashlytics:symbols:upload dell'interfaccia a riga di comando Firebase per generare e caricare il file dei simboli.

   Devi eseguire questo comando CLI ogni volta che crei una build di rilascio o qualsiasi build per la quale vuoi visualizzare le analisi dello stack con simboli nella console Firebase. Scopri di più nella pagina Ottenere report sugli arresti anomali leggibili.

Crashlytics può essere utilizzato con app che utilizzano IL2CPP?

Sì, Crashlytics può visualizzare le analisi dello stack con simboli per le tue app che utilizzano IL2CPP. Questa funzionalità è disponibile per le app rilasciate sulle piattaforme Android o Apple. Ecco cosa devi fare:

1. Assicurati di utilizzare la versione 8.6.0 o successive dell'SDK Unity Crashlytics.

2. Completa le attività necessarie per la tua piattaforma:

   • Per le app della piattaforma Apple: non sono necessarie azioni speciali. Per le app per piattaforma Apple, il plug-in Firebase Unity Editor configura automaticamente il progetto Xcode per caricare i simboli.

   • Per le app per Android: assicurati di aver configurato ed eseguito il comando Firebase CLI crashlytics:symbols:upload per generare e caricare il file dei simboli.

     Devi eseguire questo comando CLI ogni volta che crei una build di rilascio o qualsiasi build per la quale vuoi visualizzare le analisi dello stack con simboli nella console Firebase. Scopri di più nella pagina Ottenere report sugli arresti anomali leggibili.

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 di stato e così via.

Quando un membro del progetto pubblica una nota, questa viene etichettata con l'email del suo Account Google. Questo indirizzo email è visibile, insieme alla nota, a tutti i membri del progetto con accesso alla visualizzazione della 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.

  • Proprietario o Editor del progetto, Amministratore Firebase, Amministratore qualità, o Amministratore Crashlytics

• I membri del progetto con uno dei seguenti ruoli possono visualizzare le note pubblicate in un problema, ma non possono eliminarle o scriverne una.

  • Visualizzatore del progetto, Visualizzatore Firebase, Visualizzatore qualità, o Visualizzatore Crashlytics

Integrazioni

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 reporter di arresti anomali interferiscano con la registrazione dei gestori di eccezioni. Per risolvere il problema, disattiva la segnalazione di 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 si trovano automaticamente negli Stati Uniti, indipendentemente dalla posizione del tuo progetto Firebase.

Problemi regrediti

Che cos'è un problema di regressione?

Un problema ha subito una regressione quando lo hai chiuso in precedenza, ma Crashlytics riceve una nuova segnalazione che indica che il problema si è ripresentato. Crashlytics riapre automaticamente questi problemi di regressione in modo che tu possa risolverli nel modo più appropriato per la tua app.

Ecco uno scenario di esempio che spiega come Crashlytics classifica un problema come regressione:

1. 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").
2. Correggi rapidamente questo bug, chiudi il problema "A" e rilascia una nuova versione della tua app.
3. Crashlytics riceve un'altra segnalazione relativa al problema"A" dopo che lo hai chiuso.
   • Se il report proviene da una versione dell'app che Crashlytics era a conoscenza quando hai chiuso il problema (ovvero la versione aveva inviato un report sugli arresti anomali per qualsiasi arresto anomalo), allora Crashlytics non considererà il problema come regresso. Il problema rimarrà chiuso.
   • Se la segnalazione proviene da una versione dell'app che Crashlytics non conosceva quando hai chiuso il problema (ovvero la versione non aveva mai inviato alcuna segnalazione di arresto anomalo), allora Crashlytics considera il problema come regredito e lo riaprirà.

Nota:prima di febbraio 2022, Crashlytics classificava un problema come regressione quando si ripresentava in qualsiasi versione dell'app, anche per le versioni dell'app che conoscevamo quando hai chiuso il problema. Di conseguenza, Crashlytics a volte identifica in modo impreciso le regressioni. Ora utilizziamo la convenzione descritta sopra.

Quando un problema regredisce, inviamo un avviso di rilevamento della regressione e aggiungiamo un indicatore di regressione al problema per comunicarti che Crashlytics ha riaperto il problema. Se non vuoi che un problema venga riaperto a causa del nostro algoritmo di regressione, "silenzia" il problema anziché chiuderlo.

Perché vedo problemi di regressione per le versioni precedenti dell'app?

Se un report proviene da una vecchia versione dell'app che non aveva mai inviato report sugli arresti anomali quando hai chiuso il problema, Crashlytics considera il problema regredito e lo riaprirà.

Questa situazione può verificarsi quando hai corretto un bug e hai rilasciato una nuova versione dell'app, ma ci sono ancora utenti che utilizzano versioni precedenti senza la correzione del bug. Se, per caso, una di queste versioni precedenti non avesse 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 attiverebbero un problema di regressione.

Se non vuoi che un problema venga riaperto a causa del nostro algoritmo di regressione, "disattiva" il problema anziché chiuderlo.

Nota :prima di febbraio 2022, Crashlytics classificava un problema come regressione quando si ripresentava in qualsiasi versione dell'app, anche per le versioni dell'app di cui eravamo a conoscenza quando hai chiuso il problema. Di conseguenza, Crashlytics a volte identifica in modo impreciso le regressioni. Ora utilizziamo la convenzione descritta sopra.

Se noti molte regressioni identificate erroneamente prima di febbraio 2022, puoi chiuderle di nuovo per evitare che si riaprano.

Segnalare le eccezioni non rilevate come errori irreversibili

Crashlytics può segnalare le eccezioni non rilevate come errori irreversibili (a partire dalla versione 10.4.0 dell'SDK Unity). Le seguenti domande frequenti aiutano a spiegare la logica e le best practice per l'utilizzo di questa funzionalità.

Perché un'app dovrebbe segnalare le eccezioni non rilevate come errori irreversibili?

Se segnali le eccezioni non rilevate come irreversibili, ottieni un'indicazione più realistica di quali eccezioni potrebbero rendere il gioco ingiocabile, anche se l'app continua a essere eseguita.

Tieni presente che se inizi a segnalare errori irreversibili, 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.

Importante: la segnalazione di eccezioni non rilevate come errori irreversibili non influisce su Android vitals. Gli errori irreversibili segnalati in Crashlytics sono visibili solo a te, in modo che tu possa scoprire e risolvere i problemi nelle tue app e nei tuoi giochi.

Quali eccezioni verranno segnalate come irreversibili?

Affinché Crashlytics possa segnalare un'eccezione non rilevata come irreversibile, devono essere soddisfatte entrambe le seguenti condizioni:

• Durante l'inizializzazione nell'app, la proprietà ReportUncaughtExceptionsAsFatal deve essere impostata su true.

• La tua app (o una libreria inclusa) genera un'eccezione che non viene rilevata. Un'eccezione creata, ma non generata, non viene considerata non rilevata.

Dopo aver attivato la segnalazione delle eccezioni non rilevate come errori irreversibili, ora ho molti nuovi errori irreversibili. Come faccio a gestire correttamente queste eccezioni?

Quando inizi a ricevere report sulle eccezioni non rilevate come errori irreversibili, ecco alcune opzioni per la gestione di queste eccezioni non rilevate:

• Valuta come iniziare a rilevare e gestire queste eccezioni non rilevate.
• Valuta diverse opzioni per registrare le eccezioni nella console di debug di Unity e in Crashlytics.

Rilevare e gestire le eccezioni generate

Le eccezioni vengono create e generate per riflettere stati imprevisti o eccezionali. La risoluzione dei problemi indicati da un'eccezione generata comporta il ripristino del programma a uno stato noto (un processo noto come gestione delle eccezioni).

La best practice consiste nell'intercettare e gestire tutte le eccezioni previste, a meno che il programma non possa essere riportato a uno stato noto.

Per controllare quali tipi di eccezioni vengono rilevati e gestiti da quale codice, inserisci il codice che potrebbe generare un'eccezione in un blocco try-catch. Assicurati che le condizioni nelle istruzioni catch siano il più specifiche possibile per gestire le eccezioni specifiche in modo appropriato.

Registrare 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 segnalare a Crashlytics, durante lo sviluppo o la risoluzione dei problemi

  • Stampa nella console Unity utilizzando Debug.Log(exception), Debug.LogWarning(exception) e Debug.LogError(exception), che stampano i contenuti dell'eccezione nella console Unity e non generano nuovamente l'eccezione.

• Opzione 2: carica su Crashlytics per report consolidati nella dashboard 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 Diagnostics, puoi utilizzare Debug.LogException. Questa opzione stampa l'eccezione nella console Unity come l'opzione 1, ma genera anche l'eccezione (indipendentemente dal fatto che sia stata generata o rilevata). Genera l'errore in modo non locale. Ciò significa che anche un Debug.LogException(exception) circostante con blocchi try-catch genera un'eccezione non rilevata.

Pertanto, chiama Debug.LogException solo se vuoi fare tutte le seguenti operazioni:

• Per stampare l'eccezione nella console Unity.
• Per caricare l'eccezione su Crashlytics come evento irreversibile.
• Per generare l'eccezione, trattala come un'eccezione non rilevata e segnalala a Unity Cloud Diagnostics.

Tieni presente che se vuoi stampare un'eccezione rilevata nella console Unity e caricarla su Crashlytics come evento non irreversibile, segui invece questa procedura:

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
    //
}