使用 Crashlytics 框架处理崩溃报告提供了不正确的 crashDate答案

【问题标题】：Handling crash report with Crashlytics framework provided incorrect crashDate使用 Crashlytics 框架处理崩溃报告提供了不正确的 crashDate
【发布时间】：2016-02-15 14:55:40
【问题描述】：

我在可能的 iOS 应用程序中使用Crashlytics 框架作为崩溃处理程序。

我需要将崩溃信息发送到我的服务器，为此我实现了 [Crashlytics sharedInstance] 方法的委托调用

它提供了在您的应用程序启动时处理崩溃报告的方法，以决定它是否应该发送该崩溃报告。下面是这种方法的最简单实现：

- (void)crashlyticsDidDetectReportForLastExecution:(CLSReport *)report completionHandler:(void (^)(BOOL))completionHandler {
    NSDate *crashDate = report.dateCreated;
    //Do the logic
    completionHandler(YES);
}

为了测试一切是否按预期工作，我使用这些行模拟了崩溃

{
    ...
    NSDate *realCrashDate = [NSDate date];
    [[Crashlytics sharedInstance] crash];
}

然后我注意到我在崩溃前在日志中打印的realCrashDate 与存储在CLSReport 实例中的crashDate 不同。而且区别更奇怪，因为crashDate早于realCrashDate。

真实的例子是：

realCrashDate = 2016-02-15 14:36:21 +0000
crashDate = 2016-02-15 14:36:01 +0000

是Crashlytics 框架中的错误还是我理解不正确。

【问题讨论】：

委托方法名称的LastExecution 部分听起来像是一个线索？换句话说，结束应用程序上一次运行的崩溃是什么？我猜是真的，但我知道当我使用 Crashlytics 时崩溃和报告崩溃之间存在延迟，并且直到我重新启动应用程序才会出现。
@trojanfoe 你是对的，委托方法在下一次应用程序启动时被调用，也许我应该提到这一点。但这仍然不是问题的答案，因为日期必须是相同的 +/- 几毫秒。但差别不大。

标签： ios objective-c crashlytics twitter-fabric

【解决方案1】：

我找到了原因。似乎report.dateCreated 返回的不是崩溃日期，而是应用程序会话开始的日期。

这真是令人困惑。我猜 Crashlytics 团队应该以不同的方式命名它，或者至少在界面文档中提及它。

【讨论】：