ios - 找出Crashlytics中的确切崩溃时间

在我的应用中，我想找出通过Crashlytics报告的上一次 session 崩溃的确切时间。我是这样设置Crashlytics的:

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

应用启动后几分钟，我通过按一个按钮来模拟应用崩溃:

[CrashlyticsKit crash];

我试图使用CrashlyticsDelegate来获取上次 session 的崩溃时间:

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

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

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

但不幸的是，这两个日期都没有显示崩溃时间，而是上一次 session 启动时间。有任何想法吗？谢谢。

---

Best Answer-推荐答案

Matt来自Crashlytics。

不幸的是，您发现了一个错误我已注意到它，并且我将确保对其进行检查。

我也想知道您打算如何使用此信息。这只是我以前从未听说过的用例。

另外，请记住，特定的委托回调是有问题的。正如我们在标题文档中指出的那样，该方法的API需要我们牺牲一些可靠性功能。我建议避免使用它，因为没有它，我们成功报告崩溃的能力会更好。是的，我们确实计划添加新的只读API来避免这种折衷。目前，仅当您有迫切需要而无法用其他方法满足的情况时，我才建议您这样做。

另外，由于它是在注释中显示的-永远不会为内存不足终止而调用此API。从技术上讲，这些不是崩溃，也没有这样的报告。我们使用的机制是完全不同的，并在此处的文档https://docs.fabric.io/apple/crashlytics/OOMs.html中进行了概述。我们使用试探法，并非(也不声称)是100％可靠的。很好。

希望这对您有所帮助-并访问我们的支持论坛/电子邮件以获取更多帮助。堆栈溢出更难监控

更新:

既然我了解了Radu想要达到的目标，我认为这里有用的更多信息。结果是使用此委托方法无法实现他想要的结果，实际上只会使情况变得更糟。

在初始化Crashlytics时(在-[Fabric with:]调用过程中)，SDK将磁盘上的所有崩溃准备并排队到NSURLSession的后台上传工具中。这样做是因为我们要确保我们的上传过程不会因其他崩溃而中断。据我所知，这是我们实施所独有的功能，我们已经使用了多年，而且效果惊人。 Crashlytics基本上不会报告由于后续启动而导致的崩溃而导致的失败。

现在，为了确保它能尽可能好地工作，我们必须在启动过程中同步，和ot。因此，如果您在后台线程上启动Crashlytics / Fabric，或者在初始化SDK的同时进行后台工作，则会损害我们可靠地完成此过程的能力，避免再次发生潜在的崩溃。

但是，还有另一个问题。如果设置了委托并实现了此方法，则我们必须遵守API的合同，并询问委托是否可以在发送之前将报告放入队列。不管是好是坏，此API也不同步执行此操作。因此，当实现此委托方法时，您将打开一个大的时间窗，其中:

Crashlytics将不发送报告，因为它正在等待您的允许。

另一个崩溃可能导致挂起的报告

丢失

在调用委托和调用回调之间的时间内，您不会花更多时间发送报告。您只是在添加延迟之前，SDK才知道您已准许我们发送它们。

(就我个人而言，我发现此API非常有问题，并希望将其删除。但是，为了保持向后兼容性，我们需要对其进行保留。这是我的错，因为我没有实现不允许委托人取消报告的新API。这样的API不会延迟入队报告的时间，并且可以避免所有这些问题。总有一天，我们将拥有该API，最后可以弃用此API。)

因此，为了改进早期启动的崩溃处理，我建议以下内容:

永远不会在后台线程

上初始化Crashlytics

确保尽早在启动时初始化Crashlytics，理想情况下，应用程序要做的第一件事

永远不要使用此委托方法

唯一的例外应该确实是:

您正在尝试实现面向用户的崩溃报告权限对话框(正是为此用例而设计的)

希望删除敏感的高速缓存数据，这些数据可能是崩溃的原因

还有一些其他分析机制，您想计算崩溃

我也建议再次与我们的支持人员联系。丢失的崩溃很常见。由SDK问题引起的丢失崩溃很少见，受到监视，并且我们有大量的SDK端和后端端代码可以理解并最小化它们。

关于ios - 找出Crashlytics中的确切崩溃时间，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40975846/