我几乎知道为什么我的 iPad 应用程序崩溃了,但我无法想出一个解决方案的方案。该应用程序是一个拼图应用程序。我有一个比应用商店中的版本更稳定的工作版本,但我仍然有一个讨厌的问题,我不能完全解决。
问题的根源在于用户活动和自动保存之间的冲突。保存基本上将拼图的状态存储为属性列表。除其他外,属性列表包含拼图中所有调色板的汇编,并且对于每个调色板,该调色板上所有部分的详细信息。它运作良好,只是用户活动可能会改变这些细节。调色板本质上是一个包含拼图作为子视图的 UIView。用户可以在调色板上移动片段或将它们从一个调色板移动到另一个调色板。
我的保存过程分两个阶段进行。第一阶段由计时器启动。此阶段会定期检查是否存在需要保存的用户活动。它将一个属性设置abortSave
为 NO,然后触发一个非重复计时器在开始第二阶段之前等待另一个时间段。
在第二阶段,只要abortSave
是 NO,就会进行保存。
同时,如果用户执行了任何影响保存的操作,abortSave
则设置为YES。这个想法是阶段 1 和阶段 2 之间的延迟比执行用户操作所需的时间要长,所以如果abortSave
是 NO,那么进行保存应该是安全的。
这个过程已经消除了 95% 左右的崩溃,但我仍然遇到崩溃。
当然,为了应用程序的良好性能,用户活动以及保存操作都在后台线程中进行。
我遇到的情况类型通常是快速枚举期间的突变,或类似的情况。本质上,一些用户操作是在保存过程中进行更改。如果我复制正在快速枚举的对象然后处理副本,它没有帮助。有时错误会发生在复制语句上。如果对象是数组,我不使用快速枚举,而是使用常规 for 循环来遍历数组。这有点帮助。
我希望这个问题不是太笼统。我想我可以发布一些代码,但我不确定它到底有多大帮助。我不想不必要地混淆这个问题。
我还没有做的一件事是使用另一种方式工作的标志:
saveProcessActive
在保存发生之前设置为 YES 并在保存完成时设置为 NO 。saveProcessActive
如果是,则所有用户操作都必须停止。这种情况的问题是它会导致用户操作的延迟,可能对用户可见,但可能任何延迟都是微不足道的。它只需要保存到下一次检查abortSave
. saveProcessActive
当它确认中止请求时,中止的保存过程将变为NO。有更好的解决方案吗?