没有100％，但是在某些情况下，您可能更喜欢一种：

作为一般规则，您可能会喜欢GCD，因为它效率更高。话虽如此，在以下情况下，人们可能会更喜欢Operation：

• 您通过封装Operation来包装本身是异步的任务（例如网络请求）。

  例如Trying to Understand Asynchronous Operation Subclass。

• 您希望将某些操作的逻辑封装在其自己的对象中，以提供更好的职责分离。

  例如，假设我要在用户界面中显示一堆图像，并且想要异步调整它们的大小。我不想用异步调整大小逻辑来妨碍我的视图控制器（或视图，或视图模型/演示者）。我可以将异步调整大小的逻辑包装在其自己的Operation子类中。

• 您想要并发，但也想限制在任何给定时间可以完成多少次。

  例如，如果要处理许多图像，您可能不想说您不想在任何给定时间执行多于4张图像，因为您想限制在任何给定时刻的峰值内存使用量。因此，您需要设置maxConcurrentOperationCount中的OperationQueue。

• 虽然您可以取消GCD DispatchWorkItem对象和Operation对象，但是Operation中的实现更为优雅。

  例如，假设我有一个Operation，用于包装异步网络请求。我可以编写自己的cancel覆盖，以取消网络请求。如果您的任务由某个for或while循环组成，则可以使用DispatchWorkItem（例如How to stop a DispatchWorkItem in GCD?）来取消操作，但是在处理本身是异步的任务时，Operation处理起来更好。但是，即使在简单的场景中，我也发现在操作队列中进行取消更为简单和直观。

• 操作队列非常适合那些您可能具有复杂依赖性的情况。

  例如，您有任务A，B，C，D和E，但是您不希望C和D在A和B完成后才能运行，而您只希望E在C和D时运行完成。操作队列可以通过“依赖项”很好地处理这类情况。

• 您的队列中有很多任务，但是它们的优先级不同。使用操作队列，每个任务可以有自己的queuePriority，并且操作队列将倾向于优先选择那些优先级较高的操作，而不是优先级较低的操作。

其中一些方法也可以在GCD中实现，但是在这些情况下，操作队列可能更适合。

话虽如此，在某些情况下，GCD绝对更适合：

• 我想要与某些对象进行线程安全的交互。进行同步时，我需要尽可能少的开销。

  例如，您可以将读写器模式与GCD并发队列一起使用。然后使用sync相对于彼此并发执行读取操作，但使用屏障异步执行写入操作（因此永远不会相对于其他任何操作同时进行）。

• 我只想快速将一些UI更新发送到主队列。

  例如，假设有一个URLSession任务正在运行，并且在其完成处理程序（在后台串行队列中运行）中，我想更新UI或模型对象。通常，我只想接触DispatchQueue.main.async { ... }。简单高效。

• 我想在后台队列上运行计时器。

  例如，请参见How to execute a method every second on a background thread so it doesn't affect the performance of the app?

• 我想使一些计算任务与UI更新脱钩。我可能会进行派遣合并或添加“源”。

  例如，您可能正在做一些复杂的计算，并且想要更新进度指示器，但是更新的速度可能比UI处理它们的速度更快。因此，我们可以使用分派添加源将后台任务与UI更新分离。例如Long cycle blocks application。

• 我有一些计算量大的任务，我想最大限度地利用设备上的内核，但又不想耗尽GCD工作线程数量非常有限的情况。在这种情况下，我需要联系concurrentPerform来并行化我的for循环。 （请参见前面的示例。）

简而言之（并且要简化），GCD非常适合简单高效的任务（或低级控制），而操作队列则非常适合高级逻辑工作单元。

有关更多信息，另请参见When are GCD queues used and when do you know you need them?

内部之间没有很大的区别，因为Operations和OperationQueues是内部的GCD。

但是，操作可以让您指定触发机制和相关性，从而使您可以连贯地流/链异步操作，如以下精彩视频所述：

https://developer.apple.com/videos/play/wwdc2015/226/

使用裸露的GCD很难做到这一点。

另一方面，新的Combine框架可能以更好的方式解决了相同类型的问题。