iphone - 为什么 iPhone OS 3.1 上的 NSOperationQueue 会保留长期取消(和释放)的操作？

Question

我有一个应用程序，它使用 NSOperations 来管理对 Web API 的服务调用(这些调用基于 CURLOperation in Jon Wight's touchcode )。

本地图 View 的中心发生显着变化时，有一个特定的调用会下载 map 位置；因为这些可以很快堆积起来，如果你移动 map ，我会尝试积极取消陈旧的操作。它在 4.0 上运行良好。

但是，在 3.1 中，似乎在某些情况下操作队列将保留已取消(和释放)的操作，从而在到达它们应在队列中的位置时导致崩溃。

这是一个插图。

我从队列中相对重量级的服务调用开始:

1. MyLongRunningOp 0x1

用户导航至 map 。队列现在看起来像这样:

1. MyLongRunningOp 0x1
2. MyMapOp 0x2

他们移动 map ，取消 MyMapOp 0x2 并添加 MyMapOp 0x3:

1. MyLongRunningOp 0x1
2. MyMapOp 0x3

MyMapOp 0x2 现已发布，因为它已从队列中删除。现在，MyLongRunningOp 0x1 完成。在用于设置 MyLongRunningOp 上 isFinished 键的 KVO 回调中，我看到操作队列处理通知并尝试将 MyMapOp 0x2 添加到某些 NSArray >。当然，启用 NSZombies 后，

[MyMapOp retain]: message sent to deallocated instance 0x2

似乎 NSOperationQueue 以某种方式卡在指向已取消/已释放操作的指针上，并尝试在前一个操作完成后激活它。

我无法在 4.0 上重现此行为，因此我认为这是 3.1 的错误。

我在解决这个问题时遇到了很多麻烦 - 据我所知，唯一的解决方法是永远不要取消我的操作，这会在网络不稳定时导致体验不佳。

还有其他人经历过这种情况吗？有什么想法吗？

Answer 1

我在 NSOperations 上使用 KVO 时遇到了(我认为是)类似的问题。

刚刚阅读您的描述，我的第一 react 是检查操作队列的规则。是否有可能一旦您将其交给队列，队列就应该承担所有权，因此您不应该手动释放它？ (不确定你是否是)。

根据我的个人经验，也许这会有所帮助，也可能没有帮助:

1) 当您取消操作时，请从中删除 KVO 观察者。我遇到过这样的情况:当任何一方被删除时，KVO 都不会取消链接。

2) 请注意，KVO 回调与 NSOperation 在同一线程中运行。因此，在您开始操作和 KVO 回调之间，对象可能会超出范围。

如果您发布代码，我也许可以为您提供更多帮助。希望以上内容对您有用!