我们最近在我们的 生产环境 iOS应用程序中遇到了我们的核心数据堆栈问题，Fabric Crashlytics帮助我们解决了大部分问题 . 但是，我们怀疑即使在用户重新启动应用程序发送崩溃报告后，也不会报告所有崩溃 .
在应用程序进入 recurring crash loop on app launch 的情况下，Crashlytics可能不会报告发生的任何崩溃 . 来自Fabric的文档：
如果您的应用程序在启动时崩溃，则在后续启动时，我们将尝试在短时间内同步阻止主线程发送崩溃报告 .
上面的主线程阻塞永远不会发生，并且因为该应用程序在Crashlytics有机会发送报告之前再次崩溃;从未报告原始崩溃 .
@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {
var window: UIWindow?
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
Fabric.with([Crashlytics.self])
Crashlytics.sharedInstance().crash() // Mimics our CoreData stack crash.
return true
}
}
我们做错了吗？有没有办法配置Crashlytics来启用此功能？
请注意，我们尝试使用其他方法来崩溃应用程序（例如强制解包），测试时未附加调试器，Fabric和Crashlytics pod正确设置并且报告适用于不再发生的崩溃 .
1 回答
来自Fabric的Mike来自这里 . 鉴于崩溃发生时，init之后的行，几乎可以肯定我们的SDK没有足够的时间来完成初始化 . 发布时大多数应用程序崩溃发生在启动序列的后期，使我们的SDK有足够的时间进行初始化 .
在应用程序在Fabric中处于活动状态之前，不要故意导致崩溃，否则您可能会阻止应用程序在Fabric中激活 .