【问题标题】:NSOperation Cancellation: NSInvocationOperation or NSOperation subclass?NSOperation 取消:NSInvocationOperation 还是 NSOperation 子类?
【发布时间】:2011-03-18 04:26:10
【问题描述】:

我有一个相当简单但昂贵的任务,我需要在后台运行,这是标准的 NSOperation 情况。我还需要确保操作支持取消,并适当地停止。鉴于该要求,哪种方法更好:只是将昂贵的方法调用封装在 NSInvocationOperation 中,还是从头开始编写 NSOperation 子类?

到目前为止,这是我的想法。 NSInvocationOperations 是我的第一选择,也是我过去使用的,因为任务非常简单,我不想编写一个包含所有 NSOperation 样板代码的整个类来执行它。现在让我犹豫的是,在 NSInvocationOperation 中执行的方法似乎并没有一种方法可以检查取消并不会引起我脑海中的骇客警报。有关上述黑客的一些示例,请参见this question。我试过了,它们确实有效,但它们也觉得恶心。

如前所述,编写一个 NSOperation 子类来执行简单的任务似乎有点过头了,但毫无疑问,检查取消比我遇到的 NSInvocationOperation 更优雅。

那么,对于那些拥有更多 NSOperations 的人来说,你习惯了哪些最成功的结局?是否有使用我可能错过的 NSInvocationOperations 的不错的取消解决方案?如果没有对取消的某种支持,NSInvocationOperations 有用的情况就会急剧下降。

【问题讨论】:

    标签: iphone objective-c ipad nsoperation


    【解决方案1】:

    我相信,子类化 NSOperation 是唯一优雅的方法。

    当我将现有代码重构为多线程时,我倾向于只使用 NSInvocationOperations,这是一个方便的快捷方式。

    【讨论】:

    • +1 当我深入研究 Obj-C/iOS 时,我发现起初看起来过于冗长的做事方式实际上最终会鼓励更好的代码结构并提供更多权力或让你避免重新发明轮子。
    【解决方案2】:

    只是 NSOperation 的子类。 (需要更多字符)

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2014-11-23
      • 2015-10-30
      • 1970-01-01
      • 1970-01-01
      • 2011-04-21
      相关资源
      最近更新 更多