Google is committed to advancing racial equity for Black communities. See how.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Personnalisez vos rapports d'incidents Firebase Crashlytics

Firebase Crashlytics peut fonctionner avec très peu de configuration de votre part. Dès que vous ajoutez le SDK, Crashlytics se met au travail en envoyant des rapports de plantage à la console Firebase .

Pour vous donner plus d'informations sur les rapports d'erreur, Firebase Crashlytics fournit quatre mécanismes de journalisation prêts à l'emploi: clés personnalisées, journaux personnalisés , identifiants utilisateur et exceptions interceptées .

Ajouter des clés personnalisées

Les clés personnalisées vous aident à connaître l'état spécifique de votre application menant à un plantage. Vous pouvez associer des paires clé / valeur arbitraires à vos rapports d'incident et les consulter dans la console Firebase .

Commencez par [CrashlyticsKit setObjectValue:forKey:] ou l'une des méthodes associées:

- (void)setObjectValue:(id)value forKey:(NSString *)key;

// calls -description on value, perfect for NSStrings!
- (void)setIntValue:(int)value forKey:(NSString *)key;

- (void)setBoolValue:(BOOL)value forKey:(NSString *)key;

- (void)setFloatValue:(float)value forKey:(NSString *)key;

Parfois, vous devez modifier la valeur de clé existante. Appelez la même clé, mais remplacez la valeur, par exemple:

Objectif c
[CrashlyticsKit setIntValue:3 forKey:@"current_level"];
[CrashlyticsKit setObjectValue:@"logged_in" forKey:@"last_UI_action"];
Rapide
Crashlytics.sharedInstance().setIntValue(42, forKey: "MeaningOfLife")
Crashlytics.sharedInstance().setObjectValue("Test value", forKey: "last_UI_action")

Ajouter des messages de journal personnalisés

Pour vous donner plus de contexte pour les événements menant à un crash, vous pouvez ajouter des journaux Crashlytics personnalisés à votre application. Crashlytics associe les journaux à vos données de plantage et les rend visibles dans la console Firebase .

Objectif c

En Objective-C, utilisez CLS_LOG pour identifier les problèmes. Il inclut automatiquement des informations sur la classe Objective-C, la méthode et le numéro de ligne associés au journal.

CLS_LOG comportement de CLS_LOG change selon qu'il s'agit d'une journalisation pour un débogage ou une version de version:

  • Débogage des builds: CLS_LOG passe par NSLog afin que vous puissiez voir la sortie dans Xcode et sur l'appareil ou le simulateur.
  • CLS_LOG versions: pour améliorer les performances, CLS_LOG taire toutes les autres sorties et ne passe pas par NSLog .

Utilisez CLS_LOG(format, ...) pour vous connecter avec CLS_LOG . Par exemple:

CLS_LOG(@"Higgs-Boson detected! Bailing out... %@", attributesDict);

Parcourez le fichier d'en-tête Crashlytics/Crashlytics.h pour plus de détails sur l'utilisation de CLS_LOG .

Rapide

Dans Swift, utilisez CLSLogv ou CLSNSLogv pour identifier les problèmes.

Il y a deux choses à garder à l'esprit lors de la journalisation avec CLSLogv et CLSNSLogv :

  • Votre argument de format doit être une chaîne constante au moment de la compilation. Ceci est appliqué par le compilateur en Objective-C, mais cette protection est actuellement perdue lors du pontage vers Swift.
  • Stockez les valeurs du journal dans un tableau et appelez getVaList sur ce tableau pour les récupérer.

Par exemple:

func write(string: String) {
    CLSLogv("%@", getVaList([string]))
}
L'interpolation de chaîne Swift n'entraînera pas une chaîne constante au moment de la compilation. Tout comme avec printf et NSLog, l'utilisation d'une chaîne non constante avec CLSLog peut entraîner un plantage.

Avancée

Pour plus de contrôle, vous pouvez exploiter directement CLSLog(format, ...) et CLSNSLog(format, ...) . Ce dernier passe par NSLog afin que vous puissiez voir la sortie dans Xcode ou sur l'appareil ou le simulateur. CLSLog(format, ...) et CLSNSLog(format, ...) sont thread-safe. CLSLog est destiné à CLSLog les informations importantes pour résoudre les plantages. Il ne doit pas être utilisé pour suivre les événements in-app.

Définir les identifiants utilisateur

Pour diagnostiquer un problème, il est souvent utile de savoir lequel de vos utilisateurs a connu un crash donné. Crashlytics inclut un moyen d'identifier de manière anonyme les utilisateurs dans vos rapports d'erreur.

Pour ajouter des ID utilisateur à vos rapports, attribuez à chaque utilisateur un identifiant unique sous la forme d'un numéro d'identification, d'un jeton ou d'une valeur hachée:

Objectif c
[CrashlyticsKit setUserIdentifier:@"123456789"];
Rapide
Crashlytics.sharedInstance().setUserIdentifier("123456789")

Si vous devez effacer un identifiant utilisateur après l'avoir défini, réinitialisez la valeur sur une chaîne vide. La suppression d'un identifiant utilisateur ne supprime pas les enregistrements Crashlytics existants. Si vous devez supprimer des enregistrements associés à un ID utilisateur, contactez le support Firebase .

Enregistrer les exceptions non fatales

En plus de signaler automatiquement les plantages de votre application, Crashlytics vous permet de consigner les exceptions non fatales.

Sur iOS, vous faites cela en enregistrant des objets NSError , que Crashlytics rapporte et regroupe un peu comme des plantages:

Objectif c
[CrashlyticsKit recordError:error];
Rapide
Crashlytics.sharedInstance().recordError(error)

Lorsque vous utilisez la méthode recordError , il est important de comprendre la structure NSError et la manière dont Crashlytics utilise les données pour regrouper les plantages. Une utilisation incorrecte de la méthode recordError peut entraîner un comportement imprévisible et peut obliger Crashlytics à limiter le signalement des erreurs enregistrées pour votre application.

Un objet NSError a trois arguments: domain: String , code: Int et userInfo: [AnyHashable : Any]? = nil

Contrairement aux plantages fatals, qui sont regroupés via l'analyse de trace de pile, les erreurs enregistrées sont regroupées par domain et code NSError. Il s'agit d'une distinction importante entre les plantages fatals et les erreurs consignées. Par exemple, consigner une erreur telle que:

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";
    UserID: @"Jane Smith"
};

NSError *error = [NSError domain:NSSomeErrorDomain
                          code:-1001
                          userInfo:userInfo];

Crée un nouveau problème regroupé par NSSomeErrorDomain et -1001 . Les erreurs consignées supplémentaires qui utilisent le même domaine et les mêmes valeurs de code seront regroupées sous ce problème.

Évitez d'utiliser des valeurs uniques, telles que l'ID utilisateur, l'ID de produit et les horodatages dans les champs de domaine et de code. L'utilisation de valeurs uniques dans ces champs entraîne une cardinalité élevée de problèmes et peut obliger Crashlytics à limiter le signalement des erreurs enregistrées dans votre application. Des valeurs uniques doivent à la place être ajoutées à l'objet de dictionnaire userInfo.

Les données contenues dans l'objet userInfo sont converties en paires clé-valeur et affichées dans la section clés / journaux d'un problème individuel.

Crashlytics ne stocke que les 8 exceptions les plus récentes dans une session d'application donnée. Si votre application lève plus de 8 exceptions dans une session, les anciennes exceptions sont perdues.

Journaux et clés personnalisées

Tout comme les rapports d'erreur, vous pouvez incorporer des journaux et des clés personnalisées pour ajouter du contexte à NSError. Cependant, il existe une différence entre les journaux attachés aux plantages et les erreurs consignées. Lorsqu'un crash se produit et que l'application est relancée, les journaux que Crashlytics récupère sur le disque sont ceux qui ont été écrits jusqu'au moment du crash. Lorsque vous enregistrez une erreur NSError, l'application ne se termine pas immédiatement. Étant donné que Crashlytics n'envoie le rapport d'erreur journalisé qu'au prochain lancement de l'application et que Crashlytics doit limiter la quantité d'espace allouée aux journaux sur le disque, il est possible d'enregistrer suffisamment après qu'une erreur NSError est enregistrée pour que tous les journaux pertinents soient tournés par le heure à laquelle Crashlytics envoie le rapport depuis l'appareil. Gardez cet équilibre à l'esprit lors de la journalisation de NSErrors et de l'utilisation de CLSLog et de clés personnalisées dans votre application.

Considérations relatives aux performances

Gardez à l'esprit que la journalisation d'une NSError peut être assez coûteuse. Au moment où vous effectuez l'appel, Crashlytics capture la pile d'appels du thread actuel à l'aide d'un processus appelé déroulement de pile. Ce processus peut être gourmand en CPU et en E / S, en particulier sur les architectures prenant en charge le déroulement DWARF (arm64 et x86). Une fois le déroulement terminé, les informations sont écrites sur le disque de manière synchrone. Cela évite la perte de données si la ligne suivante tombe en panne.

Bien qu'il soit sûr d'appeler cette API sur un thread d'arrière-plan, n'oubliez pas que la distribution de cet appel à une autre file d'attente perdra le contexte de la trace de pile actuelle.

Qu'en est-il de NSExceptions?

Crashlytics ne propose pas de fonction de journalisation / enregistrement des instances NSException directement. De manière générale, les API Cocoa et Cocoa Touch ne sont pas protégées contre les exceptions. Cela signifie que l'utilisation de @catch peut avoir des effets secondaires involontaires très graves dans votre processus, même lorsqu'il est utilisé avec un soin extrême. Vous ne devez jamais utiliser d'instructions @catch dans votre code. Veuillez vous référer à la documentation Apple sur le sujet.

Activer les rapports d'activation

Par défaut, Firebase Crashlytics collecte automatiquement les rapports d'erreur pour tous les utilisateurs de votre application. Pour donner aux utilisateurs plus de contrôle sur les données qu'ils envoient, vous pouvez activer la création de rapports d'activation à la place.

Pour ce faire, vous devez désactiver la collecte automatique et initialiser Crashlytics uniquement pour les utilisateurs opt-in.

  1. Désactivez la collecte automatique avec une nouvelle clé vers votre fichier Info.plist :
    • Clé: firebase_crashlytics_collection_enabled
    • Valeur: false
  2. Activez la collecte pour les utilisateurs sélectionnés en initialisant Crashlytics au moment de l'exécution:
    Objectif c
    [Fabric with:@[[Crashlytics class]]];
    Rapide
    Fabric.with([Crashlytics.self])

Gérer les données Crash Insights

Crash Insights vous aide à résoudre les problèmes en comparant vos traces de pile anonymisées aux traces d'autres applications Firebase et en vous indiquant si votre problème fait partie d'une tendance plus large. Pour de nombreux problèmes, Crash Insights fournit même des ressources pour vous aider à déboguer le plantage.

Crash Insights utilise des données d'accident agrégées pour identifier les tendances de stabilité communes. Si vous préférez ne pas partager les données de votre application, vous pouvez désactiver Crash Insights dans le menu Crash Insights en haut de votre liste de problèmes Crashlytics dans la console Firebase .