现在我有一些我多年前编写的旧代码，它允许iOS应用程序在用户离线时排队作业（发送消息或向后端服务器提交数据等等）。当用户重新联机时，将运行任务。如果应用程序进入后台或终止，队列将被序列化，然后在应用程序再次启动时加载回来。我已经将NSOperationQueue子类化，我的工作是NSOperation的子类。这让我可以灵活地为我提供一个可以直接子类化的数据结构（操作队列），并通过子类化NSOperation如果我的任务失败（服务器关闭等等），我可以很容易地重新排队。
我很可能会把它保留原样，因为如果没有破坏就不要修复它，对吗？这些都是非常轻量级的操作，我不希望在当前的应用程序中，我正在努力在任何给定时间排队很多任务。但是我知道使用NSOperation而不是直接使用GCD会产生额外的开销。
我不相信我可以按照NSOperationQueue的方式对调度队列进行子类化，因此我会听到额外的代码来维护我自己的数据结构并将其加载到＆amp;每次将应用程序发送到后台时都不在调度队列中，对吧？如果失败，我也不确定如何处理重新排队的工作。现在，如果我从服务器获得HTTP 500 response，例如，在我的操作代码中，我发送一个通知，其中包含失败的NSOperation对象的深层副本。我的自定义操作队列选择此通知并将任务添加到自身。不确定如何能够与GCD做类似的事情。我还需要一种简单的方法来取消所有操作或在网络连接丢失时暂停队列，然后在重新获得网络访问时重新激活。
希望从其他人那里得到一些想法，意见和想法，这些人可能做过类似的事情，或者比我更熟悉GCD。
另外值得注意的是，我知道iOS 7中有一些新的后台任务支持，但可能还需要一段时间才能成为我的部署目标。我还不确定它是否会完全符合我的要求，所以目前只是看GCD的可能性。
感谢。
答案 0 :(得分：1)
如果NSOperation vs向GCD提交阻止，则会显示为可衡量的开销，问题不在于您使用的是NSOperation，而是您的操作远太颗粒了。我希望这种开销在任何实际情况下都是无法测量的。 （当然，你可以设计一个测试工具来测量开销，但只能通过实现无效的操作。）
使用最高级别的抽象来完成工作。只有当硬数据告诉您应该这样做时才会向下移动。