本文主要从以下三条主线去分析Glide

1、了解请求怎么发送的，有没有队列，怎么维护的
2、生命周期怎么回事，Glide怎么去做的？
3、Glide是如何处理我们的请求的

Glide优点：

• 生命周期的管理
• 支持gif picasso也支持gif
• 三级缓存，内存缓存中还分为活动缓存和内存缓存；活动缓存指得是讲正在使用得图片用弱引用缓存，使用完成后到内存缓存；再到磁盘缓存；
• 占用内存小，它默认得编码格式是rgb565； picasso用得argb8888 ImageLoader不支持gif图片加载 而且也很老了

Glide缺点：
加载GIF的时候，第一次是 从第一帧 一直播到最后一帧。应用杀掉或者第二次再进到这个页面的时候，可能是从第五帧开始播，最好用NDK去加载

第一条线 ：load.into()方法 这个请求发送到哪里去了

发送到RequestTracker 两个队列中 ：requests和pendingRequests 请求过来之后，都是存入这两个队列；从Glide具有生命周期的特性开始推算，RequestManager 进行维护队列

第二条线：为什么RequestManager能够管理生命周期？谁在处理？

通过RequestManagerRetriever创建一个无UI的Fragment，并将这个Fragment的生命周期绑定到RequestManager上；

Glide队列请求如何处理的？

当我们在load.into();方法时，所有的请求都会被添加到一个叫RequestTracker的队列中，这个队列有两个，一个是运行时队列，一个是等待队列；
如果当前页面停止，onStop方法被调用，所有的运行中的请求都会被停止，并且全部添加到等待队列中；
当开始运行时，又会把所有等待队列中的请求放到运行队列中去！

队列是如何维护的?

RequestManager with = Glide.with(this);
通过这句代码，创建了一个RequestManager，并在Glide.with方法中，为传入的this(Activity) 创建一个无UI的Fragment，并将Fragment的生命周期绑定到ReuqestManager上。

当Activity触发了onStop等方法时，则会隐式的调用fragment的onStop方法，再通过fragment 的onStop 调用RequestManager的onStop方法，以此来管理两个请求队列中的请求；

第三条主线

• 当RequestManager类里调用requestTracker.runRequest的时候，所有请求都会构成一个SingleRequest，并开始调用begin方法运行
• begin方法最终会调用engine.load方法
• 根据request构建EngineKey
• 根据EngineKey去活动缓存中获取数据
• 如果获取不到，去内存缓存中获取数据
• 如果获取不到，通过硬盘缓存的线程池去获取本地硬盘的数据
• 如果获取不到本地的，通过网络的线程池去获取网络的数据

最后说一下，如果让我自己写一个 图片加载框架，我可能会这个设计：

• 要有生命周期
• 活动缓存设计
• 内存缓存设计
• 磁盘缓存设计