Firebase Crashlytics のクラッシュ レポートのカスタマイズ

iOS Android Unity

Firebase Crashlytics を動作させるためにユーザー側で行う設定はほとんどありません。SDK を追加するとすぐに、Crashlytics はクラッシュ レポートを Firebase コンソールに送信するようになります。

Firebase Crashlytics には、クラッシュ レポートを詳細に分析するために、カスタムキー、カスタムログ、ユーザー ID、検出された例外という、設定が不要な 4 つのロギング メカニズムが用意されています。

カスタムキーを追加する

カスタムキーを使用して、クラッシュにつながったアプリの特定の状態を把握できます。任意の Key-Value ペアをクラッシュ レポートに関連付けて、Firebase コンソールでそれらのペアを表示できます。

[CrashlyticsKit setObjectValue:forKey:] または関連するいずれかのメソッドで開始します。

- (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;

場合によっては、既存の Key-Value の変更が必要です。その場合、次の例のように同じキーを、値を置き換えて呼び出します。

[CrashlyticsKit setIntValue:3 forKey:@"current_level"];
[CrashlyticsKit setObjectValue:@"logged_in" forKey:@"last_UI_action"];

Crashlytics.sharedInstance().setIntValue(42, forKey: "MeaningOfLife")
Crashlytics.sharedInstance().setObjectValue("Test value", forKey: "last_UI_action")

カスタム ログメッセージを追加する

クラッシュにつながったイベントのコンテキストをさらに詳細に把握するには、カスタム Crashlytics ログをアプリに追加します。Crashlytics はログをクラッシュ データに関連付けて、Firebase コンソールで表示できるようにします。

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

func write(string: String) {
    CLSLogv("%@", getVaList([string]))
}

ユーザー ID を設定する

問題を診断する際には、多くの場合、特定のクラッシュがどのユーザーで発生したかを把握すると役立ちます。Crashlytics には、クラッシュ レポート内でユーザーを匿名で識別する手段が用意されています。

レポートにユーザー ID を追加するには、各ユーザーに ID 番号、トークン、またはハッシュ値の形で一意の ID を割り当てます。

[CrashlyticsKit setUserIdentifier:@"123456789"];

Crashlytics.sharedInstance().setUserIdentifier("123456789")

ユーザー ID を設定後にクリアする必要が生じた場合は、ID の値を空白の文字列にリセットします。ユーザー ID を作成しても、既存の Crashlytics レコードが削除されることはありません。ユーザー ID に関連付けられたレコードを削除する必要がある場合は、Firebase サポートにお問い合わせください。

致命的でない例外をログに記録する

Crashlytics では自動的にアプリのクラッシュを報告するだけでなく、致命的でない例外をユーザーがログに記録できるようになっています。

iOS で非致命的な例外をログに記録するには、NSError オブジェクトを記録します。Crashlytics はこのオブジェクトを、クラッシュと同様に報告およびグループ化します。

[CrashlyticsKit recordError:error];

Crashlytics.sharedInstance().recordError(error)

recordError メソッドを使用する場合、NSError の構造と、このデータを使用して Crashlytics がどのようにクラッシュをグループ化するかを理解していることが重要です。recordError メソッドを誤った方法で使用すると、予測不可能な動作が発生し、アプリについてログに記録されたエラーの報告を Crashlytics が制限する必要が生じる可能性があります。

NSError オブジェクトには、domain: String、code: Int、userInfo: [AnyHashable : Any]? = nil の 3 つの引数があります。

スタック トレース分析によってグループ化される致命的なクラッシュとは異なり、ログに記録されるエラーは NSError の domain と code を基準にグループ化されます。これは、致命的なクラッシュとログに記録されるエラーとの重要な違いです。たとえば、次のエラーをログに記録するとします。

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];

これにより、NSSomeErrorDomain と -1001 を基準にグループ化される新しい問題が作成されます。以降にログに記録される、同じドメインとコードの値が使用されているエラーは、この問題に分類されます。

userInfo オブジェクト内に格納されたデータは Key-Value ペアに変換され、各問題内の keys/logs セクションに表示されます。

ログとカスタムキー

クラッシュ レポートと同様に、ログとカスタムキーを埋め込んで NSError にコンテキストを追加することができます。ただし、クラッシュに関連付けられるログと、ログに記録されるエラーに関連付けられるログには違いがあります。クラッシュが発生してアプリが再起動された時点で Crashlytics がディスクから取得するログは、クラッシュが発生する直前までに書き込まれたログです。NSError をログに記録した場合、アプリが直ちに終了することはありません。Crashlytics はアプリが次に起動されるまでログに記録されたエラーのレポートを送信せず、また、Crashlytics はディスク上でログに割り当てるスペースの量を制限しなければならないため、NSError が記録された後、十分な数のログが記録され、Crashlytics が端末からレポートを送信するときには、関連するすべてのログがローテーションされクリアされている可能性があります。アプリで NSErrors をログに記録し、CLSLog とカスタムキーを使用する場合は、このバランスに注意してください。

パフォーマンスに関する注意事項

NSError のロギングでは、コストがかなり高くなる場合があるので注意してください。Crashlytics を呼び出した時点で、Crashlytics はスタックの巻き戻しと呼ばれるプロセスによって現行スレッドのコールスタックをキャプチャします。このプロセスでは CPU と I/O の使用量が高まります。特に、DWARF 巻き戻しをサポートするアーキテクチャ（arm64 および x86）で顕著です。巻き戻しが完了した後、情報が同期的にディスクに書き込まれます。これにより、次の行でクラッシュが発生した場合のデータ損失を防ぎます。

この API 呼び出しはバックグラウンド スレッドで行っても差し支えありませんが、この呼び出しを別のキューにディスパッチすると、現在のスタック トレースのコンテキストが失われることに注意してください。

NSExceptions とは

Crashlytics には、NSException インスタンスを直接ロギング / 記録する機能がありません。一般に、Cocoa API と Cocoa Touch API は例外セーフではありません。つまり、@catch を使用すると、かなり慎重を期したとしても、プロセスに非常に深刻な想定外の副次作用がもたらされる可能性があります。コードでは決して @catch ステートメントを使用しないでください。このトピックについては、Apple のドキュメントをご覧ください。

オプトイン レポートを有効にする

デフォルトでは、Firebase Crashlytics は自動的にアプリの全ユーザーを対象にクラッシュ レポートを収集します。どのデータを送信するかをユーザーが細かく制御できるようにするには、デフォルトの代わりにオプトイン レポートを有効にします。

オプトイン レポートを有効にするには、自動収集を無効にして、オプトイン ユーザーに対してのみ Crashlytics を初期化する必要があります。

1. Info.plist ファイル内の新しいキーで自動初期化を無効にします。
   • キー: firebase_crashlytics_collection_enabled
   • 値: false
2. Crashlytics を実行時に初期化して、選択されたユーザーに対して収集を有効にします。

   Objective-C

   [Fabric with:@[[Crashlytics class]]];

   Swift

   Fabric.with([Crashlytics.self])

クラッシュ分析データを管理する

クラッシュ分析では、匿名化されたスタック トレースと他の Firebase アプリのトレースを比較して、発生した問題がより大きい傾向の一部であるかどうかが通知されるので、問題の解決に役立ちます。また、多くの問題について、クラッシュのデバッグに役立つリソースも提供されます。

クラッシュ分析は、集計されたクラッシュ データを使用して、一般的な安定性の傾向を特定します。 アプリのデータを共有しない場合は、Firebase コンソールの Crashlytics 問題リストの最上部にある [クラッシュ分析情報の設定] メニューからクラッシュ分析を無効にできます。