iOS并发编程中Dispatch Queues的创建与管理的实践总结

　导读：本文为读《Concurrency Programming Guide》笔记第二篇，在上篇分享了OS X和iOS应用开发中实现任务异步执行的技术以及应注意的事项之后，作者付宇轩（@DevTalking）对Operation对象的设置与执行，以及Dispatch Queues的创建与管理进行了实践总结。
　　系列阅读
　　Operation对象的相关设置
　　Operation对象除了上文中讲到到基本使用方法外还有一些其他的特性，这些特性需要根据我们的应用场景去设置，设置的时机在创建Operation对象之后和运行它或者将其放入操作队列之前，下面让我们来看看Operation对象还有哪些特性。
　　Operation对象之间的依赖
　　与GCD不同，Operation Queue不遵循先进先出的原则，而且Operation Queue始终是并发执行Operation对象的，所以想让Operation对象串行执行就需要用它的Operation对象依赖特性，该特性可以让Operation对象将自己与另外一个Operation对象进行关联，并且当关联的Operation对象执行完成后才可以执行，这样就达到了串行执行Operation对象的目的。
　　我们可以用NSOperation的addDependency方法添加依赖的Operation对象，而且产生依赖的这两个Operation对象并不要求必须在相同的操作队列中，但是这种依赖只能是单向的，不能相互依赖。
　　importFoundation classTestOperationDependency{func launch（） { letblockOperationA = NSBlockOperation（block： { print（“Task in blockOperationA.。.”） sleep（3） }） letblockOperationB = NSBlockOperation（block： { print（“Task in blockOperationB.。.”） sleep（5） }） blockOperationA.addDependency（blockOperationB） letoperationQueue = NSOperationQueue（） operationQueue.addOperation（blockOperationA） operationQueue.addOperation（blockOperationB） sleep（10） } } lettestOperationDependency = TestOperationDependency（） testOperationDependency.launch（）
　　上面的示例代码展示了如何给Operation对象添加依赖，大家可以注释掉blockOperationA.addDependency（blockOperationB）这一行看看打印结果有什么区别。
　　Operation对象的优先级
　　上文中说了，操作队列里的Operation对象都是并发执行的，如果一个操作队列中有多个Operation对象，那么谁先执行谁后执行取决于Operation对象的依赖Operation对象是否已执行完成，也就是是否处于准备执行的状态。其实Operation对象自身也有优先级的属性，如果有两个都处于准备执行状态的Operation对象，那么优先级高的会先执行，优先级低的后执行。每个Operation对象默认的优先级是NSOperationQueuePriority.Normal级别，我们可以通过设置queuePriority属性更改Operation的在队列中执行的优先级，优先级别有以下五种：
　　NSOperationQueuePriority.Normal：正常优先级NSOperationQueuePriority.Low：低优先级NSOperationQueuePriority.VeryLow：非常低优先级NSOperationQueuePriority.High：高优先级NSOperationQueuePriority.VeryHigh：非常高优先级
　　这里我们需要注意一下Operation对象优先级的作用域，它只能作用于相同的操作队列中，不同操作队列中的Operation对象是不受优先级影响的。另外需要注意的是，如果有两个Operation对象，一个处于准备执行状态，但优先级比较低，另一个处于等待状态，但优先级比较高，那么此时仍然是处于准备执行状态的低优先级Operation对象先执行。可见Operation对象的优先级相互影响需要满足两个条件，一是必须处在同一个操作队列中，另一个是Operation对象都处于准备执行状态。
　　通过Operation对象修改线程优先级
　　通常情况下，线程的优先级由内核自己管理，不过在OS X v10.6及以后的版本和iOS4到iOS7期间，NSOperation多了一个threadPriority属性，我们可以通过该属性设置Operation对象运行所在线程的优先级，数值范围为0.0到1.0，数字越高优先级越高。不过可能是出于线程安全等方面的考虑，Apple从iOS8开始废除了该属性。
　　设置Completion Block
　　上篇文章中说过，Operation对象其中的一个特别好的特性就是完成时回调闭包Completion Block。它的作用不言而喻，就是当主要任务执行完成之后做一些收尾的处理工作，我们可以设置completionBlock属性给Operation对象添加完成时回调闭包：
　　blockOperationA.completionBlock = { print（“blockOperationA has finished.。.”） }
　　执行Operation对象
　　虽然前面文章的示例中已经包含了对Operation对象的执行，但是并没详细说明，这节就说说Operation对象的执行。
　　使用Operation Queue
　　使用Operation Queue操作队列执行Operation对象已然是标配选项了，操作队列在Cocoa框架中对应的类是NSOperationQueue，一个操作队列中可以添加多个Operation对象，但一次到底添加多少Operation对象得根据实际情况而定，比如应用程序对内存的消耗情况、内核的空闲情况等，所以说凡事得有度，不然反而会适得其反。另外需要注意的一点是不论有多少个操作队列，它们都受制于系统的负载、内核空闲等运行情况，所以说并不是说再创建一个操作队列就能执行更多的Operation对象。
　　在使用操作队列时，我们首先要创建NSOperationQueue的实例：
　　letoperationQueue = NSOperationQueue（）
　　然后通过NSOperationQueue的addOperation方法添加Operation对象：
　　operationQueue.addOperation（blockOperationA） operationQueue.addOperation（blockOperationB）
　　在OS X v10.6之后和iOS4之后，我们还可以用addOperations:waitUntilFinished：方法添加一组Operation对象：
　　operationQueue.addOperations（［blockOperationA， blockOperationB］， waitUntilFinished： false）
　　该方法有两个参数：
　　ops： ［NSOperation］：Operation对象数组。waitUntilFinished wait： Bool：该参数标示这个操作队列在执行Operation对象时是否会阻塞当前线程。
　　我们还可以通过addOperationWithBlock方法向操作队列中直接添加闭包，而不需要去创建Operation对象：
　　operationQueue.addOperationWithBlock（{ print（“The block is running in Operation Queue.。.”） }）
　　除了以上这几种添加Operation对象的方法外，还可以通过NSOperationQueue的maxConcurrentOperationCount属性设置同时执行Operation对象的最大数：
　　operationQueue.maxConcurrentOperationCount =2
　　如果设置为1，那么不管该操作队列中添加了多少Operation对象，每次都只运行一个，而且会按照添加Operation对象的顺序去执行。所以如果遇到添加到操作的队列的Operation对象延迟执行了，那么通常会有两个原因：
　　添加的Operation对象数超过了操作队列设置的同时执行Operation对象的最大数。延迟执行的Operation对象在等待它依赖的Operation对象执行完成。
　　另外需要的注意的是当Operation对象添加到操作队列中后，不要再更改它任务中涉及到的任何属性或者它的依赖，因为到操作队列中的Operation对象随时会被执行，所以如果你自以为它还没有被执行而去修改它，可能并不会达到你想要的结果。
　　手动执行Operation对象
　　除了用操作队列来执行Operation对象以外，我们还可以手动执行某个Operation对象，但是这需要我们注意更多的细节问题，也要写更多的代码去确保Operation对象能正确执行。在上篇文章中，我们创建过自定义的Operation对象，其中我们知道有几个属性特别需要我们注意，那就是ready、concurrent、executing、finished、cancelled，对应Operation对象是否出于准备执行状态、是否为异步并发执行的、是否正在执行、是否已经执行完成、是否已被终止。
　　这些状态在我们使用操作队列时都不需要理会，都有操作队列帮我们把控判断，确保Operation对象的正确执行，我们只需要在必要的时候获取状态信息查看而已。但是如果手动执行Operation对象，那么这些状态都需要我们来把控，因为你手动执行一个Operation对象时要判断它的依赖对象是否执行完成，是否被终止了等等，所以并不是简单的调用start方法，下面来看看如果正确的手动执行Operation对象：
　　func performOperation（operation： NSOperation）-》Bool { varresult = falseifoperation.ready && ！operation.cancelled { ifoperation.concurrent { operation.start（） } else{ NSThread.detachNewThreadSelector（“start”， toTarget： operation， withObject： nil） } result = true} returnresult }
　　终止Operation对象执行
　　一旦Operation对象被添加到操作队列中，这个Operation对象就属于这个操作队列了，并且不能被移除，唯一能让Operation对象失效的方法就是通过NSOperation的cancel方法终止它执行，或者也可以通过NSOperationQueue的cancelAllOperations方法终止在队列中的所有Operation对象。
　　暂停和恢复操作队列
　　在实际运用中，如果我们希望暂停操作队列执行Operation对象，可以通过设置NSOperationQueue的suspended属性为false来实现，不过这里要注意的是暂停操作队列只是暂停执行下一个Operation对象，而不是暂停当前正在执行的Operation对象，将suspended属性设置为true后，操作队列则恢复执行。
　　Dispatch Queues
　　Dispatch Queue是GCD中的核心功能，它能让我们很方便的异步或同步执行任何被封装为闭包的任务，它的运作模式与Operation Queue很相似，但是有一点不同的是Dispatch Queue是一种先进先出的数据结构，也就是执行任务的顺序永远等同于添加任务时的顺序。GCD中已经为我们提供了几种类型的Dispatch Queue，当然我们也可以根据需求自己创建Dispatch Queue，下面我们先来看看Dispatch Queue的类型：
　　串行Dispatch Queue：该类型的队列一次只能执行一个任务，当前任务完成之后才能执行下一个任务，而且可依任务的不同而在不同的线程中执行，这类队列通常作为私有队列使用。这里需要注意的是虽然该类型的队列一次只能执行一个任务，但是可以让多个串行队列同时开始执行任务，达到并发执行的任务的目的。并行Dispatch Queue：该类队列可同时执行多个任务，但是执行任务的顺序依然是遵循先进先出的原则，同样可依任务的不同而在不同的线程中执行，这类队列通常作为全局队列使用。主Dispatch Queue：该类队列实质上也是一个串行队列，但是该队列是一个全局队列，在该队列中执行的任务都是在当前应用的主线程中执行的。通常情况下我们不需要自己创建此类队列。
　　Dispatch Queue与Operation Queue相似，都能让我们更方便的实现并发任务的编程工作，并且能提供更优的性能，因为我们不再需要编写关于线程管理相关的一大堆代码，这些完全都有系统接管，我们只需要将注意力放在要执行的任务即可。举个简单的例子，如果有两个任务需要在不同的线程中执行，但是他们之间存在资源竞争的情况，所以需要保证执行的先后顺序，如果我们自己创建线程实现该场景，那么就务必要用的线程锁机制，确保任务有正确的执行顺序，这势必对系统资源的开销会非常大，如果使用Dispatch Queue，我们只需要将任务安正确的顺序添加到串行队列中即可，省时省力省资源。
　　任务的载体是闭包
　　在使用Dispatch Queue时，需要将任务封装为闭包。闭包就是一个函数，或者一个指向函数的指针，加上这个函数执行的非局部变量，闭包最大的一个特性就是可以访问父作用域中的局部变量。我们在将任务封装为闭包进行使用时要注意以下这几点：
　　虽然在闭包中可以使用父作用域中的变量，但是尽可能少的使用父作用域中比较大的变量以及不要在闭包中做类似删除清空父作用域中变量的行为。当将一个封装好任务的闭包添加至Dispatch Qeueu中，Dispatch Queue会自动复制该闭包，并且在执行完成后释放该闭包，所以不同担心闭包中一些值的变化问题，以及资源释放问题。虽然使用Dispatch Queue执行并发异步任务很方便，但是创建和执行闭包还是有一定资源开销的，所以尽量不要使用Dispatch Queue执行一些很小的任务，要物有所值。如果确实有很小的任务需要并发异步执行，那么使用NSThread的detachNewThreadSelector方法或NSObject的performSelectorInBackground方法去执行也未必不可。如果同一个队列中的多个任务之间需要共享数据，那么应该使用队列上下文去存储数据，供不同的任务访问。如果闭包中的任务创建了不少对象，那么应该考虑将整个任务逻辑代码放在autoreleasepool中，虽然Dispatch Queue中也有自动释放池，但是你不能保证它每次释放的时间，所以咱们自己再加一个要来的更保险一些。
　　创建与管理Dispatch Queues
　　在使用Dispatch Queue之前，我们首先需要考虑应该创建什么类型的Dispatch Queue，如何进行配置等，这一节就来说一说如何创建和管理Dispatch Queue。
　　全局并发Dispatch Queue
　　并发队列的好处人人皆知，可以方便的同时处理多个任务，在GCD中并发Dispatch Queue同样遵循先进先出的原则，但这只是在运行时适用，如果有个任务在并发队列中还没轮到它执行，那么此时完全可以移除它，而不必等它前面的任务执行完成之后。至于并发队列中没次有多少个任务在执行，这个恐怖在每一秒都在变化，因为影响它的因素有很多，所以之前说过，尽量不要移除移除已经添加进队列的任务。
　　OS X和iOS系统为我们提供了四种全局并发Dispatch Queue，所谓全局队列，就是我们不需要理会它们的保留和释放问题，而且不需要专门创建它。与其说是四种不如说是一种全局并发队列的四种不同优先级，因为它们之间唯一的不同之处就是队列优先级不同。与Operation Queue不同，在GCD中，Dispatch Queue只有四种优先级：
　　DISPATCH_QUEUE_PRIORITY_HIGH：高优先级。DISPATCH_QUEUE_PRIORITY_DEFAULT：默认优先级，低于高优先级。DISPATCH_QUEUE_PRIORITY_LOW：低优先级，低于高优先级和默认优先级。DISPATCH_QUEUE_PRIORITY_BACKGROUND：后台优先级，低于高优先级和后台线程执行的任务。
　　我们可以通过dispatch_get_global_queue函数再根据不同的优先级获取不同的全局并发队列，类型为dispatch_queue_t：
　　lethighPriorityQueue = dispatch_get_global_queue（DISPATCH_QUEUE_PRIORITY_HIGH， 0） letdefaultPriorityQueue = dispatch_get_global_queue（DISPATCH_QUEUE_PRIORITY_DEFAULT， 0）
　　我们在使用全局并发队列的时候不需要保留队列的引用，随时要用随时用该函数获取即可。当然我们也可以通过dispatch_queue_create函数自己创建队列：
　　letconcurrentQueue = dispatch_queue_create（“com.example.MyConcurrentQueue”， DISPATCH_QUEUE_CONCURRENT）
　　从上面代码可以看到，dispatch_queue_create函数有两个参数，第一个为队列的名称，第二个为队列类型，串行队列为DISPATCH_QUEUE_SERIAL，并发队列为DISPATCH_QUEUE_CONCURRENT。
　　串行Dispatch Queue
　　串行队列可以让我们将任务按照一定顺序执行，能更优的处理多个任务之间的资源竞争问题，比线程锁机制有更小的资源开销和更好的性能，并且不会产生死锁的问题。
　　系统也为我们提供了一个串行队列，我们可以通过dispatch_get_main_queue函数获取：
　　letmainQueue = dispatch_get_main_queue（）
　　该队列与当前应用的主线程相关联。当然我们也可以自己创建串行队列：
　　letserialQueueA = dispatch_queue_create（“com.example.MySerialQueueA”， DISPATCH_QUEUE_SERIAL） // 或者letserialQueueB = dispatch_queue_create（“com.example.MySerialQueueB”， nil）
　　dispatch_queue_create函数的第二个参数如果为nil则默认创建串行队列。当我们创建好串行队列后，系统会自动将创建好的队列与当前应用的主线程进行关联。
　　获取当前队列
　　如果需要验证或者测试当前队列，我们可以通过dispatch_get_current_queue函数获取当前队列。如果在闭包中调用，返回的是该闭包所在的队列，如果在闭包外调用，返回的则是默认的并发队列。不过该函数在OS X v10.10中和Swift中都不能使用了，取而代之的是通过DISPATCH_CURRENT_QUEUE_LABEL属性的get方法。
　　擅用队列上下文
　　很多情况下，同一个队列中的不同任务之间需要共享数据，尤其像串行队列中的任务，可能由多个任务对某个变量进行处理，或者都需要使用到某个对象，这时就要用到队列上下文：
　　import Foundation classTestDispatchQueue{func launch（） { let serialQueue = dispatch_queue_create（“com.example.MySerialQueue”， DISPATCH_QUEUE_SERIAL） dispatch_set_context（serialQueue， unsafeBitCast（0， UnsafeMutablePointer《Int》.self）） dispatch_async（serialQueue， { vartaskCount = unsafeBitCast（dispatch_get_context（serialQueue）， Int.self） taskCount++ print（“TaskA in the dispatch queue.。.and The number of task in queue is \（taskCount）”） dispatch_set_context（serialQueue， unsafeBitCast（taskCount， UnsafeMutablePointer《Int》.self）） sleep（1） }） dispatch_async（serialQueue， { vartaskCount = unsafeBitCast（dispatch_get_context（serialQueue）， Int.self） taskCount++ print（“TaskB in the dispatch queue.。.and The number of task in queue is \（taskCount）”） dispatch_set_context（serialQueue， unsafeBitCast（taskCount， UnsafeMutablePointer《Int》.self）） }） sleep（3） } } let testDispatchQueue = TestDispatchQueue（） testDispatchQueue.launch（）
　　从上面的代码示例中可以看到，在执行代码点，我们用dispatch_set_context函数向serialQueue队列的上下文环境中设置了一个Int类型的变量，初始值为0。该函数有两个参数，第一个是目标队列，第二个参数是上下文数据的指针。然后在闭包中我们使用dispatch_get_context函数获取上下文数据进行进一步的处理。除了基本类型，我们也可以将自定义的类放入队列上下文中：
　　importFoundation class Contact： NSObject { letname =“DevTalking”letmobile =“10010”} class TestDispatchQueue { letcontact =Contact（） func launch（） { letserialQueue =dispatch_queue_create（“com.example.MySerialQueue”， DISPATCH_QUEUE_SERIAL） dispatch_set_context（serialQueue， unsafeBitCast（contact， UnsafeMutablePointer《Void》.self）） dispatch_async（serialQueue， { letcontact =unsafeBitCast（dispatch_get_context（serialQueue）， Contact.self） print（“The name is \（contact.name）”） sleep（1） }） dispatch_async（serialQueue， { letcontact =unsafeBitCast（dispatch_get_context（serialQueue）， Contact.self） print（“The name is \（contact.mobile）”） }） sleep（3） } } lettestDispatchQueue =TestDispatchQueue（） testDispatchQueue.launch（）
　　关于unsafeBitCast函数和Swift中指针的用法在这里可以有所参考。
　　队列的收尾工作
　　虽然在ARC时代，资源释放的工作已经基本不需要我们手动去做了，但有些时候因为系统释放资源并不是很及时，也会造成内存移除等问题，所以在一些情况下我们还是需要进行手动释放资源的工作，必入添加autoreleasepool保证资源及时释放等。Dispatch Queue也给我们提供了这样的机会（机会针对于ARC时代，在MRC时代是必须要做的），那就是Clean Up Function清理扫尾函数，当队列被释放时，或者说引用计数为0时会调用该函数，并且将上下文指针也传到了该函数，以便进行清理工作：
　　importFoundation class Contact： NSObject { letname =“DevTalking”letmobile =“10010”} class TestDispatchQueue { letcontact =Contact（） func testCleanUpFunction（） { launch（） sleep（15） } func launch（） { letserialQueue =dispatch_queue_create（“com.example.MySerialQueue”， DISPATCH_QUEUE_SERIAL） dispatch_set_context（serialQueue， unsafeBitCast（contact， UnsafeMutablePointer《Void》.self）） dispatch_set_finalizer_f（serialQueue， myFinalizerFunction（）） dispatch_async（serialQueue， { letcontact =unsafeBitCast（dispatch_get_context（serialQueue）， Contact.self） print（“The name is \（contact.name）”） sleep（1） }） dispatch_async（serialQueue， { letcontact =unsafeBitCast（dispatch_get_context（serialQueue）， Contact.self） print（“The name is \（contact.mobile）”） }） sleep（3） } func myFinalizerFunction（） -》 dispatch_function_t { return{ context inletcontact =unsafeBitCast（context， Contact.self） print（“The name is \（contact.name） and the mobile is \（contact.mobile）， The serialQueue has been released and we need clean up context data.”） // TODO.。. } } } lettestDispatchQueue =TestDispatchQueue（） testDispatchQueue.testCleanUpFunction（）
　　从上面的代码示例中可以看到当给队列设置完上下文时，我们使用了dispatch_set_finalizer_f函数给队列设置清理函数，dispatch_set_finalizer_f函数有两个参数，第一个是目标队列，第二个参数是类型为dispatch_function_t的函数指针，也就是清理函数，上下文数据指针是该函数唯一的参数。在上面代码中，我们添加了myFinalizerFunction函数作为清理函数，在该函数中获得上下文数据，然后进行后续的清理工作。