使用Crashlytics框架處理崩潰報告提供了錯誤的crashDate

我正在使用Crashlytics框架作爲iOS應用程序中的崩潰處理程序。使用Crashlytics框架處理崩潰報告提供了錯誤的crashDate

我需要發送崩潰的信息到我的服務器，並要做到這一點，我實現[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我在日誌中印在崩潰前不同crashDate存儲在CLSReport實例中。而且這個區別甚至更加奇怪，因爲crashDate早於realCrashDate。

真實的例子是：

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

它的bug在Crashlytics框架或它的東西，我不明白的權利。

來源

2016-02-15 Antondomashnev

委託方法名稱的'LastExecution'部分聽起來像是一個線索？換句話說，這是應用程序的*前*運行結束的崩潰。我真的在猜測，但是我知道，當我使用Crashlytics時，崩潰和崩潰報告之間存在延遲，並且在我重新啓動應用程序之前它不會顯示。 – trojanfoe

@trojanfoe你是對的，在下一次應用程序啓動時調用委託方法，可能我應該提到這一點。但是這仍然不是問題的答案，因爲日期必須是+/-幾個毫秒。但沒有那麼大的差別。 – Antondomashnev

我找到了原因。看起來像report.dateCreated不是返回崩潰的日期，而是返回應用程序會話開始的日期。

這真是令人困惑。我想Crashlytics團隊應該對它進行不同的命名，或者至少在界面文檔中提到它。

來源

2016-02-17 11:18:04 Antondomashnev

使用Crashlytics框架處理崩潰報告提供了錯誤的crashDate

回答

相關問題