Ios 对脱机持久队列使用GCD

现在，我有一些多年前编写的旧代码，允许iOS应用程序在用户离线时排队作业（发送消息或向后端服务器提交数据等）。当用户重新联机时，任务将运行。如果应用程序进入后台或被终止，队列将被序列化，然后在再次启动应用程序时重新加载。我已经对

NSOperationQueue

进行了子类化，我的作业是

NSOperation

的子类。这使我能够灵活地使用提供给我的数据结构，我可以直接子类化（操作队列），通过子类化

NSOperation

，如果任务失败（服务器关闭等），我可以轻松地重新查询

我很可能会让它保持原样，因为如果它没有坏，就不要修复它，对吗？此外，这些都是非常轻量级的操作，我不希望在我正在开发的当前应用程序中，在任何给定的时间都有很多任务排队。但是，我知道使用

NSOperation

而不是直接使用

GCD

会有一些额外的开销

我不相信我可以像对待

NSOperationQueue

那样对调度队列进行子类划分，因此我会无意中听到额外的代码来维护自己的数据结构，并在每次将应用发送到后台时将其加载到调度队列中，对吗？也不知道如果工作失败，我会如何处理重新申请。现在，如果我从服务器获得

HTTP 500响应

，例如，在我的操作代码中，我会发送一个通知，其中包含失败的

NSOperation

对象的深度副本。我的自定义操作队列接收此通知并将任务添加到自身。不确定我是否能用

GCD

做类似的事情。我还需要一种简单的方法来取消所有操作或在网络连接丢失时挂起队列，然后在恢复网络访问时重新激活队列

只是希望从其他可能做过类似事情或比我更熟悉GCD的人那里得到一些想法、意见和想法

另外值得一提的是，我知道iOS 7将提供一些新的后台任务支持，但这可能需要一段时间才能成为我的部署目标。我也不确定它是否能完全满足我的需要，所以目前只考虑

GCD

的可能性

---

谢谢。

如果

NSOperation

与向GCD提交数据块相比显示出可测量的开销，问题不在于您使用的是

NSOperation

，而是您的操作过于精细。我希望这种开销在任何实际情况下都是无法测量的。（当然，您可以设计一个测试线束来测量开销，但只能通过执行实际上什么都不做的操作。）

---

使用完成工作的最高抽象级别。只有当硬数据告诉你应该这样做时，才下移。

虽然我确信这是可以做到的，但我还是有一些想法<代码>1。GCD没有内置的取消支持；你得自己滚<代码>2。没有像

NSOperationQueue

那样简单的子类化，因此您必须单独维护操作列表，而不是在子类中，这可能是未来的错误源<代码>3。从iOS 4+开始，NSOperationQueue在内部使用

GCD

<代码>4。为什么要重新写一些没有损坏的东西？是的，你的第4点正是我自己说的。是的，NSOperationQueue在封面下使用GCD。我也知道，使用最高级别的抽象是最容易的，但是会有一些开销。我不是在试图解决一个我没有遇到的问题，也就是说，我没有看到这方面的性能问题，而是在检查，因为这是旧代码，更新是否有意义，以及在我使用GCD的有限经验中是否缺少一些东西，这些东西会使重构变得比看起来更容易。很可能就这样离开。谢谢。完全证实了我的想法——只是想做一次精神检查。谢谢