使用 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 来处理以下版本的崩溃。”