glide(底層)：HttpUrlConnection
Glide默認使用
HttpUrlConnection進行網絡請求Google推薦的圖片加載庫，專注於流暢的滾動。
1.優點
1）使用RGB_565，內存佔用比Picasso小一半。
2）圖片展示和頁面的生命週期一致（對context有類型要求）
3）相比Picasso，Glide在緩存策略和加載GIF方面略勝一籌
減少了緩存文件的大小
Picasso和Glide在磁盤緩存策略上有很大的不同。Picasso緩存的是全尺寸的，而Glide緩存的是跟ImageView尺寸相同的。 這樣在下次顯示的時候不需要重新調整大小，顯示的會更快。
4）在頁面不可見時停止網絡請求，停止對圖片的解析操作。
5）專注於流暢的滾動
6）當列表在滑動的時候，調用pauseRequests()取消請求，滑動停止時，調用resumeRequests()恢復請求。這樣是不是會好些呢？
7）支持當你想清除掉所有的圖片加載請求時
8）同時因爲Glide和Activity/Fragment的生命週期是一致的，因此gif的動畫也會自動的隨着Activity/Fragment的狀態暫停、重放。Glide 的緩存在gif這裏也是一樣，調整大小然後緩存。
9）支持gif
但是從我的一次測試結果來看Glide 動畫會消費太多的內存，因此謹慎使用。
10）Glide還可以將任何的本地視頻解碼成一張靜態圖片。
11）使用glide，你可以配置圖片顯示的動畫，而Picasso只有一種動畫：fading in。
12）可以使用thumbnail()產生一個你所加載圖片的thumbnail。
2.缺點
1）Glide 功能強大，但代碼量大、流轉複雜。在較深掌握的情況下才推薦使用，免得出了問題難以下手解決。
3.性能分析
比Picasso性能好一些。
4.風險（包大小等）
包大小：1.3mb
能否解決listview圖片錯位問題？可以
Picasso（底層默認無緩存，使用的是API 9 以上使用 okhttp，以下使用 Urlconnection的緩存）
1.優點
1）picasso能夠根據網絡狀態調整線程池的併發數量
2）使用簡單，源碼簡單易懂。Picasso 代碼雖然只在一個包下，沒有嚴格的包區分，但代碼簡單、邏輯清晰
3）內部維護了一個監控類，能夠實時反饋內存緩存的命中率，使用狀態等等。
2.缺點
1）ARGB_8888
2）Picasso的方式則因爲需要在顯示之前重新調整大小而導致一些延遲，Glide加載顯示更快。
3.性能分析
4.風險（包大小等）
包大小：1.2mb
能否解決listview圖片錯位問題？
fresco(默認網絡HttpURLConnection)
Facebook出的，不是一般的強大。
1.優點
1）使用了Native緩存(5.0以下，不包括5.0)
2）支持模糊漸進形式展示圖片（類似webView）
3）能夠根據View的展示狀態控制網絡請求和圖片解析的狀態（在頁面不可見時停止對圖片的網絡請求和解析操作，在頁面可見時恢復操作）
4）對多幀動畫圖片支持更好（未測試）
5）對外提供清除緩存的方法
2.缺點
1）ARGB_8888
2）體積較大，集成後增大apk體積
3）需要使用特定的view，需要xml支持
3.性能分析
4.風險（包大小等）
包大小：4mb
能否解決listview圖片錯位問題？
volley imageloader
1.優點
2.缺點
Google官方出品，可惜不能加載本地圖片~
3.性能分析
4.風險（包大小等）
Universal Image Loader
1.優點
2.缺點
一個強大的圖片加載庫，包含各種各樣的配置，最老牌，使用也最廣泛。
3.性能分析
4.風險（包大小等）
