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

Posted

技术标签:

【中文标题】使用 Crashlytics 框架处理崩溃报告提供了不正确的 crashDate【英文标题】:Handling crash report with Crashlytics framework provided incorrect 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 时崩溃和报告崩溃之间存在延迟,并且直到我重新启动应用程序才会出现。 @***foe 你是对的,委托方法在下一次应用程序启动时被调用,也许我应该提到这一点。但这仍然不是问题的答案,因为日期必须是相同的 +/- 几毫秒。但差别不大。 【参考方案1】:

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

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

【讨论】:

以上是关于使用 Crashlytics 框架处理崩溃报告提供了不正确的 crashDate的主要内容,如果未能解决你的问题,请参考以下文章

将 LogCat 日志添加到 Firebase Crashlytics

崩溃报告没有进入Crashlytics / fabric。显示警告:“看起来我们缺少dSYM来处理以下版本的崩溃。”

崩溃报告未进入 Crashlytics / fabric。显示警告:“看起来我们缺少 dSYM 来处理以下版本的崩溃。”

Crashlytics 没有向我的 Fabric 仪表板发送崩溃报告?

Crashlytics 没有向我的 Fabric 仪表板发送崩溃报告?

无法在 Crashlytics/fabric 中获取崩溃报告。显示错误:“看起来我们缺少 dSYM 来处理以下版本的崩溃。”