如何获取冻结的 iOS 应用程序的错误报告？答案

【问题标题】：How to get error reports of a freezing iOS app?如何获取冻结的 iOS 应用程序的错误报告？
【发布时间】：2020-07-02 11:53:57
【问题描述】：

最近我的 iOS 应用程序出现问题，导致应用程序冻结。 UI 没有响应，用户必须终止并重新启动应用程序才能使其再次运行。

在 Google 的 Play Console 中，我看到诸如 ANR（“应用程序未响应”错误）之类的问题。

但不幸的是，在 Xcode 中我没有收到任何报告。 Crashlytics 也没有显示任何报告。

是否有可能通过类似于 Google Play 控制台中的 ANR 的堆栈跟踪获得某种报告？

请注意：

我知道是什么导致应用程序在这个特定问题中冻结，以及如何调试和修复它。我什么 want 是一个错误报告，以防在 QA 期间未发现问题，但它是发生在用户会话中。
冻结版本没有发布到 App Store，只是为了试飞。

【问题讨论】：

标签： ios swift xcode crashlytics

【解决方案1】：

UI 无响应的原因可能有多种原因：

其中一个原因可能是负载过高（RAM、交换空间用完）。为了检测这些场景（没有崩溃行为），您需要应用程序性能监控，例如使用Firebase。 Firebase 的优势在于您无需提示同意，因此您可以获得更多数据来检测挂起。 Xcode Organizer 可以提供Hang Rate metrics，但前提是您有足够多的用户同意共享他们的数据（Xcode 11 中的新功能）。
另一个原因可能是代码中的逻辑错误。例如，用户触发了在手动测试期间遗漏的意外应用程序流。在这些情况下，可能很难缩小范围，但可以通过事先手动用户测试来跟踪，例如TestFlight。您可以使用应用内反馈工具（用户向您发送电子邮件）收集有关问题的背景信息，或使用Instabug 获取屏幕截图和高级反馈。
另一个原因可能是死锁。例如，如果您使用DispatchGroup 或DispatchSemaphores 对网络请求进行排队并且请求超时，那么这也可能导致暂停UI 框架。我也会仔细查看您离开调度组的位置 - 所有可能的分支都应该有一个 dispatch_group_leave 声明以避免挂在 dispatch_group_wait 上。
您可以使用线程状态跟踪工具查看系统调用是否阻塞了您的主线程来调试此问题。经典的 iOS 开发建议是仅在主线程上执行 UI 更新，并将所有其他逻辑移至后台线程。这可能无法解决根本原因，但确实可以防止挂起。相同的逻辑适用于 Core Data 的获取、插入、删除和更新。在网络请求回调中也将 Core Data 操作移至后台线程。
如果您收到崩溃报告，可以很容易地在 Crashlytics 崩溃报告中诊断出 OOM 错误（例如，在 Insights 中出现）。堆损坏也可以从崩溃报告中推断出来，虽然对于相同的行为，元数据可能不同，但当您尝试重现错误时，它可能会指向一个屏幕或操作。
如果用户没有事先终止应用程序，Watchdog 无响应的应用程序崩溃可能会被截获并出现在崩溃报告中，但您提到用户终止了应用程序，因此这可能不可用。

iOS 应用没有直接等效的 ANR 错误报告，因为只有在检测到足够多的会话时才会汇总挂起率。您可以对应用会话 (ServiceNow) 进行屏幕录制，但我不建议这样做，因为它会影响隐私。

【讨论】：

感谢您的完整回答。我会试试 Firebase 性能监控。

【解决方案2】：

Crashlytics 无法发送由看门狗触发的异常终止。我已经针对 Jetsam 终端对此进行了研究。您将在控制台日志中看到它们。请参阅此链接以了解 iOS 生成的看门狗崩溃：Watchdog Unresponsive App。如果有办法监控主线程的排队操作执行时间过长，您可能会触发致命错误，即在看门狗终止应用程序之前触发致命错误。

【讨论】：

【解决方案3】：

对 MetricKit 做一些研究。它是 iOS 13 的新功能。有一个名为 MXHangDiagnostic 的类。您可以在您的应用中使用它来监控挂起情况并根据需要报告它们。

【讨论】：