下圖是一個客戶端圖片加載模塊常見的處理流程。
本文以UniversalImageLoader為例分析了這一流程，然后分析了Fresco的優勢和問題，最終推薦大家使用Glide。
從UniversalImageLoader分析圖片加載中需要處理的問題
網絡
主要用于下載網絡圖片，在UIL中是將圖片地址變為InputStream。UIL支持多種類型來源的圖片顯示，包括：
- 網絡
- 文件
- Uri資源（如果是視頻，會找到縮略圖顯示）
- assets
- drawable
緩存
- UIL使用兩級緩存：磁盤緩存圖片文件、內存緩存Bitmap
- UIL已經實現了多種緩存策略，但一般都使用LRU緩存
- UIL可以指定圖片緩存的路徑，和緩存文件名的生成規則
- 需要自己確定緩存的大小，確定內存緩存的大小尤其重要
- 通過
ActivityManager#getMemoryClass或Runtime.getRuntime().maxMemory()獲得單個應用的最大內存（前者單位為MB，后者單位為B），一般最多劃分1/4的最大內存，否則容易導致OOM。 - 圖片較多，大圖較多的應用，需要使用較大的緩存，提高緩存的命中率
- 內存也不宜太小，最少應該能緩存2~3個屏幕大小的Bitmap
- 通過
解碼
- 要按需解碼，否則會造成內存的浪費，主要通過
options.inJustDecodeBounds進行預解析 - ImageAware可以幫助控制解碼圖片的大小，ImageViewAware就是對ImageView的一個封裝
- 注意照片方向Exif，避免圖片錯誤旋轉
顯示
實現接口BitmapDisplayer可以自定義顯示效果，已實現的包括：帶描邊的圓形、漸入、圓角矩形（不能四個角分別指定）等。
某些設計可能會出現兩個角圓角、另外兩個直角的特殊裁剪模式。自己實現這類Displayer時，不要生成一個新的Bitmap，定義一個Drawable會更高效。因為生成新的Bitmap會引起內存分配和回收，從而使GC更加頻繁，而Drawable只是在繪制時會使用很少的計算資源?？梢詤⒖荚创a中RoundedBitmapDisplayer。
多線程
圖片的下載和解碼都需要再后臺線程中處理，而且為了提高效率，一般都使用多個線程分別進行解碼和網絡請求。
共有三個Executor，分別用于
- 分發任務
- 處理已緩存圖片
- 處理未緩存圖片
已緩存的圖片主要占用計算資源，未緩存的圖片則主要占用網絡資源，所以不應該在一個Executor中競爭?？梢苑謩e指定Executor的線程數量，UIL默認為3個。
監聽
UIL向外提供了兩類監聽：ImageLoadingListener和ImageLoadingProgressListener
PauseOnScrollListener主要用于，在列表滾動時暫停圖片加載，但在現在的RecyclerView中無法使用。需要自己使用ImageLoader#pause和ImageLoader#resume
了解了UIL是如何處理圖片加載的問題之后，其他的第三方庫也都是大同小異，下面再介紹下Fresco和Glide。
Fresco的優勢和問題
Fresco在解決圖片加載問題上的思路和其他框架有很大的不同。它最大的問題有兩個：
- 不能直接使用ImageView：這個問題對于老項目的重構幾乎是致命的。
- 需要指定寬高：指定寬高對于圖片加載其實是一件好事，但在加載網絡圖片的時候需要服務端告知原圖的尺寸，才能幫助客戶端實現更好的體驗。
相比UIL，它的優點主要包括：
- 5.0以下的系統上，使用ASHMEM，不會占用Java堆內容
- 多一級未解碼圖片的內存緩存，減少文件IO（很多Android機器使用1年之后變慢，很大的原因就是IO變慢了，所以這一優化的效果還是很顯著的）
- 支持多圖請求，可以在大圖顯示之前展現縮略圖
- 支持Gif動畫和漸進式JPEG（圖片還未下載完成的時候就可以先顯示一部分）
更多關于Fresco的特點可以參考Android圖片加載開源庫深度推薦，安利Fresco
緩存和網絡：Image Pipeline
在5.0系統以下，Image Pipeline 使用 pinned purgeables 將Bitmap數據避開Java堆內存，存在ASHMEM中。這要求圖片不使用時，要顯式地釋放內存。SimpleDraweeView自動處理了這個釋放過程，所以沒有特殊情況，盡量使用SimpleDraweeView。
顯示
修改圖片的顯示效果需要使用DraweeHolder，它不僅能控制圖片的顯示，還可以處理View的Touch事件。默認支持圓角和圓形。
另一個控制圖片顯示的方法是在Postprocessor中修改Bitmap，但效率很低。
監聽
- ControllerListener：監聽圖片顯示的過程
- RequestListener：監聽圖片獲取的過程
Glide是個不錯的選擇
優點
- 支持本地Video
- 分別控制每次請求的優先級
- 支持縮略圖
- 可直接更新AppWidget和Notification中的圖片
- 自定義圖片轉換效果，還可使用GPU轉換（使用GPU處理圖片變換，并保持到緩存文件中，在Demo中可以看到GPU變換的10種特效）
- 定義加載動畫
- 很方便的使用圖片裁剪服務
- 使用Bitmap回收池，減少系統gc
可參考Glide相關文章了解怎么通過自定義的GlideModule優化加載的圖片。本文也提供給了參考代碼，在代碼中引入七牛裁圖服務，同時也可體驗10種GPU變化的特效。
關于Transformation和BitmapImageViewTarget的使用
-
Transformation#transform：在緩存前對圖片進行處理，處理之后的圖片才會進行緩存。處理圖片的過程中會產生額外的內存消耗，處理后的圖片會占據獨立的緩存空間。但第二次使用的時候，不再需要處理，直接從緩存中讀取。 -
BitmapImageViewTarget#setResource：控制圖片的顯示邏輯，每次顯示的時候都會處理。因此在setResource中應該定義特殊的Drawable來控制顯示效果，而不應該對Bitmap進行處理。（Bitmap的頻繁生成和回收會導致gc；Drawable是在繪制的時候，通過Paint設置特殊的繪制效果，不會產生新的Bitmap）
關于Bitmap的回收機制
系統的Bitmap內存管理機制隨著Android系統的演進可以分為三個階段，關于這部分可以參考官網文章Managing Bitmap Memory。
- 2.3.3及以下：Bitmap的像素數據存儲在native內存中，但依舊會計算在一個進程的內存上限之中。
- 3.0~4.4：Bitmap的像素數據存儲在Java堆內存中，解碼Bitmap時可以通過
Options#inBitmap復用不再使用的Bitmap，從而減少系統gc。但要求被復用的Bitmap和新Bitmap的像素數據一樣大。 - 5.0及以上：對于復用Bitmap的限制不再嚴格要求一樣大，只要別復用的Bitmap的像素數據不小于新Bitmap即可。
如有興趣，可參考筆者的另一篇文章了解《Glide如何通過引用計數復用Bitmap》
Android系統使用的內存除了native heap和Java heap以外，還有ASHMEM。在5.0之前可以通過Options#inPurgeable將Bitmap的數據存儲在ASHMEM中，從而不占據一個進程的內存上限。
BitmapFactory.Options = new BitmapFactory.Options();
options.inPurgeable = true;
Bitmap bitmap = BitmapFactory.decodeByteArray(jpeg, 0, jpeg.length, options);
關于Android系統中三種內存的和Bitmap的關系可以參考Introducing Fresco: A new image library for Android
