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]。