我們可以在iOS上的後臺線程上引導Crashlytics嗎？

我們正在努力減少我們的iOS應用程序的冷啓動響應時間，我們注意到，Crashlytics可在50和150毫秒之間採取（對低端設備），這樣做是通過他們的API設置：我們可以在iOS上的後臺線程上引導Crashlytics嗎？

Fabric.with([Crashlytics.self])

這是指示在應用生命週期中儘可能早地運行。

有沒有人發現文檔或嘗試在成功的背景隊列中運行這段代碼？

邁克從面料這裏。如果你在後臺線程上初始化，你可能會遇到在啓動應用程序時丟失崩潰的風險，所以在技術上你可以，但是存在權衡。一般來說，在我的測試中，我看到30-60ms的初始值。

2017-10-18 01:08:23

如果你走這條路線，你可能要dispatch_wait爲它在應用程序的最終完成：didFinishLaunching：只是讓你不會錯過在app之後執行的代碼中的任意位崩潰初始化也是如此。但是，如果你這樣做的話，可能也不會贏。 –

這不是一個壞主意 - 我想我們可能會嘗試使用我們自己的基本崩潰記者在短暫的時間Crashlytics不是自舉的。 –

作爲一個頭腦，這將是有風險的，以及iOS只支持一個正在運行的未捕獲異常處理程序。 –

如果要實現CrashlyticsDelegate協議（特別是crashlyticsDidDetectReportForLastExecution回調），並設置自己作爲代表，那麼Crashlytics將上傳崩潰報告異步，所以你不會需要把初始化後臺線程：

只是實施這種委託方法將禁用所有形式的同步報告提交。這可能會在應用程序啓動的早期影響報告崩潰的可靠性。

2017-10-24 22:46:06

感謝您的建議 - 但我的延遲來自引導Crashlytics--而不是發送崩潰報告。在crashlytics初始化過程中不會調用此方法，除非之前發生崩潰。 –

回答