需求
在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，而此处紧紧只是内存回收产生滞后，处理速度跟不上，只要速度能跟上，消除其中的时间差就不会产生泄漏。两者本质不一样。
那如何解决呢？
很简单，加锁，或者添加信号量，只要标记当前帧已经完全处理结束才能进行下一帧的处理，此处代码很简单，不再罗列。
网友评论