GCD没你想的那么好，被魔化的GCD和被忽略的NSOperationQueue

实测：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 ，开启多个线程，并发执行。

{number = 33, name = (null)}
{number = 46, name = (null)}
{number = 44, name = (null)}
{number = 9, name = (null)}
4.229893922805786

---

内存开销情况：耗瞬间可到5G多，如图已达4.4G

图1.png

---

二、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 ，开启多个线程，并发执行。

{number = 18, name = (null)}
{number = 14, name = (null)}
{number = 17, name = (null)}
{number = 7, name = (null)}
{number = 15, name = (null)}
{number = 8, name = (null)}
4.2739338874816895

---

内存开销情况：处理过程中稳定在500MB ~ 900MB。

图2.png

---

测试结果表：

我做了表格对比，第二组数据不贴图了。如下:

第一组： 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左右，已经达到非常高效了，算是完美了，满足了我对产品需求。当然，优化无止境 ~。