前言:在Android開發中,圖片加載OOM一直困擾着很多開發者,在各種不合理的設計之下也容易導致圖片加載OOM的問題,目前開源的比較常用的圖片加載庫也很多,比如老牌的UIL,Volley,AQuery還有比較優秀的Picasso,Glide,Fresco等.
本文僅簡單地比較Fresco&Glide&Picasoo,如有錯誤還請斧正.
Picasso
由Square公司開源的一款圖片加載和緩存的庫,不過Picasso不支持磁盤緩存.也就是說如果想要做磁盤緩存的話需要另外想辦法.(可以利用JakeWharton/DiskLruCache)
Glide
一款和Picasso類似的圖片加載和緩存的開源庫.雖然在函數定義和調用上和Picasso相差無幾,但是Glide確實在性能方面比Picasso要好,值得注意的是Glide庫僅支持Android 2.3.3及以上的版本.(PS:目前市面上貌似也很少看到Android 4.1以下的機型了,所以版本向下兼容可以不用擔心.)
關於Glide和Picasso的比較文章推薦:
Introduction to Glide, Image Loader Library for Android, recommended by Google
Fresco
一款由Facebook今年推出的一個強大的圖片加載庫,Fresco 中設計有一個叫做 image pipeline 的模塊。它負責從網絡，從本地文件系統，本地資源加載圖片。為了最大限度節省空間和CPU時間，它含有3級緩存設計（2級內存，1級文件）。Fresco 中設計有一個叫做 Drawees 模塊，方便地顯示loading圖，當圖片不再顯示在屏幕上時，及時地釋放內存和空間占用。Fresco 支持 Android2.3(API level 9) 及其以上系統。(摘自:http://fresco-cn.org/)
有關Fresco的使用教程請繞道:http://fresco-cn.org/docs/index.html#_
Fresco相比其他圖片庫如Picasso，UIL，Glide相比，所具有的最重要的幾個獨有特性：
- 在Android 5.0以下系統，圖片不存儲在Java heap，而是存儲在ashmemheap，中間的字節buffer同樣位於native heap。使應用有更多內存空間，降低OOM風險，減少GC次數。
漸進式的JPEG呈現。- 圖片可以在任意點進行裁剪，而不是中心，即自定義居中焦點。
- JPEG可以在native進行resize，避免了在縮小圖片時的OOM風險。
- 支持Gif和WebP。
Fresco&Glide&Picasso 比較
Facebook也提供了,關於Fresco和其他圖片加載器的比較例子.下載地址:Fresco
加載本地圖片:
由於圖片數量比較少,很難看出差別,不過可以發現,在一般的情況下,Fresco和Glide在內存占用上,Fresco更優,這是由於Fresco將圖片放置到一塊特殊的Native內存，這塊內存的管理是由Fresco進行的，所以Fresco的體積比較龐大，會為應用增加接近2M的體積，這算是Fresco的一個缺點.
加載網絡圖片: 
在加載網絡圖片時,由於機型和網絡環境不同,可能也會導致現實的數據有問題,不過在比較的時候,可以發現,Fresco在加載網絡圖片時,剛開始Heap內存占用也是58M左右,不過隨着時間的推移,Heap內存占用的值會變大,可能是由於Fresco內存釋放存在問題導致的.可見Fresco雖然在加載圖片上獨辟蹊徑但是並沒有傳說中那么完美.
圖片加載庫的選擇
根據自己平時在項目中的體會,在綜合包的大小及圖片加載器的穩定性后覺得Glide是比較適合用在產品中的圖片加載庫.
選擇的原因如下:
- Glide默認提供配置支持本地圖片緩存,緩存的機制是DiskLruCache.可以根據自己的需要,自定義圖片緩存的路徑.所以在考慮節省用戶流量來看可以不考慮Picasso;
- 雖然Fresco也提供更強大的圖片緩存和加載機制,不過在比較之后,感覺Fresco還是有待完善.Glide可以很簡單的獲取網絡圖片的Bitmap對象,而Fresco需要通過訂閱數據源克隆Bitmap對象的引用才能存儲值.操作方式不夠簡潔和友好.
- Fresco的庫文件中,以最新的0.8.1為例,imagepipeline-0.8.1.aar光包得大小就有3.5M ,而Glide包的大小為465K為了讓Apk包得體積更小,所以考慮使用Glide.
推薦：Android中實用的Gradle配置 http://www.apkbus.com/blog-705730-61441.html