Glide 使用簡明的流式語法API,大多數狀況下,可能完成圖片的設置你只須要: Glide.with(activity) .load(url) .into(imageView);
html
默認狀況下,Glide 會在開始一個新的圖片請求以前檢查如下多級的緩存:
1. 活動資源 (Active Resources)
2. 內存緩存 (Memory Cache)
3. 資源類型(Resource Disk Cache)
4. 原始數據 (Data Disk Cache)
活動資源:若是當前對應的圖片資源正在使用,則這個圖片會被Glide放入活動緩存。
內存緩存:若是圖片最近被加載過,而且當前沒有使用這個圖片,則會被放入內存中
資源類型: 被解碼後的圖片寫入磁盤文件中,解碼的過程可能修改了圖片的參數(如:inSampleSize、inPreferredConfig)
原始數據: 圖片原始數據在磁盤中的緩存(從網絡、文件中直接得到的原始數據)
複製代碼
在調用into以後,Glide會首先從Active Resources查找當前是否有對應的活躍圖片,沒有則查找內存緩存,沒有則查找資源類型,沒有則查找數據來源。android
相較於常見的內存+磁盤緩存,Glide將其緩存分紅了4層。算法
當須要加載某張圖片可以從內存緩存中得到的時候,在圖片加載時主動將對應圖片從內存緩存中移除,加入到活動資源中。 這樣也能夠避免由於達到內存緩存最大值或者系統內存壓力致使的內存緩存清理,從而釋放掉活動資源中的圖片(recycle)。 活動資源中是一個」引用計數"的圖片資源的弱引用集合。緩存
由於同一張圖片可能在多個地方被同時使用,每一次使用都會將引用計數+1,而當引用計數爲0時候,則表示這個圖片沒有被使用也就是沒有強引用了。這樣則會將圖片從活動資源中移除,並加入內存緩存。bash
內存緩存默認使用LRU(緩存淘汰算法/最近最少使用算法),當資源從活動資源移除的時候,會加入此緩存。使用圖片的時候會主動今後緩存移除,加入活動資源。微信
LRU在Android support-v4中提供了LruCache工具類。網絡
構造LinkedHashMap的accessOrder設置爲true。在使用的此map的時候,自動進行排序(每次get/put,會將使用的value放入鏈表header頭部)。LruCache會在每次get/put的時候判斷數據若是達到了maxSize,則會優先刪除tail尾端的數據。ide
磁盤緩存一樣使用LRU算法。工具
Resource 緩存的是通過解碼後的圖片,若是再使用就不須要再去進行解碼配置(BitmapFactory.Options),加快得到圖片速度。好比原圖是一個100x100的ARGB_8888圖片,在首次使用的時候須要的是50x50的RGB_565圖片,那麼Resource將50x50 RGB_565緩存下來,再次使用此圖片的時候就能夠從 Resource 得到。不須要去計算inSampleSize(縮放因子)。 Data 緩存的則是圖像原始數據。性能
若是緩存都不存在,那麼會從源地址得到圖片(網絡/文件)。而在解析圖片的時候會須要能夠得到BitmapPool(複用池),達到複用的效果。
複用效果如上。在未使用複用的狀況下,每張圖片都須要一塊內存。而使用複用的時候,若是存在能被複用的圖片會重複使用該圖片的內存。 因此複用並不能減小程序正在使用的內存大小。Bitmap複用,解決的是減小頻繁申請內存帶來的性能(抖動、碎片)問題。
developer.android.google.cn/topic/perfo…
Google給出的案例能夠看出: 使用方式爲在解析的時候設置Options的inBitmap屬性。
- Bitmap的inMutable須要爲true。
- Android 4.4及以上只須要被複用的Bitmap的內存必須大於等於須要新得到Bitmap的內存,則容許複用此Bitmap。
- 4.4如下(3.0以上)則被複用的Bitmap與使用複用的Bitmap必須寬、高相等而且使用複用的Bitmap解碼時設置的inSampleSize爲1,才容許複用。
所以Glide中,在每次解析一張圖片爲Bitmap的時候(磁盤緩存、網絡/文件)會從其BitmapPool中查找一個可被複用的Bitmap。
BitmapPool是Glide中的Bitmap複用池,一樣適用LRU來進行管理。 當一個Bitmap從內存緩存 被動 的被移除(內存緊張、達到maxSize)的時候並不會被recycle。而是加入這個BitmapPool,只有從這個BitmapPool 被動 被移除的時候,Bitmap的內存纔會真正被recycle釋放。
原創文章,轉載請聯繫做者哦~~
微信公衆號:終端研發部