最近在学习swift的并发。根据 NSOperation class reference 中的 apple 文档:
When you add an operation to an operation queue, the queue ignores the value of the asynchronous property and always calls the start method from a separate thread. Therefore, if you always run operations by adding them to an operation queue, there is no reason to make them asynchronous.
这是否意味着在单独的线程中同步与异步相同？当我使用以下代码进行测试时，该操作确实不会阻塞当前主线程。
let operationQueue = NSOperationQueue()
let operation = NSBlockOperation(){
//do some task here
}
operationQueue.addOperation(operation)
如果是这样，那我们为什么要创建 NSOperation 的并发子类？
最佳答案
哦，NSOperation。你有这么离奇的历史。
NSOperation 相对较旧(在 iOS 术语中；在 ObjC 术语中相当现代)。它是在 OS X 10.5 中添加的。在 OS X 10.6/iOS 4 之前，没有 NSBlockOperation 对象。根本没有障碍物。因此，进行操作的唯一方法是子类化或使用 NSInvocationOperation。这两种方法都很麻烦，但仍然比直接使用 NSThread 的旧方法更简单、更强大。
(这正是多核成为现实的时候。10.5 以添加核心动画而闻名，我相信这是 Cocoa 中第一个主要的抢占式多任务处理框架。在 10.5 之前，大多数事情都是用 runloop 和合作完成的多任务处理，这对于单核系统实际上非常高效和有效。但它不能很好地扩展到多核系统。提供了像 NSOperation 这样的工具来帮助我们编写更好的多核代码，但 GCD 强大得多，以至于它完全支配了 Cocoa 中多任务代码的编写方式。)
当您继承 NSOperation 时，您需要告诉系统您的操作是否是异步的。这不是异步运行您的请求。这是您的 start 方法不会阻塞的 promise 。由您的 start 方法来确保操作确实是异步的。
这仅在您的 NSOperation 被手动启动的情况下才有必要，即便如此，通常也不需要。如果你把它放到一个 NSOperationQueue 中(你真的应该总是这样做)，这个属性是无关紧要的。我记得它当时造成了很多困惑。
自从引入 block 以来，它变得更加无关紧要。使用 NSBlockOperation(或 dispatch_async)几乎总是比子类化 NSOperation 容易得多，这总是有点棘手才能完全正确.
以防万一你还没有读过它，如果你想研究 Cocoa 并发，你肯定想从 Concurrency Programming Guide 开始。 .
关于ios - 在单独的线程中同步与异步相同，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34978360/