iOS第三方做滤镜最主流的开源框架GPUImage

GPUImage是现在iOS做滤镜最主流的开源框架。作者BradLarson基于openGL对图片处理单元进行封装，提供出GPUImageFilter基类，配合shader，常用滤镜都拿下不是问题。  GPUImage中的有几个概念：

⁃ output，输出源

⁃ intput，输入源

⁃ filter，滤镜

所以一个完整的滤镜处理流程是: output+X+input，X就是滤镜组(1+个滤镜)。GPUImage为了方便，新版本中提供了GPUImageFilterPipeline 这个东西，方便用户使用多个滤镜组合，不用担心前后的链式逻辑。

GPUImage将图片滤镜处理和动态滤镜分开了，动态滤镜是按照上面那个流程，但图片处理却是以(output+filter)*X + input这种逻辑。如果处理一张图片的效果需要用到多个滤镜组合，用一个滤镜生成一张图片output，然后传给下一个滤镜处理,这个过程中如果滤镜叠加次数比较多，或者这个滤镜效果被调用多次，这样消耗的内存是特别大的，每个滤镜处理后导出的图片output都存在内存中，如果原图特别大，估计内存要爆了。

如果都是以output+X+input这种模式来处理的，这样代码逻辑单一，效率高，吃内存也没那么多。看了源码知道output +X+ input ，当X为多个时，上个滤镜n处理得到的纹理，还存在GPU显存中，GPU直接将这张纹理传给了n+1作为其output，这样整个滤镜流程下来，只有一张纹理内存的占用。

以这条线来走，过程中基本就没遇到什么问题，只是代码结构设计和封装耗时。项目里，发现滤镜模块调用完了以后，内存上去了下不来，反复检查，所有GPUImage相关元素都已经释放了。后来想到了显存，arc环境下，只负责回收oc对象的内存，显存自然需要GPUImage使用者自己来回收，这样也就容易了，翻GPUImage的api，知道

GPUImageContext中有个framebufferCache：

 

[[GPUImageContextsharedImageProcessingContext].framebufferCachepurgeAllUnassignedFramebuffers]。

 

 

 

转载于:https://www.cnblogs.com/canghaixiaoyuer/p/4713021.html