Personalizza i report sugli arresti anomali di Firebase Crashlytics

iOS+ Android Flutter Unity

Nella dashboard Crashlytics, puoi fare clic su un problema per visualizzare un report dettagliato sugli eventi. Puoi personalizzare questi report per comprendere meglio cosa succede nella tua app e le circostanze relative agli eventi segnalati a Crashlytics.

• Strumenta la tua app per registrare chiavi personalizzate, messaggi di log personalizzati e identificatori utente.

• Segnala le eccezioni a Crashlytics.

• Ricevi automaticamente i log dei breadcrumb se la tua app utilizza l'SDK Firebase per Google Analytics. Questi log ti consentono di monitorare le azioni degli utenti che precedono un evento raccolto da Crashlytics nella tua app.

• Disattiva i report automatici sugli arresti anomali e attiva i report di attivazione per i tuoi utenti. Tieni presente che, per impostazione predefinita, Crashlytics raccoglie automaticamente i report sugli arresti anomali per tutti gli utenti della tua app.

Aggiungere chiavi personalizzate

Le chiavi personalizzate ti consentono di conoscere lo stato specifico della tua app che ha causato un arresto anomalo. Puoi associare coppie chiave/valore arbitrarie ai report sugli arresti anomali, quindi utilizzare le chiavi personalizzate per cercare e filtrare i report sugli arresti anomali nella console Firebase.

• Nella dashboard Crashlytics, puoi cercare i problemi che corrispondono a una chiave personalizzata.
• Quando esamini un problema specifico nella console, puoi visualizzare le chiavi personalizzate associate per ogni evento (scheda secondaria Chiavi) e persino filtrare gli eventi in base alle chiavi personalizzate (menu Filtro nella parte superiore della pagina).

Nota: Crashlytics supporta un massimo di 64 coppie chiave/valore. Una volta raggiunta questa soglia, i valori aggiuntivi non vengono salvati. Ogni coppia chiave/valore può avere una dimensione massima di 1 kB.

Utilizza il metodo setCustomValue per impostare le coppie chiave/valore. Ad esempio:

Swift

// Set int_key to 100.
Crashlytics.crashlytics().setCustomValue(100, forKey: "int_key")

// Set str_key to "hello".
Crashlytics.crashlytics().setCustomValue("hello", forKey: "str_key")

Objective-C

Quando imposti numeri interi, valori booleani o valori in virgola mobile, inserisci il valore in una casella come @(value).

// Set int_key to 100.
[[FIRCrashlytics crashlytics] setCustomValue:@(100) forKey:@"int_key"];

// Set str_key to "hello".
[[FIRCrashlytics crashlytics] setCustomValue:@"hello" forKey:@"str_key"];

Puoi anche modificare il valore di una chiave esistente richiamandola e impostandola su un valore diverso. Ad esempio:

Swift

Crashlytics.crashlytics().setCustomValue(100, forKey: "int_key")

// Set int_key to 50 from 100.
Crashlytics.crashlytics().setCustomValue(50, forKey: "int_key")

Objective-C

[[FIRCrashlytics crashlytics] setCustomValue:@(100) forKey:@"int_key"];

// Set int_key to 50 from 100.
[[FIRCrashlytics crashlytics] setCustomValue:@(50) forKey:@"int_key"];

Aggiungi le coppie chiave/valore in blocco utilizzando il metodo setCustomKeysAndValues con un NSDictionary come unico parametro:

Swift

let keysAndValues = [
                 "string key" : "string value",
                 "string key 2" : "string value 2",
                 "boolean key" : true,
                 "boolean key 2" : false,
                 "float key" : 1.01,
                 "float key 2" : 2.02
                ] as [String : Any]

Crashlytics.crashlytics().setCustomKeysAndValues(keysAndValues)

Objective-C

NSDictionary *keysAndValues =
    @{@"string key" : @"string value",
      @"string key 2" : @"string value 2",
      @"boolean key" : @(YES),
      @"boolean key 2" : @(NO),
      @"float key" : @(1.01),
      @"float key 2" : @(2.02)};

[[FIRCrashlytics crashlytics] setCustomKeysAndValues: keysAndValues];

Aggiungere messaggi di log personalizzati

Per avere un contesto più ampio sugli eventi che precedono un arresto anomalo, puoi aggiungere alla tua app log Crashlytics personalizzati. Crashlytics associa i log ai dati sugli arresti anomali e li mostra nella pagina Crashlytics della console Firebase, nella scheda Log.

Nota: per evitare di rallentare l'app, Crashlytics limita i log a 64 kB ed elimina le voci di log precedenti quando i log di una sessione superano questo limite.

Swift

Utilizza log() o log(format:, arguments:) per individuare i problemi. Se vuoi ottenere un output del log utile con i messaggi, l'oggetto che passi a log() deve essere conforme alla proprietà CustomStringConvertible. log() restituisce la proprietà description che definisci per l'oggetto. Ad esempio:

Crashlytics.crashlytics().log("Higgs-Boson detected! Bailing out…, \(attributesDict)")

.log(format:, arguments:) formatta i valori restituiti dalla chiamata getVaList(). Ad esempio:

Crashlytics.crashlytics().log(format: "%@, %@", arguments: getVaList(["Higgs-Boson detected! Bailing out…", attributesDict]))

Per ulteriori dettagli su come utilizzare log() o log(format:, arguments:), consulta la Crashlytics documentazione di riferimento.

Objective-C

Utilizza log o logWithFormat per individuare i problemi. Tieni presente che se vuoi ottenere un output del log utile con i messaggi, l'oggetto che passi a uno dei metodi deve sostituire la proprietà di istanza description. Ad esempio:

[[FIRCrashlytics crashlytics] log:@"Simple string message"];

[[FIRCrashlytics crashlytics] logWithFormat:@"Higgs-Boson detected! Bailing out... %@", attributesDict];

[[FIRCrashlytics crashlytics] logWithFormat:@"Logging a variable argument list %@" arguments:va_list_arg];

Per ulteriori dettagli su come utilizzare log e logWithFormat, consulta la Crashlytics documentazione di riferimento.

Impostare gli identificatori utente

Per diagnosticare un problema, spesso è utile sapere quali utenti hanno riscontrato un determinato arresto anomalo. Crashlytics include un modo per identificare anonimamente gli utenti nei report sugli arresti anomali.

Per aggiungere gli ID utente ai report, assegna a ogni utente un identificatore univoco sotto forma di numero ID, token o valore sottoposta ad hashing:

Swift

Crashlytics.crashlytics().setUserID("123456789")

Objective-C

[[FIRCrashlytics crashlytics] setUserID:@"123456789"];

Se devi cancellare un identificatore utente dopo averlo impostato, reimposta il valore su una stringa vuota. L'eliminazione di un identificatore utente non comporta la rimozione dei recordCrashlytics esistenti. Se devi eliminare i record associati a un ID utente, contatta l'assistenza Firebase.

Segnalare eccezioni non fatali

Oltre a segnalare automaticamente gli arresti anomali dell'app, Crashlytics consente di registrare le eccezioni non fatali e di inviartele al successivo avvio dell'app.

Nota: Crashlytics memorizza solo le otto eccezioni più recenti in una determinata sessione dell'app. Se la tua app genera più di otto eccezioni in una sessione, le eccezioni precedenti vengono perse.

Puoi registrare le eccezioni non fatali registrando gli oggetti NSError con il metodo recordError. recordError acquisisce lo stack di chiamate del thread chiamando [NSThread callStackReturnAddresses].

Swift

Crashlytics.crashlytics().record(error: error)

Objective-C

[[FIRCrashlytics crashlytics] recordError:error];

Quando utilizzi il metodo recordError, è importante comprendere la struttura di NSError e il modo in cui Crashlytics utilizza i dati per raggruppare gli arresti anomali. L'uso scorretto del metodo recordError può causare un comportamento imprevedibile e potrebbe portare Crashlytics a limitare la generazione di report sugli errori registrati per la tua app.

Un oggetto NSError ha tre argomenti:

• domain: String
• code: Int
• userInfo: [AnyHashable : Any]? = nil

A differenza degli arresti anomali fatali, che vengono raggruppati tramite l'analisi della traccia dello stack, gli errori registrati vengono raggruppati per domain e code. Questa è una distinzione importante tra arresti anomali irreversibili ed errori registrati. Ad esempio:

Swift

let userInfo = [
  NSLocalizedDescriptionKey: NSLocalizedString("The request failed.", comment: ""),
  NSLocalizedFailureReasonErrorKey: NSLocalizedString("The response returned a 404.", comment: ""),
  NSLocalizedRecoverySuggestionErrorKey: NSLocalizedString("Does this page exist?", comment: ""),
  "ProductID": "123456",
  "View": "MainView"
]

let error = NSError.init(domain: NSCocoaErrorDomain,
                         code: -1001,
                         userInfo: userInfo)

Objective-C

NSDictionary *userInfo = @{
  NSLocalizedDescriptionKey: NSLocalizedString(@"The request failed.", nil),
  NSLocalizedFailureReasonErrorKey: NSLocalizedString(@"The response returned a 404.", nil),
  NSLocalizedRecoverySuggestionErrorKey: NSLocalizedString(@"Does this page exist?", nil),
  @"ProductID": @"123456",
  @"View": @"MainView",
};

NSError *error = [NSError errorWithDomain:NSCocoaErrorDomain
                                     code:-1001
                                 userInfo:userInfo];

Quando registri l'errore riportato sopra, viene creato un nuovo problema raggruppato per NSSomeErrorDomain e -1001. Gli altri errori registrati che utilizzano gli stessi valori di dominio e codice sono raggruppati nello stesso problema. I dati contenuti nell'oggetto userInfo vengono convertiti in coppie chiave-valore e visualizzati nella sezione chiavi/log di un singolo problema.

Attenzione: evita di utilizzare valori univoci, come ID utente, ID prodotto e timestamp, nei campi dominio e codice. L'utilizzo di valori univoci in questi campi comporta un'elevata cardinalità dei problemi e potrebbe comportare la necessità per Crashlytics di limitare la registrazione degli errori registrati nella tua app. I valori univoci devono invece essere aggiunti all'oggetto dizionario userInfo.

Log e chiavi personalizzate

Come per i report sugli arresti anomali, puoi incorporare log e chiavi personalizzate per aggiungere contesto al NSError. Tuttavia, esiste una differenza tra i log associati ai crash e quelli associati agli errori registrati. Quando si verifica un arresto anomalo e l'app viene riavviata, i log recuperati da Crashlytics dal disco sono quelli scritti fino al momento dell'arresto anomalo. Quando registri un NSError, l'app non si chiude immediatamente. Poiché Crashlytics invia il report sugli errori registrati solo al successivo avvio dell'app e deve limitare la quantità di spazio allocata per i log su disco, è possibile registrare un numero sufficiente di log dopo la registrazione di un NSError in modo che tutti i log pertinenti vengano ruotati entro il momento in cui Crashlytics invia il report dal dispositivo. Tieni presente questo equilibrio quando registri NSErrors e utilizzi i log e le chiavi personalizzate nella tua app.

Considerazioni sulle prestazioni

Tieni presente che la registrazione di un NSError può essere piuttosto costosa. Al momento della chiamata, Crashlytics acquisisce lo stack di chiamate del thread corrente utilizzando un processo chiamato scollegamento dello stack. Questo processo può richiedere un'elevata quantità di risorse della CPU e dell'I/O, in particolare su architetture che supportano lo scollegamento DWARF (arm64 e x86). Al termine dello scollegamento, le informazioni vengono scritte sul disco in modo sincrono. In questo modo si evita la perdita di dati se la riga successiva dovesse bloccarsi.

Sebbene sia sicuro chiamare questa API in un thread in background, ricorda che l'invio di questa chiamata a un'altra coda comporta la perdita del contesto della traccia dello stack corrente.

Che ne dici di NSExceptions?

Crashlytics non offre uno strumento per registrare e registrare direttamente le istanze NSException. In generale, le API Cocoa e Cocoa Touch non sono esenti da eccezioni. Ciò significa che l'uso di @catch può avere effetti collaterali indesiderati molto gravi nel processo, anche se utilizzato con estrema attenzione. Non devi mai utilizzare istruzioni @catch nel codice. Consulta la documentazione di Apple sull'argomento.

Personalizzare le tracce dello stack

Se la tua app viene eseguita in un ambiente non nativo (ad esempio C++ o Unity), puoi utilizzare l'API Exception Model per segnalare i metadati degli arresti anomali nel formato delle eccezioni native della tua app. Le eccezioni segnalate sono contrassegnate come non fatali.

Swift

var  ex = ExceptionModel(name:"FooException", reason:"There was a foo.")
ex.stackTrace = [
  StackFrame(symbol:"makeError", file:"handler.js", line:495),
  StackFrame(symbol:"then", file:"routes.js", line:102),
  StackFrame(symbol:"main", file:"app.js", line:12),
]

crashlytics.record(exceptionModel:ex)

Objective-C

FIRExceptionModel *model =
    [FIRExceptionModel exceptionModelWithName:@"FooException" reason:@"There was a foo."];
model.stackTrace = @[
  [FIRStackFrame stackFrameWithSymbol:@"makeError" file:@"handler.js" line:495],
  [FIRStackFrame stackFrameWithSymbol:@"then" file:@"routes.js" line:102],
  [FIRStackFrame stackFrameWithSymbol:@"main" file:@"app.js" line:12],
];

[[FIRCrashlytics crashlytics] recordExceptionModel:model];

I frame dello stack personalizzati possono essere inizializzati anche solo con gli indirizzi:

Swift

var  ex = ExceptionModel.init(name:"FooException", reason:"There was a foo.")
ex.stackTrace = [
  StackFrame(address:0xfa12123),
  StackFrame(address:12412412),
  StackFrame(address:194129124),
]

crashlytics.record(exceptionModel:ex)

Objective-C

FIRExceptionModel *model =
    [FIRExceptionModel exceptionModelWithName:@"FooException" reason:@"There was a foo."];
model.stackTrace = @[
  [FIRStackFrame stackFrameWithAddress:0xfa12123],
  [FIRStackFrame stackFrameWithAddress:12412412],
  [FIRStackFrame stackFrameWithAddress:194129124],
];


[[FIRCrashlytics crashlytics] recordExceptionModel:model];

Visualizzare i log dei breadcrumb

I log dei breadcrumb ti consentono di comprendere meglio le interazioni di un utente con la tua app che hanno portato a un arresto anomalo, a un evento non irreversibile o ANR. Questi log possono essere utili per provare a riprodurre e risolvere un problema.

I log breadcrumb sono basati su Google Analytics, quindi per ottenerli devi attivare Google Analytics per il tuo progetto Firebase e aggiungere l'SDK Firebase per Google Analytics alla tua app. Una volta soddisfatti questi requisiti, i log breadcrumb vengono inclusi automaticamente con i dati di un evento nella scheda Log quando visualizzi i dettagli di un problema.

L'SDK Analytics registra automaticamente l'evento screen_view che consente ai log dei breadcrumb di mostrare un elenco di schermate visualizzate prima dell'evento di arresto anomalo, non irreversibile o ANR. Un log dei breadcrumb screen_view contiene un parametro firebase_screen_class.

I log dei breadcrumb vengono compilati anche con eventuali eventi personalizzati registrati manualmente all'interno della sessione dell'utente, inclusi i dati dei parametri dell'evento. Questi dati possono essere utili per mostrare una serie di azioni utente che hanno portato a un arresto anomalo, a un evento non irreversibile o ANR.

Tieni presente che puoi controllare la raccolta e l'utilizzo dei dati Google Analytics, che includono i dati che compilano i log dei breadcrumb.

Attivare i report di attivazione

Per impostazione predefinita, Crashlytics raccoglie automaticamente i report sugli arresti anomali per tutti gli utenti della tua app. Per consentire agli utenti di avere maggiore controllo sui dati che inviano, puoi attivare i report per i quali è necessario l'attivazione disattivando i report automatici e inviando i dati a Crashlytics solo quando scegli di farlo nel codice:

1. Disattiva la raccolta automatica aggiungendo una nuova chiave al file Info.plist:

   • Chiave: FirebaseCrashlyticsCollectionEnabled
   • Valore: false

2. Attiva la raccolta per utenti selezionati chiamando l'override della raccolta dei dati Crashlytics in fase di esecuzione. Il valore dell'override persiste per tutti i lanci dell'app, in modo che Crashlytics possa raccogliere automaticamente i report.

   Per disattivare i report automatici sugli arresti anomali, passa false come valore di override. Se impostato su false, il nuovo valore non viene applicato fino alla successiva esecuzione dell'app.

   Swift

   Crashlytics.crashlytics().setCrashlyticsCollectionEnabled(true)

   Objective-C

   [[FIRCrashlytics crashlytics] setCrashlyticsCollectionEnabled:YES];

Nota: se disattivi i report automatici, tieni presente quanto segue:

• Quando la raccolta dei dati è disattivata per un utente, Crashlytics memorizza le informazioni sugli arresti anomali localmente sul dispositivo. Se la raccolta dei dati viene attivata successivamente, tutte le informazioni sugli arresti anomali memorizzate sul dispositivo verranno inviate a Crashlytics per l'elaborazione.
• Quando attivi i report di attivazione, le informazioni sugli arresti anomali possono essere raccolte solo dagli utenti che hanno attivato esplicitamente la raccolta dei dati. Di conseguenza, l'accuratezza delle metriche relative agli arresti anomali (ad esempio utenti e sessioni prive di arresti anomali) sarà interessata, poiché Crashlytics dispone solo delle informazioni sugli arresti anomali di questi utenti che hanno attivato la funzionalità (anziché di tutti i tuoi utenti). Ciò significa che le metriche relative all'assenza di arresti anomali potrebbero essere meno affidabili e meno rappresentative della stabilità complessiva della tua app.

Gestire i dati di Insight sugli arresti anomali

Gli insight sugli arresti anomali ti aiutano a risolvere i problemi confrontando le analisi dello stack anonimizzate con quelle di altre app Firebase e ti comunicano se il problema fa parte di una tendenza più ampia. Per molti problemi, gli Approfondimenti sugli arresti anomali forniscono persino risorse per aiutarti a eseguire il debug dell'arresto anomalo.

Arresti anomali utilizza i dati aggregati sugli arresti anomali per identificare le tendenze comuni di stabilità. Se preferisci non condividere i dati della tua app, puoi disattivare gli Approfondimenti sugli arresti anomali dal menu Approfondimenti sugli arresti anomali nella parte superiore dell'elenco dei problemi Crashlytics nella console Firebase.

Nota: la disattivazione della condivisione dei dati comporta anche la rimozione degli approfondimenti sui tuoi problemi. L'applicazione delle modifiche può richiedere fino a 24 ore.