1. 網路圖片顯示大體步驟:

下載圖片
圖片處理（裁剪，邊框等)
寫入磁碟
從磁碟讀取資料到核心緩衝區
從核心緩衝區複製到使用者空間(記憶體級別拷貝)
解壓縮為點陣圖（耗cpu較高）
如果點陣圖資料不是位元組對齊的，CoreAnimation

另外一種解決方案是：

imageView物件和圖片的url相關聯，在滑動時，不取消舊的下載任務，而是在下載任務完成回撥時，進行url匹配，只有匹配成功的image會重新整理imageView物件，而其他的image則只做快取操作，而不重新整理UI。

同時，仍然管理一個執行佇列，為了避免佔用太多的資源，通常會對執行佇列設定一個最大的併發量。此外，為了保證LIFO

2.3 關於位元組對齊

SDWebImage與AFNetworking都沒有對第7點做優化，FastImageCache相對與其他的開源庫，則對第5點與第7點做了優化。這裡我們談談第七點，關於圖片資料的位元組對齊。

Core Animation在某些情況下渲染前會先拷貝一份影象資料，通常是在影象資料非位元組對齊的情況下會進行拷貝處理，官方文件沒有對這次拷貝行為作說明，模擬器和Instrument裡有高亮顯示“copied images”的功能，但似乎它有bug，即使某張圖片沒有被高亮顯示出渲染時被copy，從呼叫堆疊上也還是能看到呼叫了CA::Render::copy_image方法：

那什麼是位元組對齊呢，按我的理解，為了效能，底層渲染影象時不是一個畫素一個畫素渲染，而是一塊一塊渲染，資料是一塊塊地取，就可能遇到這一塊連續的記憶體資料裡結尾的資料不是影象的內容，是記憶體裡其他的資料，可能越界讀取導致一些奇怪的東西混入，所以在渲染之前CoreAnimation要把資料拷貝一份進行處理，確保每一塊都是影象資料，對於不足一塊的資料置空。大致圖示：(pixel是影象畫素資料，data是記憶體裡其他資料)

塊的大小應該是跟CPU cache line有關，ARMv7是32byte，A9是64byte，在A9下CoreAnimation應該是按64byte作為一塊資料去讀取和渲染，讓影象資料對齊64byte就可以避免CoreAnimation再拷貝一份資料進行修補。FastImageCache做的位元組對齊就是這個事情。

從程式碼上來看，主要是在建立上圖解碼的過程中，CGBitmapContextCreate

2.6 其他（諸如圖片預下載，gif支援等等,下載進度條）

待補充

3. 常用的開源庫對比

tip	SDWebImage	AFNetworking	FastImageCache
非同步下載圖片	YES	YES	NO
子執行緒解壓縮	YES	YES	YES
子執行緒圖片處理(縮放，圓角等)	YES	YES	YES
儲存解壓縮後的點陣圖	YES	YES	YES
記憶體級別快取	YES	YES	YES
磁碟級別快取	YES	YES	YES
UIImageView category	YES	NO	NO
減少記憶體級別的拷貝	NO	NO	YES
介面易用性	***	***	*