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

iOS

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

   Objective-C

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

   Swift

   Fabric.with([Crashlytics.self])

android

1. AndroidManifest.xml ファイル内で meta-data タグを使用して自動収集を無効にします。

   <meta-data
       android:name="firebase_crashlytics_collection_enabled"
       android:value="false" />
   AndroidManifest.xml
   

2. アプリのいずれかのアクティビティから Crashlytics を初期化して、選択されたユーザーに対して収集を有効にします。

   Fabric.with(this, new Crashlytics());
   MainActivity.java
   

iOS

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

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

android

Android では、Crashlytics.log が問題の特定に役立ちます。

Crashlytics.log では、Log.println() を指定してログをクラッシュ レポートに書き込むか、単に次のクラッシュ レポートに書き込むことができます。

• クラッシュ レポートと Log.println:

  Crashlytics.log(Log.DEBUG, "tag", "message");
  MainActivity.java

• クラッシュ レポートのみ:

  Crashlytics.log("message");
  MainActivity.java

iOS

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

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

[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")

android

キーを設定するには 5 つの方法があります。設定方法によって、処理するデータ型は異なります。

Crashlytics.setString(key, "foo" /* string value */);

Crashlytics.setBool(key, true /* boolean value */);

Crashlytics.setDouble(key, 1.0 /* double value */);

Crashlytics.setFloat(key, 1.0f /* float value */);

Crashlytics.setInt(key, 1 /* int value */);
MainActivity.java

次のように、キーを再設定するとその値が更新されます。

Crashlytics.setInt("current_level", 3);
Crashlytics.setString("last_UI_action", "logged_in");
MainActivity.java

iOS

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

[CrashlyticsKit setUserIdentifier:@"123456789"];

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

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

android

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

Crashlytics.setUserIdentifier("user123456789");
MainActivity.java

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

iOS

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

[CrashlyticsKit recordError:error];

Crashlytics.sharedInstance().recordError(error)

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

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

スタック トレース分析によってグループ化される致命的なクラッシュとは異なり、ログに記録されるエラーは 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 のドキュメントをご覧ください。

android

Android では、これは、アプリの catch ブロックでキャッチされた例外をログに記録できることを意味します。

try {
    methodThatThrows();
} catch (Exception e) {
    Crashlytics.logException(e);
    // handle your exception here
}
MainActivity.java

ログに記録された例外は、いずれも Firebase コンソースでは非致命的な問題として表示されます。問題の概要には、クラッシュの場合に通常表示されるすべての状態情報に加え、Android バージョンおよびハードウェア端末ごとの内訳が示されます。

Crashlytics は専用のバックグラウンド スレッドで例外を処理するため、アプリのパフォーマンスに対する影響は最小限です。ユーザーのネットワーク トラフィックを削減するために、Crashlytics はログに記録された例外を 1 回の送信分にまとめて、アプリの次の起動時に送信します。