修复内向崩溃

几乎所有的iOS开发人员都已经发生了这种情况。 我们确实看到某些崩溃确实发生在“我的代码”区域之外，例如CFNetwork。

发生这种情况时，项目负责人经常会弹出一个问题：“计数是多少？”，如果不听，可能会出现这样的问题：“我们还有99.5％的崩溃率吗？”

“是？ 那么我们可以忽略它。 让我们专注于门票。”

这些崩溃最糟糕的部分是，我们不知道为什么会发生这种情况，最重要的是它发生在哪里。 我们只是空白。 堆栈跟踪没有显示与跟踪它们相关的任何内容。

在我早期的开发人员时代，我经常忽略了此类崩溃。 但是我认为，我们至少应该知道此类崩溃的根源。 也许这可以帮助我们追踪崩溃，或者，如果不是这样，则至少可以通过低估这种情况不会在应用程序的主要流程中弹出来了解其严重性。

因此，这就是我们在系统中跟踪此类崩溃的方式。 使用，

Crashlytics自定义键/日志

自定义键可帮助您获取导致崩溃的应用程序的特定状态。 您可以将任意键/值对与崩溃报告相关联，可以从Fabric仪表板直接查看。

记录一些有关导致崩溃的事件的上下文通常很有用。 Crashlytics提供了日志记录工具来简化此过程。 这些消息与崩溃数据相关联，如果您查看特定的崩溃，则这些消息在Fabric仪表板中可见。

我们保存一个像

  Crashlytics.sharedInstance（）。setObjectValue（“ value”，forKey：“ key”） 

和日志一样

  CLSLogv（“正在记录-％@，％@”，getVaList（[“ LogA”，“ LogB”]）） 

我们可以使用它们为崩溃添加更多细节。

在我们的系统中，我们有一个名为CrashTrackerController的父UIViewController ，我们的大多数视图控制器都从该子类继承而来。 从这一点出发，我们记录并保存自定义密钥

这就是其中一个日志的样子

这对我们来说确实很好。 现在，我们知道发生崩溃的控制器，通过查看日志，我们可以了解生成崩溃的最新流程。