為什么要用Glide
- 鏈式呼叫，兼容系統控制元件imageView，使用非常簡單，不必像Fresco那樣得用SimpleDrawableView
Glide.with(this)
.load(data.teacher_image)
.placeholder(R.drawable.recommend_teacher_icon)
.error(R.drawable.recommend_teacher_icon)
.apply(RequestOptions.circleCropTransform())
.diskCacheStrategy(DiskCacheStrategy.ALL)
.into(ivTIcon)
- 可以感知activity和fragment的生命周期做圖片加載的控制，
實作原理:通過 Glide.with(this)函式，傳入當前的context物件，進行相應的判斷轉化，拿到當前fragmentManager，然后RequestManagerRetriever創建出來一個沒有布局的fragment，并且把RequestManager和ActivityFragmentLifecycle相關聯，實作生命周期的監控和圖片網路請求的處理，防止記憶體泄露， - 通過DefaultConnectivityMonitor注冊網路變化廣播感知網路變化監聽，RequestManager處理圖片請求，
- 采用記憶體快取和磁盤快取減少流量消耗，加快回應速度，
- 記憶體快取，采用Lrucache演算法，防止存盤的記憶體過大，OOM，
假如讓你實作個圖片加載框架，會考慮哪些問題
- 圖片網路請求，異步加載，需要執行緒池
- 切換到主執行緒更新UI：Handler
- 快取：LruCache
- 防止OOM: 軟參考(map) ， LruCache， 圖片壓縮處理（按比例壓縮inSampleSize,壓縮圖片質量，RGB-565）
- 防止記憶體泄露，通過對生命周期的管理
- 串列滑動加載問題 （通過給imageView設定tag,防止圖片錯亂）
LruCache小結
- LruCache 內部用LinkHashMap存取資料，設定的accessOrder為true,即按照訪問順序排序，添加和洗掉元素不影響迭代順序，獲取元素會導致重新排序，獲取到的元素排到隊尾，當容量達到上限時，洗掉最近最少使用的元素也就是佇列頭部的元素，
代碼示例：
//put和remove元素后不影響迭代順序
Map<Integer, String> linkedHashMap = new LinkedHashMap<Integer, String>(16, 0.75f, true);
linkedHashMap.put(3, "order3");
linkedHashMap.put(1, "order1");
linkedHashMap.put(2, "order2");
linkedHashMap.get(3); //此時順序為 1->2->3
linkedHashMap.remove(1);//此時順序為 2->3
linkedHashMap.put(4, "order4");//此時順序為 2->3->4
linkedHashMap.forEach((key, value) -> System.out.println(key + "-->" + value));
輸出結果：
2-->order2
3-->order3
4-->order4
參考文章
- 圖解LinkedHashMap原理
- LinkedHashMap決議
- 面試官：簡歷上最好不要寫Glide，不是問原始碼那么簡單
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/247677.html
標籤：其他