關於 Fresco 和 Glide，真的和你想的同樣嗎

網上對於 Fresco 的討論通常都是說 Fresco 性能更好，Glide 使用更簡單。然而這個問題的答案真的有那麼明顯嗎？web

好比性能問題。Fresco 性能真的比 Glide 好多少嗎？畢竟 Fresco 包更大，線程開得也更多，圖片重採樣也要手動提供 ResizeOptions。此外，Fresco 分配用於緩存的內存也更大，若是不是主動指定 Bitmap.Config 不然不會啓用 HARDWARE 格式。其中，我最介意的是必需要手動提供 ResizeOptions 才能執行重採樣，但每每須要手動執行的都是不靠譜的，若是開發人員素質不夠，或者沒注意，那麼在加載大圖時就很容易致使內存問題。因此，從性能的角度上說，特別若是是面向 5.0 以上的設備，我的認爲 Glide 反而更好用、更安全一些。算法

而與此同時，Glide 的使用真的比 Fresco 更簡單嗎？的確，若是要使用 Java 代碼自定義圖片請求，那麼，Fresco 的確比 Glide 複雜不少。然而，大多數狀況下，Fresco 使用 SimpleDraweeView 便可完成圖片請求，同時附加圓角、placeholder、寬高比等功能，若是自定義一個通用的 style，Fresco 代碼量反而可以比 Glide 少不少。而 Glide 則每次都要 with、load、into，寬高比等功能也要本身實現，圓角的功能也不支持自定義上下左右不一樣位置使用不一樣的半徑，還要本身建立一個 RoundedCorners 對象，而不是直接設置便可，代碼寫起來反而更麻煩一些。數組

總的來講，Fresco 功能更豐富，好比圓角、寬高比、漸進式加載 JPEG、在加載過程當中顯示進度條、加載失敗後點擊重試等，對 5.0 如下的手機支持也更好。而 Glide 更方便，好比自動根據 ImageView 尺寸縮放圖片、在內存事件回調時自動釋放內存等。而對於性能以及使用的問題，答案可能並無網上討論的那麼簡單，還須要自行權衡。緩存

	Fresco	Glide
代碼結構	相對更復雜難懂	相對更清晰直觀
View	自定義的 DraweeView	配合 ImageView 使用
獲取 Bitmap	稍顯複雜，須要向 ImagePipeline 發送自定義請求	相對更簡單，使用 CustomTarget 或 FutureTarget 便可
縮放	方式更多，但默認不執行重採樣，須要手動設置爲 true，並提供 RezieOptions	默認自動根據 ImageView 的尺寸對圖片進行重採樣
圖層	層級更多，功能更豐富（好比顯示進度條、點擊重試等）	分爲佔位圖、縮略圖、加載失敗佔位圖三層
圖片格式	支持 gif、webp、視頻縮略圖，可添加自定義 svg 解碼器	支持 gif、webp、svg、視頻縮略圖
變換操做	支持圓形、圓角、旋轉等	支持圓形、圓角、旋轉等，但不支持在不一樣位置使用不一樣的圓角半徑
漸進加載 JPEG	支持	不支持
緩存	1) 內存緩存（活躍、非活躍）2) 未解碼的圖片緩存（字節流）3) 磁盤緩存（緩存的是原始圖像數據，能夠手動設置小文件、大文件分開存儲，但須要手動指定哪些是小文件）	1) 內存緩存（活躍、非活躍） 2) 磁盤緩存（解碼、變換後的圖像數據） 3) 磁盤緩存（原始圖像數據）
緩存大小	1) 內存緩存通常是 ActivityManager.getMemoryClass / 4 2) 未解碼的圖片緩存通常是 4MB 3) 磁盤緩存通常是 40MB	1) 內存緩存根據手機分辨率計算，通常是分辨率乘以 2 2) 磁盤緩存默認 250MB（兩級緩存共用）
緩存算法	LRU（磁盤緩存經過修改文件 LastModified 屬性實現）	LRU（磁盤緩存經過 DiskLruCache 實現）
對象池	都有 Bitmap 對象池和數組對象池
內存事件	須要手動調用 trim 方法釋放內存	監聽了 ComponentCallbacks2，可自動釋放內存
生命週期	監聽 DraweeView 的 attach、detach 事件	添加 Fragment 監聽生命週期
線程池	線程池更多，線程數也更多	主要有 3 個線程池，線程數相對較少
Bitmap 格式	默認爲 ARGB_8888，能夠手動設置爲 HARDWARE	優先使用 Config.HARDWARE（8.0），不然默認使用 ARGB_8888
Bitmap 存儲	5.0 如下使用 native 內存存儲，5.0 及以上使用 Java 堆存儲	Bitmap 優先使用 GPU 存儲（8.0），不然使用 Java 堆存儲