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 in realtà 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 10.8.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:
In particolare, verifica di utilizzare almeno la seguente versione dell'SDK Firebase per Google Analytics: iOS e versioni successive - v6.3.1 e versioni successive (v8.9.0 e versioni successive per macOS e tvOS).
I file dSYM mancano/non vengono caricati
Per caricare i file dSYM del progetto e ottenere un output dettagliato, verifica quanto segue:
Assicurati che la fase di compilazione del progetto contenga lo script di esecuzione Crashlytics, che consente a Xcode di caricare i file dSYM del progetto in fase di compilazione (leggi Inizializza Crashlytics per istruzioni su come aggiungere lo script). Dopo aver aggiornato il progetto,
forza un arresto anomalo e verifica che l'arresto anomalo
appaia nella dashboard Crashlytics.
Se nella console Firebase viene visualizzato un avviso "Manca il file dSYM", controlla Xcode per assicurarti che produca correttamente i file dSYM per la compilazione.
Se Xcode genera correttamente i file dSYM e continui a visualizzare file dSYM mancanti,
è probabile che lo strumento di script di esecuzione si blocchi durante il caricamento dei file dSYM.
In questo caso, prova a eseguire una delle seguenti operazioni:
Assicurati di utilizzare la versione più recente di Crashlytics.
Carica manualmente i file dSYM mancanti:
Opzione 1: utilizza l'opzione "Trascina e rilascia" basata sulla console nella
scheda dSYM
per caricare un archivio ZIP contenente i file dSYM mancanti.
Opzione 2: utilizza lo
script upload-symbols
per caricare i file dSYM mancanti per gli UUID forniti nella scheda dSYM.
Se continui a visualizzare file dSYM mancanti o i caricamenti non vanno a buon fine, contatta l'assistenza di Firebase e assicurati di includere i log.
Gli arresti anomali sono scarsamente simbolizzati
Se le tracce dello stack sembrano essere scarsamente simbolizzate, controlla quanto segue:
Se i frame della libreria dell'app non contengono riferimenti al codice dell'app, assicurati che -fomit-frame-pointer non sia impostato come flag di compilazione.
Se vedi diversi frame (Missing) per la libreria della tua app, controlla se sono presenti file dSYM facoltativi elencati come mancanti (per la versione dell'app interessata) nella Crashlyticsscheda dSYM della console Firebase. In questo caso, segui il passaggio per la risoluzione dei problemi "Avviso dSYM mancante" riportato nella Domande frequenti sui file dSYM mancanti/non caricati in questa pagina. Tieni presente che il caricamento di questi file dSYM non simbolizzerà gli arresti anomali
già avvenuti, ma contribuirà a garantire la simbolizzazione per
gli arresti anomali
futuri.
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.
Supporto della piattaforma
Posso utilizzare Crashlytics per macOS o tvOS?
Sì, puoi implementare Crashlytics nei progetti per macOS e tvOS. Assicurati di includere la versione 8.9.0 o successive dell'SDK Firebase per Google Analytics in modo che gli arresti anomali abbiano accesso alle metriche raccolte da Google Analytics (utenti senza arresti anomali, release più recente, avvisi sulla velocità e log breadcrumb).
Posso utilizzare Crashlytics in un progetto Firebase con più app su piattaforme Apple diverse?
Ora puoi segnalare arresti anomali per più app in un unico progetto Firebase, anche se le app sono create per piattaforme Apple diverse (ad es. iOS, tvOS e Mac Catalyst). In precedenza, dovevi separare le app in singoli progetti Firebase se contenevano lo stesso ID bundle.
Problemi di regressione
Che cos'è un problema di regressione?
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 in regressione. 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 che il problema sia regredito 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é riscontro 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.
