Ios 单独线程中的同步与异步相同吗

最近，我在swift学习并发。根据苹果公司在《操作类参考》中的文件：

将操作添加到操作队列时，队列将忽略asynchronous属性的值，并始终从单独的线程调用start方法。因此，如果总是通过将操作添加到操作队列来运行操作，则没有理由使其异步

这是否意味着单独线程中的同步与异步相同？当我使用下面的代码进行测试时，该操作确实不会阻塞当前的主线程

let operationQueue = NSOperationQueue()
let operation = NSBlockOperation(){
    //do some task here
}
operationQueue.addOperation(operation)

---

因此，如果这是真的，那么我们为什么要创建NSOperation的并发子类呢？

异步总是相对于发出请求的线程定义的。因此，如果线程a发出在线程B中运行的请求，使得线程a能够在线程B运行请求时执行其他工作，那么请求相对于线程a是异步的

如果线程B将请求转发给线程C，这样线程B可以在线程C运行请求时执行其他工作，那么第二个请求相对于线程B是异步的

---

当然，一次又一次地异步耕作同一个工作元素是没有意义的。但是假设上面描述的由线程A委托给线程B的工作可以被分成多个较小的工作元素。线程B在线程C、D等上异步调用较小的工作元素是合理的。如果B向a提供服务，而a不想/不需要知道如何完成工作的细节，则可能会发生这种情况；它只是希望异步完成工作。B知道细节，可以决定是否/如何通过较小的并行单元完成工作。

哦，

NSOperation

。你的历史太离奇了

NSOperation

相对较旧（用iOS术语；用ObjC术语来说相当现代）。它是在OSX10.5中添加的。在OSX10.6/IOS4之前，没有

NSBlockOperation

对象。根本没有街区。因此，进行操作的唯一方法是子类化或使用

NSInvocationOperation

。这两种方法都很麻烦，但仍然比直接使用

NSThread

的旧方法更简单、更强大

（这在多核成为一种事物的时候是正确的。10.5以添加核心动画而闻名，我相信这是Cocoa中第一个主要的抢先多任务框架。在10.5之前，大多数事情都是通过runloop和协作多任务来完成的，这对于单核系统来说实际上是非常高效和有效的。但它不是t可以很好地扩展到多核系统。提供了

NSOperation

等工具来帮助我们编写更好的多核代码，但GCD功能强大得多，它完全控制了用Cocoa编写多任务代码的方式。）

当您将

NSOperation

子类化时，您需要告诉系统您的操作是否是异步的。这不是异步运行您的请求。这是您的

start

方法不会阻塞的承诺。由您的

start

方法来确保操作确实是异步的

只有在手动启动

NSOperation

的情况下，才需要这样做，即使在手动启动的情况下，通常也不需要这样做。如果您将其放入

NSOperationQueue

（您确实应该始终这样做），则此属性与此无关。我记得当时它造成了很多混乱

自从引入块以来，它变得更加无关紧要。使用

NSBlockOperation

（或

dispatch\u async

）几乎总是比使用子类

NSOperation

容易得多，而子类

NSOperation

总是有点棘手

---

以防万一，您还没有读过它，如果您想研究Cocoa并发，您一定要从开始。

真的谢谢。如果我理解正确，您的意思是在单独的线程中同步确实与异步相同。实际上，在使用

NSOperationQueue时，不需要更改异步属性。两个计数都正确。