序
glide是android上实现图片加载的库中很常用的一个，趁着有时间，也了解下其源码，我看的是v4版本，因为之前已经看过v4版本新特性的介绍，所以就直接阅读这个版本源码，不熟悉的读者可以先看一下特性介绍。
开始
从github上面clone完项目之后，用android studio打开，目录很多，搜索了一下，在library目录下是核心功能代码，我们还是通过示例代码开始：
···
Glide.with(fragment)
.load(myUrl)
.into(imageView);
···
这应该是最简单的使用，那么我们就就Glide类开始，先找到with方法。with方法有不同参数的重载方法，我们看一下with(Context)方法，显示调用getRetriever获取RequestManagerRetriever实例，这个方法里，先是调用Glide.get(context)获取Glide的实例，Glide是单例的，因为v4版本使用了注解处理器来生成AppModule的实现类，所以这里会有反射获取实例，然后通过GlideBuilder构造Glide实例，内部实现就是初始化Glide里的内部域，这里我们会看到Engine（负责加载及管理资源），BitmapPool,MemoryCache,RequestManagerRetriever等类，注意在Glide的构造方法里，会构造Registry实例，然后调用方法将loading,encoding,decoding的逻辑实现类加到Registry内部域中，最后构造GlideContext实例，这个类后面很多地方都用到。得到Glide实例后，调用getRequestManagerRetriever得到RequestManagerRetriever的实例，然后调用其实例方法得到RequestManager实例，这里会用到RequestManagerFactory的build方法构造，而这个RequestManagerFactory只是个接口，如果我们没有配置，会使用默认实现，build方法实现就是调用RequestManage的构造方法来构造，构造方法会使用到一些参数，包括Glide实例，Lifecycle接口实现，Context实例等，至此with方法结束。
接着我们看一下RequetManager的load方法，它有很多重载方法，接收不同类型的参数，我们这里看一下参数类型是String的方法，这个方法首先调用asDrawable得到RequestBuilder<Drawable>实例，然后调用其实例方法load(String)，我们先来看asDrawable方法，这个方法最终就是调用new RequestBuilder<>(glide, this, resourceClass, context)构造RequestBuilder实例，这里resourceClass类型是Class<Drawable>。然后我们就来看一下RequestBuilder类的load(String)方法，其实现最终会将String参数赋值给其内部域model,然后设置isModelSet为true，然后就返回这个RequestBuilder了。
看来加载图片的关键代码在into(ImageView)中了，让我们来看一下RequestBuilder的into方法。into(ImageView)方法会先判断条件，是否需要将ImageView的ScaleType设置也添加到当前RequestBuilder配置中（因为RequestBuilder继承BaseRequestOptions），然后调用into的重载方法:
into(@NonNull Y target, @Nullable RequestListener<TranscodeType> targetListener,
BaseRequestOptions<?> options, Executor callbackExecutor)。我们看一下这个方法，这里先是调用buildRequest方法，其实现就是调用buildRequestRecursive方法，我们接着看其实现，先是初始化parentCoordinator，然后调用buildThumbnailRequestRecursive方法，其实现里分为三种情况，如果thumbnailBuilder内部域不为null，那么会做一些参数处理，然后创建一个ThumbnailRequestCoordinator实例，其是Request接口的实现类，职责是内部维护thumbail缩略图的加载和full image原图的加载，这里调用SingleRequest.obtain获取原图的request，递归调用thumbnailBuilder.buildRequestRecursive获取thumbail缩略图的request，将两者赋值给ThumbnailRequestCoordinator之后返回这个实例；如果thumbSizeMultiplier不为null，那么这里也要创建ThumbnailRequestCoordinator实例，只是缩略图和原图的request都是通过SingleRequest.obtain生成的；如果都不是以上两者情况，则通过SingleRequest.obtain获取原图的request，这里也就是说不加载缩略图、
得到了Request（或者是ThumbnailRequestCoordinator，或者是SingleRequest）,我们调用target.getRequest，这里会获取imageview的之前的request（如果有的话），比较这两个request是否相等，如果相等，那么会根据其他条件做处理，如果不相等，会调用以下代码：
···
requestManager.clear(target);
target.setRequest(request);
requestManager.track(target, request);
···
第一步先取消target上之前的request并释放资源，然后设置新的request，然后track方法，内部会调用以下代码：
···
targetTracker.track(target);
requestTracker.runRequest(request);
···
第一步是把这个target加到target内部维护的列表，TargetTracker会赋值在activity或fragment生命周期变化时回调target对应onStart,onStop,onDestroy方法。而runRequest方法，先是把这个request加到RequestTracker内部列表中以便在生命周期变化时管理所有request，然后如果isPaused内部域为false，说明没有暂停所有请求，则调用request的begin方法开始加载，否则调用request的clear方法并把这个request加到pendingRequests中，以便条件满足时重启request。
刚提到TargetTracker可以在生命周期变化时进行处理，那它又是如何得知生命周期变化的呢，其实在with(Activity)方法中，会将一个没有view的fragment加到activity的fragment manager,这样就可以监听生命周期变化。
回过头来我们来看一下request的begin方法，之前提到Request的两个实现类，ThumbnailRequestCoordinator和SingleRequest，在ThumbnailRequestCoordinator内部的begin方法，基本就是顺序调用origin原图和thumbnail缩略图这个两个SingleRequest的begin方法，那我们来看一下SingleRequest的begin方法。
首先是参数验证和request加载状态验证，如果已经加载完成，则直接使用缓存资源调用onResoureReady；如果已经开始，则会抛出异常；如果是其他情况，都视为可以重新启动加载，然后这里会调用Engine的load方法，这个Engine之前在Glide初始化的时候有提到，这里就深入了解。
Engine实例的构造方法内部，会创建多个GlideExecutor（这个类扩展ExecutorService），有缓存存在情况下的GlideExecutor（有1个线程），有缓存不存在情况下的GlideExecutor（两个实例，一个实例内部线程数根据硬件cpu核心数来定，最多不超过4个，还有一个实例内部线程数不限制），还有负责动画的GlideExecutor（1或2个线程，gif图需要用到）
然后我们来看一下Engine的load方法，首先是构造一个EngineKey实例，这是Key接口的实现，用作内存中缓存的key，然后这里按照以下步骤执行：
1）首先检查当前activeResource活跃资源（指被至少一个request使用并且还没释放的资源）的集合中是否存在key对应的EngineResource，如果存在则调用onResourceReady并结束，否则继续
2）检查memoryCache缓存中是否存在key对应的EngineResource,如果存在也是调用onResourceReady并结束，否则继续
3）检查正在执行加载任务的集合中是否存在key对应的EngineJob，存在的话就将调用EngineJob的addCallback方法将当前需要执行任务的callback添加进去，以便任务完成时收到回调；否则的话继续
4）创建一个EngineJob，将当前需要执行任务的callback添加进去并开始执行加载
