Fatal编程技术网
  • ios/
  • Ios isConcurrent对于从NSOperationQueue运行的NSOperation意味着什么？

Ios isConcurrent对于从NSOperationQueue运行的NSOperation意味着什么？

ios

Ios isConcurrent对于从NSOperationQueue运行的NSOperation意味着什么？,ios,nsoperation,nsoperationqueue,Ios,Nsoperation,Nsoperationqueue,因为NSOperationQueue总是在新线程上运行任务， 当NSOperation从NSOperationQueue运行时，我对isConcurrent的角色感到困惑 如果我有两个子类NSOperation，它们都运行异步进程，都是从NSOperationQueue启动的，并且在这两个子类中，我覆盖isCancelled，isExecuting，isFinished和isReady。 如果其中一个我覆盖isConcurrent始终返回YES而另一个总是返回NO，会有什么区别 谁真正调用了is

因为
NSOperationQueue
总是在新线程上运行任务， 当
NSOperation
从
NSOperationQueue
运行时，我对
isConcurrent
的角色感到困惑

如果我有两个子类
NSOperation
，它们都运行异步进程，都是从
NSOperationQueue
启动的，并且在这两个子类中，我覆盖
isCancelled
，
isExecuting
，
isFinished
和
isReady
。 如果其中一个我覆盖
isConcurrent
始终
返回YES
而另一个总是
返回NO
，会有什么区别

谁真正调用了
isConcurrent
？如果是
NO
或
YES
则逻辑如何变化这是一种遗留方法，在OS X v10.6之前和iOS 4之前使用，即在推出用于
NSOperationQueue
调度的GCD之前

从

操作队列通常提供用于运行其操作的线程。在OS X v10.6及更高版本中，操作队列使用
libdispatch
库（也称为Grand Central Dispatch）启动其操作的执行。因此，无论操作被指定为并发操作还是非并发操作，操作总是在单独的线程上执行但是，在OS X v10.5中，只有当操作的
isConcurrent
方法返回
NO
时，操作才会在单独的线程上执行。如果该方法返回YES，则操作对象将创建自己的线程（或启动一些异步操作）；队列没有为其提供线程

如果您正在运行OS X>=10.6或iOS>=4，则可以安全地忽略它

作为对这一事实的确认，从

在OS X v10.6及更高版本中，操作队列忽略此方法返回的值，并始终在单独的线程上启动操作

我现在添加了一个更简洁的答案，暂时将此作为讨论的一部分

好的，直到今天，我对使用
isConcurrent
方法还是很满意的

我读了这句话：

在OS X v10.6及更高版本中，操作队列忽略 此方法并始终在单独的线程上启动操作

作为与QA1712相关的警告，指出对于并发操作，
start
方法现在可以在不同于排队操作的线程上调用，这是10.6和iOS 4中的一个更改

我并没有将此理解为表示队列完全忽略了
isConcurrent
方法，完全没有任何用途，只是它不再影响调用
start
的线程。我可能误解了这一点

我还将最初的问题误解为关于并发操作的更一般的问题，
isConcurrent
标志，而公认的答案实际上是这样说的

从10.6版和iOS 4版开始，
isConcurrent
标志可以忽略

我不确定这是否正确

如果我现在理解了原来的问题，可以这样解释：

如果正确构建了并发的
NSOperation
，
isConcurrent
标志本身是否确实改变了操作的执行

我想很难说所有可能的设置，但我们可以说：

  • 它没有被弃用。苹果公司反对这种方法是正常的 这些都不再有用了

  • 文件一致地引用了所需的方法 覆盖

    • 也许
    isConcurrent
    实际上已被弃用，但由于它只是一个
    BOOL
    标志，也许不值得在文档中大力弃用它。或者它现在什么也不做，但苹果保留了它，以备将来可能使用，并希望您按照描述覆盖它

    我创建了一个快速测试项目，其中有一个
    NSOperation
    ，它只覆盖了
    isConcurrent
    和
    main
    ，在任何阶段都没有调用
    isConcurrent
    。这是一个非常简单的测试。我想你可能也测试过了？我假设如果
    NSOperationQueue
    没有调用
    NSOperation的
    start
    的默认实现，可能会发生这种情况
    
那我们该怎么办？显然，实现它并返回
    YES
    以满足文档化的需求并不麻烦。然而，从我的角度来看，我认为从10.6和iOS 4.0的告诫出发，说现在可以安全地忽略它是一个很大的飞跃
    

    
我的原始答案…
    

    isConcurrent
    不是传统方法，并且不会被
    NSOperationQueue
    忽略。其他答案中引用的文档有点不清楚，容易被误解
    

    isConcurrent=YES
    表示操作提供自己的并发方式。或者换句话说，操作
    “是alreadyconcurrent”
    ，不需要
    NSOperationQueue
    来提供和管理并发性。由于
    NSOperationQueue
    不再提供并发性，您需要在操作
    完成时告诉它，或者如果操作
    被取消时告诉它（等等），因此需要覆盖这些方法
    
一个常见的例子是管理
    nsurl连接的
    NSOperation
    NSURLConnection
    有自己的后台运行机制，因此不需要通过
    NSOperationQueue
    使其并发
    
一个明显的问题是：“为什么要将一个已经并发的操作放入
    NSOperationQueue
    ？”这样操作就可以从
    NSOperationQueue
    的其他特性（如依赖项等）中获益