ios - 需要帮助弄清楚如何避免 iOS 中的崩溃

Question

我几乎知道为什么我的 iPad 应用程序崩溃了，但我无法想出一个解决方案的方案。该应用程序是一个拼图应用程序。我有一个比应用商店中的版本更稳定的工作版本，但我仍然有一个讨厌的问题，我不能完全解决。

问题的根源在于用户事件和自动保存之间的冲突。保存基本上将拼图的状态存储为属性列表。除其他外，属性列表包含拼图中所有调色板的汇编，并且对于每个调色板，该调色板上所有部分的详细信息。它运作良好，只是用户事件可能会改变这些细节。调色板本质上是一个包含拼图作为 subview 的 UIView。用户可以在调色板上移动片段或将它们从一个调色板移动到另一个调色板。

我的保存过程分两个阶段进行。第一阶段由计时器启动。此阶段会定期检查是否存在需要保存的用户事件。它设置了一个属性 abortSave变为 NO，然后触发非重复计时器在开始第二阶段之前等待另一个时间段。

在第二阶段，只要 abortSave 就会进行保存。没有。

同时，如果用户进行了任何影响保存的操作，abortSave设置为是。这个想法是阶段 1 和阶段 2 之间的延迟比执行用户操作所需的时间长，所以如果 abortSave是NO，那么进行保存应该是安全的。

这个过程已经消除了 95% 左右的崩溃，但我仍然遇到崩溃。

当然，为了应用程序的良好性能，用户事件以及保存操作都在后台线程中进行。

我遇到的情况类型通常是快速枚举期间的突变，或类似的情况。本质上，一些用户操作是在保存过程中进行更改。如果我复制正在快速枚举的对象然后处理副本，它没有帮助。有时错误会发生在复制语句上。如果对象是数组，我不使用快速枚举，而是使用常规 for 循环来遍历数组。这有点帮助。

我希望这个问题不是太笼统。我想我可以发布一些代码，但我不确定它到底有多大帮助。我不想不必要地混淆这个问题。

我还没有做的一件事是使用另一种方式工作的标志:
saveProcessActive在保存发生之前设置为 YES 并在保存完成时设置为 NO 。如果 saveProcessActive，则所有用户操作都必须停止。是是的。这种情况的问题是它会导致用户操作的延迟，可能对用户可见，但可能任何延迟都是微不足道的。它只需要保存到下一次检查 abortSave 之前的时间。 .然后，中止的保存过程将变为 saveProcessActive当它确认中止请求时变为 NO。有更好的解决方案吗？

Answer 1

在内存中复制当前游戏状态应该是一个快速的 Action 。当您想保存时，制作该副本，然后将其交给您的后台队列以使用 dispatch_async() 进行保存.这样做可以消除所有并发问题，因为每条数据只能在单个队列上访问。

编辑:这是我通常如何解决此类问题(未经测试):

- (void)fireSave:(NSTimer *)timer {
  id thingToSave = [self.model copyOfThingToSave];
  dispatch_async(self.backgroundSavingSerialQueue, ^{
    [self writeToDisk:copyOfThingToSave];
  }
}

- (void)saveLater {
  [self.timer invalidate];
  self.timer = [NSTimer scheduledTimerWithTimeInterval:5
                                                target:self
                                              selector:@selector(fireSave:)
                                              userInfo:nil 
                                               repeats:NO];
}

现在，无论您在哪里修改数据，都可以调用 [self saveLater] .除了 writeToDisk: 之外，这里的所有内容都在主线程上。 (传递数据的副本)。由于writeToDisk:总是在自己的串行队列上运行，它也避免了竞争条件，即使你要求它比它保存得更快。