ios - 避免致命的崩溃

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

我知道我只需要每天打电话给它，就可以在以后的错误修复中保留下一个版本。我删除了我在测试中拥有的所有abort()语句。但是，偶尔会出现崩溃，而不是让您仅关闭应用程序然后重新打开，而导致崩溃，而无需重新安装就无法打开应用程序。例如，这只是发生了



这是由于在后台同步到云期间切换VC所致。

我可能会遇到崩溃，您只需要重新打开它即可，而不会导致应用程序无法使用的崩溃。是否有针对崩溃类型的准则，以帮助您专注于真正致命的崩溃？

还是有什么办法可以防止应用程序崩溃？

最佳答案

您应该只解决此问题。由于您具有带有该错误消息的崩溃日志，因此您知道哪种方法都可以引发问题，因此即使问题前后矛盾地和/或以多种方式表现出来，您也都有了很好的解决之道。

但是，偶尔出现的车祸给您带来的不便似乎并不太多，但这是获得1星级评论和不满意客户的最快方法。我怀疑您会后悔发布具有已知的，容易复制的崩溃的应用程序。

但是，一些观察:

听起来您的后台更新过程正在变异主线程使用的模型对象。

如果可能的话，建议不要在后台线程中更改任何模型对象，而要填充一个局部变量，并在准备好相应地更新UI时，同时分发模型更新和UI刷新到主线程。

如果由于某种原因无法执行此操作，则必须使用某种机制(例如锁，GCD串行队列，读取器-写入器模型等)来同步模型更新的所有交互。这稍微复杂一些，但是可以实现。

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



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

您说:



听起来“保存”操作以某种内部不一致的方式将结果保留在持久性存储中。以下任何一项都可以帮助您，尽管我建议您在可能的情况下全部执行三项操作:

冒着重蹈覆辙的危险，解决崩溃(与尝试围绕问题的表现进行编程相比，消除问题的根源总是更好的选择)；

根据您保存结果的方式，您可以使用 atomic 保存操作，这样，如果操作中途失败，则不会使它处于不一致的状态。在看不到说明如何保存结果的代码段的情况下，我们不能建议应该如何做，但这通常是一个选择；

确保，如果读取持久性存储的“加载”进程可能失败，请确保其正常运行而不是崩溃；查看您是否可以在启动过程中应用程序出现故障的状态下获取它，然后仔细调试启动过程中正在导致持久性存储中的这组特定数据失败的应用程序。在“设备”部分中，有一个选项可以下载与应用程序关联的数据，因此您可以仔细诊断正在发生的事情。

关于ios - 避免致命的崩溃，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/49989173/