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 le
molti aspetti dell'evento, tra cui i frame nell'analisi dello stack,
messaggio di eccezione, il codice di errore e un'altra piattaforma o tipo di errore
caratteristiche.
Tuttavia, all'interno di questo gruppo di eventi, le analisi dello stack che hanno portato all'errore
potrebbe essere diverso. 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 riscontrerai con i miglioramenti apportati:
Metadati rinnovati visualizzati nella riga del problema Ora è più facile comprendere e gestire i problemi nella tua app.
Meno problemi duplicati Una 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 in realtà un nuovo bug.
Ricerca più potente 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, ne verifichiamo la corrispondenza
problema.
Se non esistono corrispondenze, applicheremo automaticamente il nostro raggruppamento di eventi più intelligente
all'evento e creare un nuovo problema con i metadati aggiornati
la progettazione.
Questo è il primo grande aggiornamento che stiamo apportando al raggruppamento degli eventi. Se hai un feedback o riscontri problemi, comunicacelo inviando un report.
Non visibili
metriche senza arresti anomali e/o avvisi di 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
Log dei breadcrumb non visualizzati
Se non vedi
log breadcrumb,
ti consigliamo di controllare la configurazione dell'app per Google Analytics.
Assicurati di soddisfare i seguenti requisiti:
Hai
alla tua app. Questo SDK deve essere aggiunto oltre all'SDK Crashlytics.
Utilizzi le
per tutti i prodotti che utilizzi nella tua app.
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 viene descritto l'accesso necessario per visualizzare, scrivere ed eliminare
Note:
I membri del progetto con uno dei seguenti ruoli possono visualizzare ed eliminare quelli esistenti
note 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 viene descritto l'accesso necessario per visualizzare, scrivere ed eliminare
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
SDK Google Mobile Ads, ma senza arresti anomali
Se il tuo progetto utilizza Crashlytics insieme all'SDK Google Mobile Ads,
è probabile che i reporter sugli arresti anomali interferiscano quando
la registrazione di gestori di eccezioni. Per risolvere il problema, disattiva i report sugli arresti anomali in
l'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.
Supporto delle piattaforme
Problemi di regressione
Che cos'è un modello pregresso
problema?
Si è verificato un problema di regressione quando l'hai chiuso in precedenza, ma
Crashlytics riceve una nuova segnalazione che indica che il problema si è verificato.
Crashlytics riapre automaticamente questi problemi pregressi per consentirti
affrontarli in modo appropriato per la tua app.
Ecco uno scenario di esempio che spiega in che modo Crashlytics classifica un problema come regressione:
Per la prima volta in assoluto, Crashlytics riceve un report sugli arresti anomali relativo all'arresto anomalo
"A". Crashlytics apre un problema corrispondente per l'arresto anomalo (Problema "A").
Risolvi rapidamente il bug, chiudi il problema "A" e rilasci una nuova versione di
la 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 che Crashlyticssapeva
quando hai chiuso il problema (ovvero la versione aveva inviato un arresto anomalo
per qualsiasi arresto anomalo), Crashlytics non prenderà in considerazione
il problema come pregresso. Il problema rimarrà chiuso.
Se il report proviene da una versione dell'app che Crashlyticsha non
informazioni quando hai chiuso il problema (ossia la versione aveva
non ha mai inviato alcun report sugli arresti anomali per nessun arresto anomalo), quindi
Crashlytics considera che il problema sia pregresso e riaprirà lo
problema.
Quando un problema regredisce, inviamo un avviso di rilevamento di regressione e aggiungiamo
segnale di regressione al problema per indicarti che Crashlytics ha
ha riaperto il problema. Se non vuoi che un problema venga riaperto a causa del nostro algoritmo di regressione, "disattiva" il problema anziché chiuderlo.
Perché vedo i dati pregressi
problemi con 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.
