Glide工作原理

Glide加载发起流程：

1、Glide.with(context)创建RequestManager 

RequestManager负责管理当前context的所有Request

Context可以传Fragment、Activity或者其他Context，当传Fragment、Activity时，当前页面对应的Activity的生命周期可以被RequestManager监控到，从而可以控制Request的pause、resume、clear。这其中采用的监控方法就是在当前activity中添加一个没有view的fragment，这样在activity发生onStart onStop onDestroy的时候，会触发此fragment的onStart onStop onDestroy。

2、RequestManager用来跟踪众多当前页面的Request的是RequestTracker类，用弱引用来保存运行中的Request，用强引用来保存暂停需要恢复的Request。

Glide.with(context).load(url)创建需要的Request 

通常是DrawableTypeRequest，后面可以添加transform、fitCenter、animate、placeholder、error、override、skipMemoryCache、signature等等

3、如果需要进行Resource的转化比如转化为Byte数组等需要，可以加asBitmap来更改为BitmapTypeRequest

4、Request是Glide加载图片的执行单位

Glide.with(context).load(url).into(imageview) 

在Request的into方法中会调用Request的begin方法开始执行

在正式生成EngineJob放入Engine中执行之前，如果并没有事先调用override(width, height)来指定所需要宽高，Glide则会尝试去获取imageview的宽和高，如果当前imageview并没有初始化完毕取不到高宽，Glide会通过view的ViewTreeObserver来等View初始化完毕之后再获取宽高再进行下一步

5、Glide加载资源：

(1) GlideBuilder在初始化Glide时，会生成一个执行机Engine

Engine中包含LruCache缓存及一个当前正在使用的active资源Cache（弱引用）

activeCache辅助LruCache，当Resource从LruCache中取出使用时，会从LruCache中remove并进入acticeCache当中

Cache优先级LruCache>activeCache

(2)Engine在初始化时要传入两个ExecutorService，即会有两个线程池，一个用来从DiskCache获取resource，另一个用来从Source中获取（通常是下载）

线程的封装单位是EngineJob，有两个顺序状态，先是CacheState，在此状态先进入DiskCacheService中执行获取，如果没找到则进入SourceState，进到SourceService中执行下载

 6.Glide的Target：

         负责图片加载的回调

 总结：

Glide库在使用过程中表现较好，滑动流畅，内存占用低

代码扩展性极强，4.0版本更加如此，但来的问题就是过于复杂，不太便于阅读

但仍会遇到有些需求Glide无法满足 

设置加载图片的最大宽高

PlaceHolder的图片形状不与加载的Bitmap相同会产生的抖动问题

无法指定删除某一个图片缓存的问题（可以用加signature的方式试其失效并重新下载，但不可以删除）