Ⅰ Fragment中使用開源banner用Glide載入網路圖片顯示不出來
APP首頁用的是Fragment，然後用開源庫Banner來實現輪播圖，圖片載入用的是Glide，然而一張都出不來。
使用Glide的依賴為
Glide4.0以上需要自定義一個類
build之後會生成一個GlideApp.這樣就可以使用了。
如果你添加的依賴為
build的時候會報錯，此時你需要在gradle的defaultconfig添加下面這句
這樣就可以build成功。
在使用banner的時候需要設置圖片載入器：
其中ImageLoader是banner中封裝好的，我們只需要繼承一下即可。
在這里需要注意的是glide中的上下文如果使用的是displayImage中的context，也可能導致載入圖片不出來。從網上資料查閱得，Glide獲取容器生命周期的機制與其他開源框架產生了沖突，故而導致圖片載入失效
解決的方法有兩種：
1、上下文需要填
2、換用其他的第三方圖片載入
在這里使用的是ImageLoader。
依賴為：
在Application中初始化
然後再banner中設置
還有一種是9.0的系統導致圖片顯示不出來，因此需要在
設置android:usesCleartextTraffic="true"即可
Ⅱ Android Glide4.0+圖片載入進度監聽
在近期使用Glide4.0+版本的時候，需要進行圖片載入進度的監聽，於是查找各種資料實現該功能，便有了這篇記錄。
筆者Glide為：
大致思路：通過Okhttp的攔截器，監聽圖片Url的載入進度(需要自己實現邏輯計算)，並回調！
1，步驟1，將 OkHttpUrlLoader 添加到項目：
2，步驟2，將 OkHttpStreamFetcher 添加到項目：
3，步驟3，自定義攔截器和回調介面：
4，步驟4，計算載入進度，並在自定義的攔截器中使用：
5，在Glide中啟用：
本文僅為記錄，詳細分析參考： 郭霖大神Glide系列文章
Ⅲ Android：深入剖析圖片載入庫Glide緩存功能(源碼分析）
Glide 需要緩存的 圖片資源 分為兩類：
Glide 的緩存機制使得 Glide 具備非常好的圖片緩存效果，從而使得具備較高的圖片載入效率。
下面，我將根據 Glide 緩存流程中的每個步驟 進行源碼分析。
至此， Glide 的圖片緩存 Key 生成完畢。
至此，創建好了緩存對象 LruResourceCache
即：
源碼分析如下：
若上述兩個方法都沒獲取到緩存圖片時（即內存緩存里沒有該圖片的緩存），就開啟新線程載入圖片。
若無法從 內存緩存 里 獲得緩存的圖片， Glide 就會採用第2級緩存：磁碟緩存 去獲取緩存圖片
寫入 內存緩存分為：寫入 弱引用緩存 & LruCache 演算法的緩存
寫入 LruCache 演算法 內存緩存的原理：包含圖片資源 resource 的 EngineResource 對象的一個引用機制：
所以：
至此，實現了：
至此， Glide 的圖片緩存流程解析完畢。
Android圖片載入的那些事：為什麼你的Glide 緩存沒有起作用？
不定期分享關於 安卓開發 的干貨，追求 短、平、快 ，但 卻不缺深度 。
Ⅳ Android 【手撕Glide】--Glide緩存機制（面試）
本文源碼解析基於Glide 4.6.1
系列文章
Android 【手撕Glide】--Glide緩存機制
Android 【手撕Glide】--Glide緩存機制（面試）
Android 【手撕Glide】--Glide是如何關聯生命周期的？
Glide緩存分為內存緩存和磁碟緩存，其中內存緩存是由弱引用+LruCache組成。
取的順序是：弱引用、LruCache、磁碟
存的順序是：磁碟、弱引用、LruCache
這張親手製作的圖片，方便大家更直觀的理解緩存機制的整體流程，結合文末總結效果更佳。喜歡的記得點贊！
概述
1、弱引用是由這樣一個HashMap維護，key是緩存的key，這個key由圖片url、width、height等10來個參數組成；value是圖片資源對象的弱引用形式。
2、LruCache是由一個LinkedHashMap維護，根據Lru演算法來管理圖片。大致的原理是利用linkHashMap鏈表的特性，把最近使用過的文件插入到列表頭部，沒使用的圖片放在尾部；然後當圖片大小到達預先設置的一個閥值的時候 ，按演算法刪除列表尾部的部分數據。由於篇幅有限，這里不講解LruCache和DiskLruCache的底層原理，這里推薦一篇 圖解LinkedHashMap原理
這是Glide自定義的LruCache
存取原理
取數據
在內存緩存中有一個概念叫圖片引用計數器 ，具體來說是在 EngineResource 中定義一個 acquired 變數用來記錄圖片被引用的次數，調用 acquire() 方法會讓變數加1，調用 release() 方法會讓變數減1。
獲取圖片資源是先從弱引用取緩存，拿到的話，引用計數+1；沒有的話從LruCache中拿緩存，拿到的話，引用計數也是+1，同時把圖片從LruCache緩存轉移到弱應用緩存池中；再沒有的話就通過 EngineJob 開啟線程池去載入圖片，拿到的話，引用計數也是+1，會把圖片放到弱引用。
存數據
很明顯，這是載入圖片之後的事情。通過 EngineJob 開啟線程池去載入圖片，取到數據之後，會回調到主線程，把圖片存到弱引用。當圖片不再使用的時候，比如說暫停請求或者載入完畢或者清除資源時，就會將其從弱引用中轉移到 LruCache 緩存池中。 總結一下，就是正在使用中的圖片使用 弱引用 來進行緩存，暫時不用的圖片使用 LruCache 來進行緩存的功能;同一張圖片只會出現在 弱引用 和 LruCache 中的一個。
為什麼要引入軟引用？
1、分壓策略，減少Lrucache 中 trimToSize 的概率。如果正在remove的是張大圖，lrucache正好處在臨界點，此時remove操作，將延緩Lrucache的 trimToSize 操作；
2 提高效率：弱引用用的是 HashMap ，Lrucache用的是 LinkedHashMap ,從訪問效率而言，肯定是 HashMap 更高。
Glide磁碟緩存策略（4.x）
如果在內存緩存中沒獲取到數據會通過 EngineJob 開啟線程池去載入圖片,這里有2個關鍵類： DecodeJob 和 EngineJob 。 EngineJob 內部維護了線程池，用來管理資源載入，當資源載入完畢的時候通知回調； DecodeJob 是線程池中的一個任務。
磁碟緩存是通過 DiskLruCache 來管理的,根據緩存策略，會有2種類型的圖片， DATA (原始圖片)和 RESOURCE （轉換後的圖片）。磁碟緩存依次通過 ResourcesCacheGenerator 、 SourceGenerator 、 DataCacheGenerator 來獲取緩存數據。 ResourcesCacheGenerator 獲取的是轉換過的緩存數據； SourceGenerator 獲取的是未經轉換的原始的緩存數據； DataCacheGenerator 是通過網路獲取圖片數據再按照按照緩存策略的不同去緩存不同的圖片到磁碟上。
Glide緩存分為 弱引用+ LruCache+ DiskLruCache ，其中讀取數據的順序是：弱引用 > LruCache > DiskLruCache>網路；寫入緩存的順序是：網路 --> DiskLruCache--> LruCache-->弱引用
內存緩存分為弱引用的和 LruCache ，其中正在使用的圖片使用弱引用緩存，暫時不使用的圖片用 LruCache緩存，這一點是通過 圖片引用計數器（acquired變數）來實現的，詳情可以看內存緩存的小結。
磁碟緩存就是通過DiskLruCache實現的，根據緩存策略的不同會獲取到不同類型的緩存圖片。它的邏輯是：先從轉換後的緩存中取；沒有的話再從原始的（沒有轉換過的）緩存中拿數據；再沒有的話就從網路載入圖片數據，獲取到數據之後，再依次緩存到磁碟和弱引用。
參考：
面試官：簡歷上最好不要寫Glide，不是問源碼那麼簡單
原來面試的時候寫精通Glide，這樣問我這樣答