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

iOS Android Unity

このガイドでは、Firebase Crashlytics SDK を使用してクラッシュ レポートをカスタマイズする方法を説明します。デフォルトでは、Crashlytics は自動的にアプリの全ユーザーを対象にクラッシュ レポートを収集します（自動クラッシュ レポートを無効にして、ユーザーに対してオプトイン レポートを有効にすることもできます）。Crashlytics には、カスタムキー、カスタムログ、ユーザー ID、検出された例外という、設定不要な 4 つのロギング メカニズムが用意されています。

カスタムキーを追加する

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

Key-Value ペアを設定するには、setCustomValue メソッドを使用します。次に例を示します。

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

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

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

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

既存のキーの値を変更するには、そのキーを呼び出して別の値を設定します。次に例を示します。

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

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

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

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

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

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

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

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

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

ユーザー ID を設定する

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

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

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

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

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

致命的でない例外を報告する

Crashlytics では自動的にアプリのクラッシュを報告するだけでなく、致命的でない例外を記録して、アプリの次回の起動時にユーザーに送信することもできます。

致命的でない例外を記録するには、recordError メソッドを使用して NSError オブジェクトを記録します。recordError は、[NSThread callStackReturnAddresses] を呼び出してスレッドのコールスタックをキャプチャします。

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

[[FIRCrashlytics crashlytics] recordError:error];

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

NSError オブジェクトには次の 3 つの引数があります。

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

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

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)

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

上記のエラーをログに記録する場合、NSSomeErrorDomain と -1001 を基準にグループ化される新しい問題が作成されます。以降にログに記録される、同じドメインとコードの値が使用されたエラーは、この問題に分類されます。userInfo オブジェクト内に格納されたデータは Key-Value ペアに変換され、各問題内の keys/logs セクションに表示されます。

ログとカスタムキー

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

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

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

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

NSExceptions について

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

スタック トレースをカスタマイズする

アプリをネイティブでない環境（C++、Unity など）で実行する場合、Exception Model API を使用すると、アプリのネイティブ例外フォーマットでクラッシュ メタデータを報告できます。報告される例外は、非致命的としてマークされます。

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

crashlytics.record(exceptionModel:ex)

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

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

デフォルトでは、Crashlytics は自動的にアプリの全ユーザーを対象にクラッシュ レポートを収集します。どのデータを送信するかをユーザーが細かく制御できるようにするには、選択したユーザーに対してのみ自動収集を無効にして Crashlytics を初期化し、それらのユーザーに対してオプトイン レポートを有効にします。

1. Info.plist ファイル内に新しいキーを追加して、自動収集を無効にします。

   • キー: FirebaseCrashlyticsCollectionEnabled
   • 値: false

2. 実行時に Crashlytics データ収集オーバーライドを呼び出して、選択したユーザーに対して収集を有効にします。オーバーライド値はアプリが再起動されても維持されるため、Crashlytics はそのアプリ インスタンスの以降の起動に関するレポートを自動的に収集できます。自動クラッシュ レポートを無効にするには、オーバーライド値として false を渡します。false に設定された場合、この新しい値はアプリが次回実行されるまで適用されません。

   Swift

   Crashlytics.crashlytics().setCrashlyticsCollectionEnabled(true)

   Objective-C

   [[FIRCrashlytics crashlytics] setCrashlyticsCollectionEnabled:YES];

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

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

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