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

 

 

 

iOS第三方做濾鏡最主流的開源架構GPUImage