在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中查找確切的崩潰時間

回答

相關問題