Crashlyticsの正確なクラッシュ時間を確認してください

Question

私のアプリでは、Crashlyticsで報告された前回のクラッシュの正確な時刻を知りたいと思います。私は最後のセッションのクラッシュの時間を取得しようとしました

[CrashlyticsKit crash]; 

：私は、アプリが起動し、数分後に、ボタンを押すことで、アプリのクラッシュをシミュレートしてい

- (void) setUpCrashlytics 
{ 
    [[Fabric sharedSDK] setDebug:YES]; 
    [CrashlyticsKit setDebugMode:YES]; 
    [CrashlyticsKit setDelegate:self]; 
    [Fabric with:@[[Crashlytics class]]]; 
} 

：私はCrashlyticsこのように設定してい

#pragma mark - CrashlyticsDelegate Methods 
- (void) crashlyticsDidDetectReportForLastExecution:(CLSReport *) report completionHandler:(void (^)(BOOL)) completionHandler 
{ 
    BOOL isCrash = report.isCrash; //this is TRUE 

    NSDate *crashDate = report.crashedOnDate; 
    NSDate *reportCreation = report.dateCreated; 

    [[NSOperationQueue mainQueue] addOperationWithBlock:^{ 
     completionHandler(YES); 
    }]; 
} 

をしかし残念ながら、両方の日付は、クラッシュの時刻を表示されませんが、最後のセッションの起動時間：CrashlyticsDelegate使用。何か案は？ありがとう。

Answer 1

ここからクラッシュマティックスのマット。

残念ながら、私はそれをメモして撮影した:(バグを見つけた、と私はそれを見ますことを確認します。

私はまた、あなたがこれを使用する方法を知っていることが興味を持っています情報はそれまでに聞いたことのないユースケースです。

また、特定のデリゲートコールバックが問題であることを覚えておいてください。ヘッダードキュメントに示すように、そのメソッドのAPIではいくつかの信頼性機能を犠牲にする必要があります私はそれを避けることをお勧めします。なぜなら、クラッシュを正常に報告する能力は、それがなければずっと優れているからです。持っている他の方法では満足できない辛抱強く押す必要性。

また、このAPIはコメント内に持ち込まれているため、このAPIはメモリ不足の終了時には呼び出されません。それらは技術的にはクラッシュではなく、そうではないと報告されていません。私たちが使用するメカニズムはまったく異なり、以下のドキュメントに記載されています。https://docs.fabric.io/apple/crashlytics/OOMs.html我々はヒューリスティックを使用し、100％信頼できるとは言いません。しかし、それはかなり良いです。

ご希望の場合は、Googleのサポートフォーラム/メールでヒントをご覧ください。スタックオーバーフローが:)

更新監視することが困難である：

を私はそれが、今私がラドゥが達成しようとしているものを理解していることを、ここでは詳細は有用であろうと思いました。結論は、このデリゲートメソッドを使用して彼が望むものを達成することはできません、そして実際に状況を悪化させるだけです。

Crashlyticsが初期化されて（-[Fabric with:]コール中）、ディスク上のクラッシュを準備し、NSURLSessionのバックグラウンドアップロード機能にエンキューします。アップロード処理が別のクラッシュによって中断されないようにしたいからです。私の知る限り、これは私たちの実装に特有の機能です。私たちはこれを長年にわたって使用してきましたが、それは驚くほどうまく機能します。 Crashlyticsは基本的に、その後の起動時のクラッシュに起因する失敗の報告には影響されません。

は今、これが可能と同様に動作することを確認するために、我々は、打ち上げ時に同期この作品 をしなければなりません。したがって、バックグラウンドスレッドでCrashlytics/Fabricを起動したり、SDKの初期化と同時にバックグラウンドで作業したりすると、別の潜在的なクラッシュが発生する前に確実にこのプロセスを完了する能力に妥協することになります。

しかし、別の問題があります。デリゲートが設定されていて、このメソッドが実装されている場合は、を送信する前にレポートをエンキューすることができれば、APIの契約を尊重し、デリゲートに依頼する必要があります。より良いか悪いかに関わらず、このAPIはこれを同期して実行しません。それは

にそう別のクラッシュを行うにはあなたの許可を待っていることの損失を引き起こす可能性があるので、

• Crashlyticsレポートを送信しません：あなたはこのデリゲートメソッドを実装するときに、あなたは時間の大窓を開いています保留中のレポート

デリゲートが呼び出されてからコールバックされるまでの間に、レポートの送信に時間がかかりません。 SDKがあなたに許可を与えたことを知る前に、遅延を追加するだけです。

（このAPIは非常に問題があり、削除したいと考えていますが、下位互換性を保つためにこのAPIを使用する必要があります。このようなAPIは、レポートのエンキュー時に遅延が発生することはなく、これらの問題をすべて回避できる可能性があります。早期打ち上げクラッシュハンドリングを向上させる、私は次のことをお勧めします：

• バックグラウンドスレッド
上Crashlyticsを初期化することはありません
• アプリケーションが
• 唯一の例外は、本当にする必要があります。このデリゲートメソッド

を使用することはありませんん非常にまず最初に、理想的に、早くも発売中することができますようにCrashlyticsを初期化することを確認してください：

• ユーザーが直面しているクラッシュレポート権限のダイアログを実装しようとしています（これはこのユースケースのために設計されています）
• 責任を負う可能性のあるキャッシュデータを吹き飛ばしたい
• には他の分析メカニズムがあり、クラッシュをカウントしたい場合

Googleサポートにお問い合わせいただくこともお勧めします。欠落しているクラッシュは一般的です。 SDKの問題に起因する欠落したクラッシュは一般的ではなく、監視されており、われわれはSDK側とバックエンド側のコードを理解して最小限に抑えています。