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 第三方支付
1.封裝訂單模型 alixpayorder order alixpayorder alloc init 生成訂單描述 nsstring orderspec order description 2.簽名 idsigner creatersadatasigner 私鑰key 傳入訂單描述 進行 簽名 n...
iOS 第三方庫
afnetworking 網路請求元件 fmdb 本地資料庫元件 sdwebimage 多個縮圖快取元件 uickeychainstore 存放使用者賬號密碼元件 reachability 監測網路狀態 datetools 友好化時間 mbprogresshud 一款提示框第三方庫 mwphotob...
ios 第三方登入
ios 第三方登入通常的做法是，1.登入後，獲得第三方的uid，呼叫伺服器登入介面，如伺服器返回無此使用者，轉2，有此使用者，轉3.2.伺服器返回無此使用者，需完善使用者資料，如果完成，則在伺服器建立與第三方uid對應的使用者。3.登入成功。以微博登入為例，登入後得到uid和accesstoken，...