如何在当前队列中调度_after?

Boo*_*oon 8 objective-c grand-central-dispatch ios ios6

现在dispatch_get_current_queue在iOS 6 中已弃用,如何dispatch_after在当前队列中执行某些操作?

Rob*_*ier 5

评论中的各种链接并没有说"最好不要这样做".他们说你不能这样做.您必须传递所需的队列或分派到已知队列.调度队列没有"当前"的概念.块通常从一个队列馈送到另一个队列(称为"定位").当你实际运行时,"当前"队列并没有真正意义,依靠它可以(并且历史上确实)导致死锁.dispatch_get_current_queue()从来没有打算派遣; 这是一种调试方法.这就是它被删除的原因(因为人们把它当作有意义的东西对待).

如果您需要这种更高级别的簿记,请使用NSOperationQueue跟踪其原始队列的(并且具有更简单的排队模型,使"原始队列"更有意义).

UIKit中使用的几种方法是合适的:

  • 将回调dispatch_queue作为参数传递(这可能是新API中最常用的方法).参见[NSURLConnection setDelegateQueue:]addObserverForName:object:queue:usingBlock:举例.请注意,NSURLConnection期望一个NSOperationQueue,而不是一个dispatch_queue.更高级别的API以及所有这些.
  • 回拨你正在使用的任何队列,并将其留给接收器来处理它.这就是回调传统上的工作方式.
  • 要求调用线程上有runloop,并在调用runloop上安排回调.这是NSURLConnection排队前的历史工作方式.
  • 除非另有说明,否则始终在其中一个众所周知的队列(尤其是主队列)上进行回调.我不知道在UIKit中这是做什么的,但我在应用程序代码中经常看到它,并且在大多数情况下是一种非常简单的方法.

  • 我对你的上一个语句有一些抱怨:如果这是一个回调(比如一个完成,错误或进度处理程序),那么*main queue*应该是被选为默认执行上下文的最少候选者.使用主队列会增加死锁的可能性.这是一个来自图书馆设计师的坏习惯,源于愚蠢和错误的假设,即异步任务的客户端想要"反正"在主线程上做东西.但这让事情变得更糟. (2认同)