ios - 如何获取卡住的 iOS 应用程序的错误报告？

Question

最近我的 iOS 应用程序出现问题，导致应用程序卡住。 UI 没有响应，用户必须杀死并重新启动应用程序才能使其再次运行。
在 Google 的 Play Console 中，我看到了诸如 ANR(“应用程序无响应”错误)之类的问题。
但不幸的是，在 Xcode 中我没有收到任何报告。 Crashlytics 也没有显示任何报告。
是否有可能通过类似于 Google Play Console 中的 ANR 的堆栈跟踪以某种方式获得某种报告？
请注意:

我知道是什么导致应用程序在此特定问题中卡住，以及如何调试和修复它。我什么
想要是一个错误报告，以防在 QA 期间没有发现问题，但它是
发生在用户 session 中。

卡住版本没有发布到 App Store，只发布到
试飞。

Answer 1

用户界面无响应的原因可能有多种:

原因之一可能是高负载(耗尽 RAM、交换空间)。为了检测这些场景(没有崩溃行为)，您需要应用程序性能监控，例如使用 Firebase . Firebase 的优势在于您无需提示同意，因此您可以获得更多数据来检测挂起。 Xcode Organizer 可以提供 Hang Rate metrics但是，如果您有足够多的用户同意共享他们的数据(Xcode 11 中的新功能)。

另一个原因可能是由于代码中的逻辑错误。例如，用户触发了在手动测试期间遗漏的意外应用程序流。在这些情况下，缩小范围可能更难，但可以通过事先手动用户测试进行跟踪，例如 TestFlight .您可以使用应用内反馈工具(用户向您发送电子邮件)来收集有关问题的上下文或 Instabug用于屏幕截图和高级反馈。

另一个原因可能是因为死锁。如果您使用 DispatchGroup例如或 DispatchSemaphore s 将网络请求排队，然后请求超时，这也可能导致 UI 帧挂起。我也会仔细查看您离开调度组的位置 - 所有可能的分支都应该有 dispatch_group_leave避免卡在 dispatch_group_wait 上的声明.

您可以使用线程状态跟踪工具查看系统调用是否阻塞了主线程以调试此问题。经典的 iOS 开发建议是只在主线程上执行 UI 更新，并将所有其他逻辑移动到后台线程。这可能无法解决根本原因，但确实可以防止挂起。相同的逻辑适用于 Core Data 获取、插入、删除和更新。将核心数据操作也移动到网络请求回调中的后台线程。

如果您收到崩溃报告，则很容易在 Crashlytics 崩溃报告中诊断 OOM 错误(例如出现在 Insights 中)。堆损坏也可以从崩溃报告中推断出来，虽然相同行为的元数据可能不同，但当您尝试重现错误时，它可以将您指向屏幕或操作。

如果用户没有事先杀死应用程序，可以拦截看门狗无响应应用程序崩溃以出现在崩溃报告中，但您提到用户杀死了应用程序，因此这可能不可用。

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