需求

在AVFoundation Framework中的Camera Preview Callback回调中将CVPixelbuffer存储到Local Document，PixelFormmat为kCVPixelFormatType_32BGRA

环境

1、iphone X
2、swift 4.0

步骤

1、cvpixelbuffer convert to uiimage
2、uiimage convert to NSData
3、NSData write to .png file

结果

1、单帧耗时500ms以上；
2、CPU usage：200%以上；
3、Memory usage：100M左右
总结：慢、卡、热--->crash

分析

经过检测，罪魁祸首为UIImagePNGRepresentation()，该方法通过无损压缩方式将获取到的image转化为binary data，并且会重新开辟堆内存，相当于深拷贝，属于image的binary copy，最后将binary copy直接write into .png文件，并且copy的过程中其内部将会产生大量的临时缓存，当runloop进入下一次循环之前缓存数据都无法得到释放，请看代码段 fragment 1:

DispatchQueue.global().async 
{
    autoreleasepool 
    {                    
        let image = self.imageFromPixelBuffer(pixelBuffer: depthPixelBuffer).fixedOrientation().rotate(radians: Float(90.0*Double.pi/180.0))
        let imageData = UIImagePNGRepresentation(image!)
        let rgbFolderPath = self.getFolderPath(imagePath: "RGBImages")
        let rgbFolderURL = NSURL.fileURL(withPath: rgbFolderPath)
        var fileName = self.currentTime
        fileName.append(".png")
        let imageURL = rgbFolderURL.appendingPathComponent(fileName)                    
        try! imageData?.write(to: imageURL)
    }
}

该并发队列由于位于preview callback的回调之中，所以将会异步不断执行，由于上述分析的内存无法及时释放，并且不断累积调用，所以导致内存、CPU都处于增长状态，运行时间长了就crash，如何解决呢？

解决
经过研究发现，apple的ImageIO框架可以解决该问题；原理是绕过uiimage convert to NSData这个环节，直接将image的内存数据写入png文件，这样就规避了数据转换导致的开销，请看代码 fragment 2：

DispatchQueue.global().async
{
      autoreleasepool 
       {
             let image = self.imageFromPixelBuffer(pixelBuffer: videoPixelBuffer).fixedOrientation().rotate(radians: Float(90.0*Double.pi/180.0))                    
             let rgbFolderPath = self.getFolderPath(imagePath: "RGBImages")
             let rgbFolderURL = NSURL.fileURL(withPath: rgbFolderPath)
             var fileName = self.currentTime
             fileName.append(".png")
             let imageURL = rgbFolderURL.appendingPathComponent(fileName)
             self.saveFile(fileUrl: imageURL, image: image!, fileType: kUTTypePNG)
       }
}

private func saveFile (fileUrl:URL, image:UIImage, fileType:CFString)
{
       let url = fileUrl as CFURL
       let destination = CGImageDestinationCreateWithURL(url, fileType, 1, nil);
       if nil==destination {return}
       CGImageDestinationAddImage(destination!, image.cgImage!, nil)
       CGImageDestinationFinalize(destination!)
}

结果发现，使用ImageIO框架之后，内存与CPU的确有大幅降低，CPU：70～80%； Memory：<50M，毕竟iphone X的RGB Image，转换得到的图很大，差不多4M，难怪UIImagePNGRepresentation吃不消，如果图在质量很小的情况下，应该问题不大，但设备分辨率越高，图像质量将会越高，抓拍到的frame质量会越高，这种情况则需要使用ImageIO处理。

可是问题依然没有结束！
虽然内存和CPU的占比得到了较大优化，但是运行时间长了，依然会爆。还有什么其他原因吗？

好吧，不卖关子，原因是，我们处于异步队列中！

就是说，当前帧正在写当中，下一帧又进来了，当前帧并未完全结束，所以资源未被完全释放掉，所以大量垃圾阻塞在系统当中，导致程序crash。有人问不是添加了autorelease机制吗？并且还是ARC模式，种种因素加起来不是会自动管理内存资源吗？为什么？其实系统的确在帮我们释放资源，只不过最终的问题是，我们创建资源的速度超过了系统释放的速度，本质上不存在leaks，这是一种变异的泄漏，leaks的本质是泄漏之后系统内存无法回收，并且可能导致严重的crash，而此处紧紧只是内存回收产生滞后，处理速度跟不上，只要速度能跟上，消除其中的时间差就不会产生泄漏。两者本质不一样。

那如何解决呢？
很简单，加锁，或者添加信号量，只要标记当前帧已经完全处理结束才能进行下一帧的处理，此处代码很简单，不再罗列。