原文地址:https://blog.csdn.net/jcp312097937/article/details/45849341
GPUImage是现在做滤镜最主流的开源框架，没有之一。作者BradLarson基于openGL对图片处理单元进行封装，提供出GPUImageFilter基类，配合shader，常用滤镜都拿下不是问题。
下面大致讲解下GPUImage里的一些基本概念，为了表达方便。已经知道请跳过
GPUImage中的几个概念
output为输出源
intput为输入源
filter为滤镜
所以一个完整的滤镜处理流程是这样的:output+X+input，X就是滤镜组(1+个滤镜)。GPUImage为了方便，新版本中提供了GPUImageFilterPipeline 这个东东，方便用户使用多个滤镜组合，不用担心前后的链式逻辑。
GPUImage作者将图片滤镜处理和动态滤镜是分开了的，动态滤镜是按照上面那个流程，但图片处理却是以(output+filter)*X + input这种逻辑。如果处理一张图片的效果需要用到多个滤镜组合，用一个滤镜生成一张图片output，然后传给下一个滤镜处理,这个过程中如果滤镜叠加次数比较多，或者这个滤镜效果被调用多次，这样消耗的内存是贴别大的，每个滤镜处理后导出的图片output都存在内存中，如果原图特别大，那么恭喜。。估计内存要爆了。
我在做滤镜app的时候，都是以output+X+input这种模式来处理的，这样代码逻辑单一，效率高，吃内存也没那么多。看了源码知道output +X+ input ，当X为多个时，上个滤镜n处理得到的纹理，还存在GPU显存中，GPU直接将这张纹理传给了n+1作为其output，这样整个滤镜流程下来，只有一张纹理内存的占用。
以这条线来走，过程中基本就没遇到什么问题，只是代码结构设计和封装耗时。最后滤镜模块做完实用到项目里，发现滤镜模块调用完了以后，内存上去了下不来，我遇到了这问题时，反复检查，所有GPUImage相关元素都已经释放了，那么增加的内存是哪儿来的呢？后来想到了显存，arc环境下，只负责回收oc对象的内存，显存自然需要GPUImage使用者自己来回收
IOS处理方法
GPUImageContext中有个framebufferCache
[[GPUImageContextsharedImageProcessingContext].framebufferCachepurgeAllUnassignedFramebuffers]。
安卓处理方法