Ⅰ 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，这样问我这样答