在Crashlytics中查找确切的崩溃时间

在我的应用程序中，我想查找从前一个会话中发生崩溃的确切时间，通过Crashlytics报告。我设立Crashlytics这样：在Crashlytics中查找确切的崩溃时间

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

我按一个按钮模拟的应用程序崩溃，应用后几分钟内启动：

[CrashlyticsKit crash];

我试图让最后一次会议时坠毁使用CrashlyticsDelegate：

#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); 
    }]; 
}

但不幸的是，这两个日期都显示不死机时间，但最后一个会话启动时间。有任何想法吗？谢谢。

来源

2016-12-05 Otto Boy

您是否检查过“isCrash”是真的？有没有回溯？报告也会生成所谓的“内存不足”错误。 “所谓”，因为我不相信Crashlytics准确地检测到这100％（他们很难检测到）。某些类型的背景终端（特别是后台OoM）从不让程序运行代码，所以Crashlytics不能存储崩溃时间。通过故意强制崩溃来测试这个，看看'crashedOnDate'是否符合你的期望。 –

Crashlytics的Matt在这里 - 我们不会通过这种机制在iOS上检测到OOM。因此，在内存不足终止后，此回调将永远不会被调用。你是对的，他们很难做到。以下是我们的做法：https：//docs.fabric.io/apple/crashlytics/OOMs.html – Matt

马特在这里从Crashlytics。

不幸的是，你发现了一个错误:(我已经采取予以注意，我会确保它得到看着。

我也有兴趣知道你打算如何使用这算什么信息，这只是一个我以前没有听说过的用例

另外，请记住特定的代理回调是有问题的当我们在头文件中指出，该方法的API要求我们牺牲一些可靠性特性。我建议避免它，因为如果没有它，成功报告崩溃的能力会好得多。是的，我们计划添加一个新的只读API来避免这种折衷。现在，我只会推荐它有av不能满足任何其他方式的需要。

另外，由于它是在注释中提出的，所以此API将不会因内存不足而终止。这些技术上不是碰撞，也不是不报告。我们使用的机制完全不同，并在我们的文档中列出：https://docs.fabric.io/apple/crashlytics/OOMs.html。我们使用启发式方法，而不是（或声称）100％可靠。虽然这很好。

希望这会有所帮助 - 并打开我们的支持论坛/电子邮件寻求进一步的帮助。堆栈溢出是很难监控:)

更新：

我认为这将是非常有用的详细信息在这里，现在我明白了什么拉杜努力实现的目标。结果是使用这种委托方法无法实现他想要的，实际上只会使情况变得更糟。

目前Crashlytics已初始化（在-[Fabric with:]调用期间），SDK会准备磁盘上的所有崩溃并将其排入NSURLSession的后台上传工具。我们这样做是因为我们要确保我们的上传过程不会被另一次崩溃中断。据我所知，这是我们实施的独特功能，我们已经使用了它多年，并且它的工作非常好。 Crashlytics基本上不会因后来发布的崩溃而导致报告失败。

现在，为了确保它能够正常工作，我们必须在启动期间同步执行此项工作。因此，如果您在后台线程上启动Crashlytics/Fabric，或者在SDK初始化时同时执行后台工作，则会降低我们在另一个潜在崩溃发生之前可靠完成此过程的能力。

但是，还有一个问题。如果代表已设置，并且已实施此方法，则我们必须尊重API的合同，并询问代理是否可以让我们发送之前发送的。无论更好还是更糟，这个API也不会同步执行此操作。因为它在等待您的许可，这样做

另一个崩溃可能导致的损失

Crashlytics不会发送报告：所以，当你实现这个委托方法，您打开的时间，其中一大亮点待处理报告

在调用委托与调用回调之间的时间内，您没有给予更多时间发送报告。您只是在SDK知道您已授权我们发送它们之前添加延迟。我个人觉得这个API非常有问题，并且希望将其删除，但是为了向后兼容，我们需要保留它，这实际上是我的错，因为没有实现一个不允许委托的新API取消报告，这样的API不会被延迟排队报告，并且可以避免所有这些问题。有一天，我们会得到这个，我们终于可以弃用这个）

所以，提高早期推出的碰撞处理，我提出以下建议：

从来没有在后台线程初始化Crashlytics
确保在启动早，你可以，初始化Crashlytics理想的第一件事您的应用程序确实
从来不使用这个委托方法

唯一的例外真的应该是：

你正试图实现面向用户的崩溃报告的权限对话框（它是专为正是这种使用情况）
要打击，可能是造成死机
有一些其他的分析机制，你要计算崩溃

我还建议，再次联系我们的支持。缺少崩溃是常见的。缺少由SDK问题导致的崩溃并不常见，受到监视，并且我们有大量的SDK端和后端代码来理解和最小化它们。

来源

2016-12-05 23:09:31 Matt

它发生了几次，应用程序在启动后崩溃，Crashlytics没有成功发送崩溃报告，因为它过早终止。这就是为什么我使用该委托方法，我要显示并提醒几秒钟，以便将报告发送到服务器。此外，我只想过滤发生崩溃的事件，这就是为什么我需要崩溃时间，才能检测到发生后一秒内发生的崩溃事件。希望我清楚自己将要实现的目标。 –

伟大的建议马特。我会跟着他们。谢谢。 –

在Crashlytics中查找确切的崩溃时间

回答

相关问题