我有一个应用程序，它使用 NSOperations 来管理对 Web API 的服务调用(这些调用基于 CURLOperation in Jon Wight's touchcode )。
本地图 View 的中心发生显着变化时，有一个特定的调用会下载 map 位置；因为这些可以很快堆积起来，如果你移动 map ，我会尝试积极取消陈旧的操作。它在 4.0 上运行良好。
但是，在 3.1 中，似乎在某些情况下操作队列将保留已取消(和释放)的操作，从而在到达它们应在队列中的位置时导致崩溃。
这是一个插图。
我从队列中相对重量级的服务调用开始:
MyLongRunningOp 0x1
用户导航至 map 。队列现在看起来像这样:
MyLongRunningOp 0x1MyMapOp 0x2
他们移动 map ，取消 MyMapOp 0x2 并添加 MyMapOp 0x3:
MyLongRunningOp 0x1MyMapOp 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 的错误。
我在解决这个问题时遇到了很多麻烦 - 据我所知，唯一的解决方法是永远不要取消我的操作，这会在网络不稳定时导致体验不佳。
还有其他人经历过这种情况吗？有什么想法吗？
最佳答案
我在 NSOperations 上使用 KVO 时遇到了(我认为是)类似的问题。
刚刚阅读您的描述，我的第一 react 是检查操作队列的规则。是否有可能一旦您将其交给队列，队列就应该承担所有权，因此您不应该手动释放它？ (不确定你是否是)。
根据我的个人经验，也许这会有所帮助，也可能没有帮助:
1) 当您取消操作时，请从中删除 KVO 观察者。我遇到过这样的情况:当任何一方被删除时，KVO 都不会取消链接。
2) 请注意，KVO 回调与 NSOperation 在同一线程中运行。因此，在您开始操作和 KVO 回调之间，对象可能会超出范围。
如果您发布代码，我也许可以为您提供更多帮助。希望以上内容对您有用!
关于iphone - 为什么 iPhone OS 3.1 上的 NSOperationQueue 会保留长期取消(和释放)的操作？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3670309/