第43条:掌握GCD及操做队列的使用时机

　　本条要点：（做者总结）

•  在解决多线程与任务管理问题时，派发队列并不是惟一方案。
•  操做队列提供了一套高层的 Objective-C API，能实现纯 GCD 所具有的绝大部份功能，并且还能完成一些更为复杂的操做，那些操做若改用 GCD 来实现，则需另外编写代码。

　　GCD 技术确实很棒，不过有时侯采用标准系统库的组件，效果会更好。必定要了解每项技巧的使用时机，若是选错了工具，那么编出来的代码就会难于维护。

　　不多有其余技术能与GCD 的同步机制相媲美。对于那些只须要执行一次的代码来讲，也是如此，使用 GCD 的 dispatch_once 最为方便。然而，在执行后台任务时，GCD 并不必定是最佳方式。还有一种技术叫作 NSOperationQueue，它虽然与 GCD 不一样，可是却与之相关，开发者能够把操做以 NSOperation 子类的形式放在队列中，而这些操做也可以并发执行。其与 GCD 派发队列有类似之处，这并不是巧合。“操做队列”（operation Queue）在 GCD 以前就有了，其中某些设计原理因操做队列而流行，GCD 就是基于这些原理构建的。实际上，从 iOS 4 与 Mac OSX 10.6 开始，操做队列在底层是用 GCD 来实现的。

　　在二者的诸多差异中，首先要注意：GCD 是纯 C 的 API，而操做队列则是 Objective-C 的对象。在 GCD 中，任务用块来表示，而块是个轻量级数据结构。与之相反，“操做”（operation）则是个更为重量级的 Objective-C 对象。虽然说如此，但 GCD 并不老是最佳方案。有时候采用对象所带来的开销微乎其微，使用完整对象所带来的好处反而大大超过其缺点。

　　用 NSOperationQueue 类的 “addOperationWithBlock:” 方法搭配 NSBlockOperation 类来使用操做队列，其语法与纯 GCD 方式很是相似。使用 NSOperation 及 NSOperationQueue 的好处以下：

• 　取消某个操做。若是使用操做队列，那么想要取消操做是很容易的。运行任务以前，能够在 NSOperation 对象上调用 cancel 方法，该方法会设置对象内的标志位，用以代表此任务不须要执行，不过，已经启动的任务没法取消。如果不使用操做队列，而是把块安排到 GCD 队列中，那就没法取消了。那套架构是 “安排好任务以后就无论了”（fire and forget）。开发者能够在应用程序层本身来实现取消功能，不过这样作须要编写不少代码，而那些代码其实已经由操做队列实现好了。
• 指定操做间的依赖关系。一个操做能够依赖其余多个操做。开发者可以指定操做之间的依赖体系，使特定的操做必须在另一个操做顺序执行完毕以后方可执行。比方说，从服务器下载并处理文件的动做，能够用操做来表示，而在处理其余文件以前，必须先下载 “清单文件”（manifest file）。后续的下载操做，都要依赖于先下载清单文件这一操做。若是操做队列容许并发的话，那么后续的多个下载操做就能够同时执行，但前提是它们所依赖的那个清单文件下载操做已经执行完毕。
• 经过键值观测机制监控 NSOperation 对象的属性。NSOperation 对象有许多属性都适合经过键值观测机制（简称KVO）来监听，好比能够经过 isCancelled 属性来判断任务是否已取消，又好比能够经过 isFinished 属性来判断任务是否已完成。若是想在某个任务变动其状态时获得通知，或是想用比 GCD 更为精细的方式来控制所要执行的任务，那么键值观测机制会颇有用。
• 指定操做的优先级。操做的优先级表示此操做与队列中其余操做之间的优先关系。优先级高的操做先执行，优先级低的后执行。操做队列的调度算法（scheduling algorithm）虽 “不透明”（opaque），但必然是通过一番深思熟虑才写成的。反之，GCD 则没有直接实现此功能的办法。GCD 的队列确实有优先级，不过那是针对整个队列来讲的，而不是针对每一个块来讲的。而令开发者在 GCD 之上本身来编写调度算法，又不太合适，所以，在优先级这一点上，操做队列所提供的功能要比 GCD 更为便利。NSOperation 对象也有 “线程优先级”（thread priority），这决定了运行此操做的线程处在何种优先级上。用 GCD 也能够实现此功能，然而采用操做队列更为简单，只需设置一个属性。
• 重用 NSOperation 对象。系统内置了一些 NSOperation 的子类（好比 NSBlockOperation）供开发者调用，要是不想用这些固有子类的话，那就得本身来建立了。这些类就是普通的 Objective-C 对象，可以存听任何信息。对象在执行时能够充分利用存在于其中的信息，并且还能够随意调用定义在类中的方法。这就比派发队列中那些简单的块要强大许多。这些 NSOperation 类能够在代码中屡次使用，它们符合软件开发中的 “不重复”（Don't Repeat Yourself, DRY）原则。

　　正如你们所见，操做队列有不少地方赛过派发队列。操做队列提供了多种执行任务的方式，并且都是写好了的，直接就能使用。开发者不用再编写复杂的调度器，也不用本身来实现取消操做或指定操做优先级的功能，这些事情操做队列都已经实现好了。

　　有一个 API 选用了操做队列而非派发队列，这就是 NSNotificationCenter ，开发者可经过其中的方法来注册监听器，以便在发生相关事件时获得通知，而这个方法接受的参数是块，不是选择子。方法原型以下:

1 　　- (id)addObserverForName:(NSString *)name object:(id)object queue:(NSOperationQueue *)queue usingBlock:(void(^)(NSNotification *))block;

　　原本这个方法也能够不使用操做队列，而是把处理通知事件所用的块安排在派发队列里。但实际上并无这么作，其设计者显然使用了高层的 Objective-C API。在这种状况下，两套方案的运行效率没多大差距。设计这个方法的人可能不想使用派发队列，由于那样将依赖于 GCD，而这种依赖没有必要，前面说过，块自己和 GCD 无关，因此若是仅使用块的话，就不会引入对 GCD 的依赖了。也有可能编写这个方法的人想所有用 Objective-C 来描述，而不想使用纯 C 的东西。

　　常常会有人说：应该尽量选用高层 API，只在确有必要时才求助于底层。笔者也赞成这个说法，但我并不盲从。某些功能确实能够用高层的 Objective-C 方法来作，但这并不等于说它就必定比底层实现方案好。要想肯定哪一种方案更佳，最好仍是要测试一下性能。

　　END