使用 NSOperation 处理目标/操作弱引用
我正在使用 NSOperation 来处理 iOS 应用程序中的后台处理，并且我正在尝试理解目标/操作模式。在委托模式中，委托被作为弱引用保存，并且委托对象负责在dealloc之前将另一个对象的委托字段设置为nil。据我了解，在目标/操作模式中，出于类似的原因，目标被视为弱引用。然而，当目标对象 dealloc 和 NSOperation 存在时，“nil”目标字段似乎并不那么容易当其目标被释放时，该操作可能仍然位于队列中。
在这种情况下（NSOperation 执行后台处理，然后使用目标/操作将值返回给 NSOperation 的创建者），应该如何处理内存管理？
I'm using a NSOperation to handle background processing in an iOS app, and I'm trying to understand the target/action pattern. In the delegate pattern, the delegate is held as a weak reference, and the delegate object is responsible for setting the other object's delegate field to nil before it deallocs. In the target/action pattern, as I understand it, the target is held as a weak reference, for similar reasons. However, it doesn't seem as easy to "nil out" the target field when the target object deallocs, and with NSOperations there is a chance the operation could still be sitting on a queue when its target is deallocated.
How should memory management be handled in this case (of a NSOperation performing background processing, then using target/action to return a value to the creator of the NSOperation)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如 目标，如果有控件，则由您来确保目标可用可能会发送一个操作。实际上，这不是问题，因为目标通常是在控件之前创建并在控件之后释放的控制器。
如果您要从操作发送操作消息，则需要确保在操作完成之前不会释放目标。一种方法可能是让目标保留自身直到操作完成。
另一种方法可能是使用操作和目标都已知的中间对象。该操作可以将中间对象视为目标的代理，并将操作发送给它，而不是直接将其发送到目标，并且如果中间对象被释放，则目标可以适当地更新中间对象。目标和操作都可以保留中间体，而无需创建保留周期。我不确定这种方法是否是我的第一选择——似乎有点过于复杂——但它可能会有所帮助。
As explained in The Target, it's up to you to make sure that the target is available if a control might send an action. In practice, this isn't a problem because the target is usually a controller that's created before and deallocated after the controls.
If you're sending action messages from an operation, you'll need to ensure that the target isn't deallocated until after the operation completes. One way to do that might be to have the target retain itself until the operation completes.
Another approach might be to use an intermediate object that's known to both the operation and the target. The operation could treat the intermediate object like a proxy for the target and send the action to it rather than sending it directly to the target, and the target could update the intermediate appropriately if it's deallocated. Both the target and the operation could retain the intermediate without creating a retain cycle. I'm not sure this method would be my first choice -- seems a little overcomplicated -- but it might help.
UIControl 采用目标的 __weak 引用，因此目标操作方法不会更改目标的生命周期。
NSTimer 采用目标的 __strong 引用，在 NSTimer 对象释放之前，目标不会释放。这可能会导致保留圈。
试试这个 Pod：https://github.com/Elenionl/ELAutoSelector
UIControl takes a __weak reference of a target, so target-action methods do not change the lifetime of the target.
NSTimer takes a __strong reference of targets, the targets will not dealloc until the NSTimer Object dealloc. This may result in a retain-circle.
Try this pod: https://github.com/Elenionl/ELAutoSelector