ios - 避免致命车祸

Question

我已经调试了一个应用程序一段时间，并准备将其上传到应用程序商店。然而，我仍然偶尔会遇到难以复制或调试的崩溃——例如以奇怪的顺序按下按钮时。如果我写下这些序列，我可以进行调试，但当我没有写下来时不可避免地会发生这种情况，并且这些序列可能很难复制。

我知道我需要今天就到此为止，并将 future 的错误修复留给下一个版本。我已经删除了测试中的所有 abort() 语句。然而，有时我会遇到崩溃，而不是让您关闭应用程序并重新打开，而是导致在不重新安装的情况下无法打开应用程序。例如，这刚刚发生，带有

'NSGenericException', reason: '*** Collection <__NSCFSet: 0x174a41b90> was mutated while being enumerated.'

这是由于在后台同步到云期间切换 VC 造成的。

我可以忍受只需要重新打开的崩溃，但不能忍受导致应用程序无法使用的崩溃。是否有针对崩溃类型的指导方针来帮助您关注真正致命的崩溃？

或者您可以采取什么措施来防止应用程序变砖而崩溃？

Answer 1

你应该解决这个问题。由于您有包含该错误消息的崩溃日志，因此您知道哪种方法可能会引发问题，因此即使问题表现不一致和/或以多种方式表现出来，您也可以在修复它方面取得良好的开端。

但是偶尔的崩溃对您来说似乎并没有太大的不便，但这是获得一星级评论和不满意客户的最快方法。我怀疑您很快就会后悔分发一个已知的、容易重现崩溃的应用程序。

但是，一些观察结果:

1. 听起来您的后台更新进程正在改变主线程使用的模型对象。

   • 如果可能的话，我建议小心不要在后台线程中更改任何模型对象，而是填充局部变量，当您准备好相应地更新 UI 时，分派(dispatch)两者模型更新和UI刷新到主线程。

   • 如果由于某种原因无法做到这一点，则必须使用某种机制(例如锁、GCD串行队列、读写器模型等)来同步模型更新的所有交互。这是稍微复杂的方法，但是可以做到。

2. 我建议暂时编辑目标的“方案”并打开线程清理程序:

   

   它可能会帮助您识别并更轻松地重现此类问题。您越容易重现问题，就越容易解决问题。

3. 你说:

   Or is there anything you can do to keep crashes from bricking app?

   听起来“保存”操作以某种内部不一致的方式将结果保留在持久存储中。以下任何一项都会有所帮助，但我建议您如果可能的话，同时执行所有三项):

   • 冒着重复自己的风险，修复崩溃(消除问题根源总是比尝试围绕问题的表现进行编程更好)；

   • 根据您保存结果的方式，您也许可以使用 atomic保存操作，这样如果中途失败，也不会使其处于不一致状态；如果没有看到说明如何保存结果的代码片段，我们无法建议您应该如何执行此操作，但这通常是一种选择；

   • 确保，如果读取持久存储的“加载”进程可能失败，它会正常执行，而不是崩溃；看看是否可以在应用程序在启动期间失败的状态下获得它，然后仔细调试启动过程中发生的情况，导致应用程序在持久存储中使用此特定数据集失败。在“设备”部分，有一个选项可以下载与应用程序关联的数据，以便您可以仔细诊断正在发生的情况。