实测：GCD远远没你想的那么好，而NSOperationQueue综合各方面简直不要太舒服。
技术市场背景：线程方面，目前GCD家喻户晓，都知道它是最高效的，是个做苹果软件开发的都在用，我也用，确实方便简洁。而NSOperationQueue确实是个冷板凳，用得少。现在说一下「多线程并发异步处理」这种场景，GCD远远没你想的那么好。
背景：最近在优化一款图片压缩软件uPic，每次用户拖进图片时，会做预处理。需要读取原图，将原图生成100 * 100px缩略图，提供任务列表显示使用。但任务过多时，耗时严重，用户长久等待，造成软件假死状态，文件多而且大时，比如处理1GB图片，接近20s假死。甚至有影楼一次处理好几G的图片，就耗时更长了。遇到了问题需要解决，那么就产生了新需求
需求：提升图片处理效率，减少用户等待时间，提升用户体验。
方案：只用到了单一的主线程，确实缺点很大。那么就采用多线程处理，充分发挥多核CPU优势，提升处理效率，同时加入过渡等待动画。
机器：2018年MacBook Pro 15寸高配版（CPU 6核）。
两组图片：
第一组： 46张高清摄影照片，磁盘存储空间：402MB。
第二组：1600多张小图，磁盘存储空间：大概几十MB。
结果：经过优化，耗时任务效率提升4倍，之前处理1G图片大概20s，现在仅为5s左右，也就说仅仅用到之前1/4时间，提升效果是非常惊人的。
然而以上都不是重点，重点是实践过程与得出的结论，理解的加深，对以后技术方案选型非常有帮助。
技术点就不说了，不清楚的同学点多线程深度解析，也可以参考GCD和NSOperation。
现在咱们来点实际的，对比了GCD和NSOperationQueue
对比两套代码
一、使用GCD，多线程并发模式
let begin = Date()
let group = DispatchGroup()
let queue = DispatchQueue(label: "com.queue",attributes: .concurrent) //并发多线程处理 45张艺术照处理 17s 减少至 4s
for file in files {
queue.async(group: group) {
if let task = self.executeTaskHandle(file) { //耗时任务
objc_sync_enter(self)
tasks.append(task)
objc_sync_exit(self)
}
debugPrint(Thread.current)
}
}
group.wait()
let end = Date()
let interval = end.timeIntervalSince1970 - begin.timeIntervalSince1970
debugPrint(interval)
耗时：4.229s ，开启多个线程，并发执行。
<NSThread: 0x6000018d2600>{number = 33, name = (null)}
<NSThread: 0x600001893b80>{number = 46, name = (null)}
<NSThread: 0x60000188de00>{number = 44, name = (null)}
<NSThread: 0x600001828900>{number = 9, name = (null)}
4.229893922805786
内存开销情况：耗瞬间可到5G多，如图已达4.4G
二、NSOperationQueue 多线程并发
let begin = Date()
let queue = OperationQueue()
queue.maxConcurrentOperationCount = 6
for file in files {
queue.addOperation {
if let task = self.executeTaskHandle(file) { //耗时任务
objc_sync_enter(self)
tasks.append(task)
objc_sync_exit(self)
}
debugPrint(Thread.current)
}
}
queue.waitUntilAllOperationsAreFinished()
let end = Date()
let interval = end.timeIntervalSince1970 - begin.timeIntervalSince1970
debugPrint(interval)
耗时：4.27s ，开启多个线程，并发执行。
<NSThread: 0x600001859f80>{number = 18, name = (null)}
<NSThread: 0x6000017ffc80>{number = 14, name = (null)}
<NSThread: 0x6000018aae40>{number = 17, name = (null)}
<NSThread: 0x6000017c5800>{number = 7, name = (null)}
<NSThread: 0x600001858b40>{number = 15, name = (null)}
<NSThread: 0x6000017cfbc0>{number = 8, name = (null)}
4.2739338874816895
内存开销情况：处理过程中稳定在500MB ~ 900MB。
测试结果表：
我做了表格对比，第二组数据不贴图了。如下:
第一组： 46张高清摄影照片，磁盘存储空间：402MB。结果表：
| 主线程 | GCD | NSOperationQueue | |
|---|---|---|---|
| 耗时 | 16.52s | 4.229s | 4.273s |
| 内存 | 慢慢上升可达5G | 瞬间可达5G | 800MB稳定 |
| 线程数 | 1个 | 动态分配（cup核心数） | 动态6个(设置max数) |
| 异常问题 | 无 | 偶尔有，同步锁可解决 | 极少有，同步锁可解决 |
第二组：1600多张小图，磁盘存储空间：大概几十MB。结果表：
| 主线程 | GCD | NSOperationQueue | |
|---|---|---|---|
| 耗时 | 5.17s | 1.285s | 1.293s |
| 内存 | 可达700MB | 瞬间可达800MB | 200MB左右 |
| 线程数 | 1个 | 动态分配（cup核心数） | 动态6个(设置max数) |
| 异常问题 | 无 | 偶尔有，同步锁可解决 | 极少有，同步锁可解决 |
关于同步锁：
说到多线程，那就少不了同步锁，Swift var资源用 objc_sync_enter() 和objc_sync_exit()，Objective-C用@synchronized() { }
如果不加同步锁，偶尔会出现如下异常错误：
1、malloc: Heap corruption detected, free list is damaged at 0x600000fb42d0
2、 Fatal error: UnsafeMutablePointer.deinitialize with negative count
3、Thread 83: EXC_BAD_ACCESS (code=1, address=0x3eadddea39a0)
对比细说GCD优势：
1、GCD效率确实比NSOperationQueue 快上那么一点点
2、灵活的队列配置，太TM灵活了
3、更底层
4、GCD神化，代码高逼格点
GCD劣势：
1、无法设置并发个数，当然也可以通过 DispatchSemaphore去做，相对麻烦些
2、并发任务产生的内存高，内存回收慢，group执行完才回收。
对比细说NSOperationQueue优势
1、可设置最大并数，可取消，可挂起。
2、与CGD效率相差很小，几乎可以忽略不计。
3、内存消耗稳定，内存回收及时。
4、从产品角度来说这是绝佳，既加速处理，又稳定性极佳，最优选择。
NSOperationQueue劣势：
也就只能说，冷门点了，无劣势。
关键点：
表现：NSOperationQueue的 maxConcurrentOperationCount 不设置默认为无序group执行，纯异步并发CGD一样。
设置了大于1，表现为第一组表现为maxCount的串行并发，实测过程中，第一组是异步并发，后续才为串行并发。内存回收机制也是基于maxCount 线程数边执行边回收，不像GCD必须等到group中所有任务执行完才进行回收。
总结
两者比较：GCD与NSOperationQueue执行效率非常接近，但内存开销NSOperationQueue完胜。
适用场景：
GCD：多数处理时间短，内存开销小的任务，低并发任务。比如网络请求、数据模型转化，监听......等。
NSOperationQueue：通用性比较强，尤其在处理高内存开销绝对优势。比如大量图片处理、音视频帧合成、滤镜处理......等。
「多线程并发异步处理」这种场景，也许是我的例子极端点，动不动就处理几百兆甚至几G的数据，把GCD问题暴露放大了，但这就是事实，实践得真理，感悟才更深。刀与剑都可杀人，但场景优劣不一样，什么时候用刀，什么时候用剑，心中有杆秤。
总的来说，做开发的，都知道NSOperationQueue是基于GCD封装，但苹果技术人员封装真的厉害，经过大量实践测试，才放出的API，这块得有空去得看看源码。当然CGD也有也有很多第三方库可选择，可控制并发数与挂起操作，我知道GCD效率高，也相信使用第三方库会更简洁便利，但我不会用，有NSOperationQueue就能满足所有需求。另外一个重要原因：用得多，错得多，尽量使用原生API。
就像以前，在做高德地图一样，整个项目几乎不用轮子，都团队内部自己写，出任何问题都可控，才有 十万分之7的闪退概率，远远低于业界平均水平，稳定性非常高。
2019.6.10「后续优化」
即上次多线程优化后，今天再次更新，再次对本项目做了优化，效果显著。结果如下表格：
| 原始 | 线程优化后 | 采用Image IO 优化后 | |
|---|---|---|---|
| 第一组图片 耗时 | 16.52s | 4.229s | 0.786s |
| 内存 | 慢慢上升可达5G | 800MB稳定 | 200MB稳定 |
想法策略：对于之前先读取图片二进制，再生成缩略图逻辑，图片读取与解码生成Image也是一个消耗高的操作。那么我可以免去了图片先解码，采用了Image IO读取图片，直接生成缩略图，效率基于上次结果，再次提高5倍左右 。相当于与最初相比，提高了20倍，效果太惊人了，我都有点不敢相信。在生成缩略图效果相比，Image IO 比 CoreImage高效太多。
代码如下：
//此方式，内存大大优化 800MB 减少到 200MB，而且更快。 时间更是比 读取Image再转 缩小到 1/4
class func thumbnail(maxSize:Float, url:URL) -> NSImage? {
//生成CGImageSourceRef 时，不需要先解码。
let imageSourceOptions = [kCGImageSourceShouldCache: false] as CFDictionary
let imageSource = CGImageSourceCreateWithURL(url as CFURL, imageSourceOptions)!
let maxDimensionInPixels = max(maxSize, maxSize)
//kCGImageSourceShouldCacheImmediately
let options = [kCGImageSourceCreateThumbnailFromImageAlways: true,
kCGImageSourceShouldCacheImmediately: false,
kCGImageSourceCreateThumbnailWithTransform: true,
kCGImageSourceThumbnailMaxPixelSize: maxDimensionInPixels] as CFDictionary
//生成
if let image = CGImageSourceCreateThumbnailAtIndex(imageSource, 0, options) {
return NSImage(cgImage: image, size: NSSize(width: image.width, height: image.height))
}
return nil
}
目前处理几百MB - 1GB图片，基本1 - 2s左右，已经达到非常高效了，算是完美了，满足了我对产品需求。当然，优化无止境 ~。
