写在之前
上一篇博文写的是Picasso基本使用和源码完全解析，Picasso的源码阅读起来还是很顺畅的，然后就想到Glide框架，网上大家也都推荐使用这个框架用来加载图片，正好我目前的写作目标也是分析当前一些流行的框架源码，那就也来解析下Glide的源码吧，而且有了Picasso源码的分析相信很快就搞定Glide的，结果也就悲剧了，深陷其中无法自拔了，Glide的源码远非Picasso能比，阅读起来也是相当的困难的，而且我使用的是最新的Glide4.0，与之前版本有较大的差异，网上也没可以参考的资料，这就悲剧了，苦头专研呗。直到今天才从深沟中冒出头了，差点憋死，哈哈。
正文
Glide的使用和Picasso基本一样，这里就不再多说，主要是因为源码分析会写的很长很细，再加上基本使用的话，就更加长了，而且上一篇已写过Picasso的基本使用，这两者在使用方面相差的微乎及微，所以我们这篇文章直接进入源码分析。
Glide 源码分析
首先在build.gradle里添加如下引用：
compile 'com.github.bumptech.glide:glide:4.0.0-RC0'
这里我用的是Glide4.0也是最新的版本，和3.X在源码上还是有很大的差别的。看过3.X源码的相信对比下这篇文章就会知道。
ok，和Picasso的分析模式一样，我们也是从下面最简单的代码进行一步一步的深入分析：
Glide.with(MainActivity.this).load(url).into(headerImage);
with()
首先我们来看看当我们调用Glide的with方法那做了哪些工作：
with方法中可以接受Context，Activity，FragmentActivity，Fragment甚至是View不同的类型，返回的是RequestManager对象，这个对象是需要在RequestManagerRetriever中获取的，那我们在来看看RequestManagerRetriever是怎么获取到的？请看getRetriever方法的源码：
getRetriever方法中也没有真正的创建RequestManagerRetriever对象，而是从Glide的getRequestManagerRetriever方法中获取，那么很明显的可以看出所做的工作都是在Glide的get方法中完成的，在来看下get方法源码：
来到这一步，我们看到了非常熟悉的代码设计原理，那就是双重加锁的单例模式保证Glide对象的唯一性，那么initGlide就是创建Glide对象的方法了，请看：
这是initGlide方法中最重要的代码，主要是创建了一个GlideBuilder对象，然后调用build方法来完成Glide对象的创建，相信不用看bulid方法，大家也会猜到接下来将要发生什么样的事情，没错，那就是使用建造者设计模式来完美的构建出Glide对象：
public Glide build(Context context) {
if (sourceExecutor == null) {
sourceExecutor = GlideExecutor.newSourceExecutor();
}
if (diskCacheExecutor == null) {
diskCacheExecutor = GlideExecutor.newDiskCacheExecutor();
}
if (memorySizeCalculator == null) {
memorySizeCalculator = new MemorySizeCalculator.Builder(context).build();
}
if (connectivityMonitorFactory == null) {
connectivityMonitorFactory = new DefaultConnectivityMonitorFactory();
}
if (bitmapPool == null) {
int size = memorySizeCalculator.getBitmapPoolSize();
bitmapPool = new LruBitmapPool(size);
}
if (arrayPool == null) {
arrayPool = new LruArrayPool(memorySizeCalculator.getArrayPoolSizeInBytes());
}
if (memoryCache == null) {
memoryCache = new LruResourceCache(memorySizeCalculator.getMemoryCacheSize());
}
if (diskCacheFactory == null) {
diskCacheFactory = new InternalCacheDiskCacheFactory(context);
}
if (engine == null) {
engine = new Engine(memoryCache, diskCacheFactory, diskCacheExecutor, sourceExecutor,
GlideExecutor.newUnlimitedSourceExecutor());
}
RequestManagerRetriever requestManagerRetriever = new RequestManagerRetriever(
requestManagerFactory);
return new Glide(
context,
engine,
memoryCache,
bitmapPool,
arrayPool,
requestManagerRetriever,
connectivityMonitorFactory,
logLevel,
defaultRequestOptions.lock());
}
build方法中主要是构建线程池（包括sourceExecutor ，diskCacheExecutor ），缓存大小和缓存器，默认的连接监听工厂（connectivityMonitorFactory ），Engine对象和RequestManagerRetriever 对象等等。
有几个重要的对象创建，我们这里先看下它的构建内容：
1 Engine对象
创建Engine对象在构造方法中传递了几个重要的参数，分别是线程池，内存缓存和硬盘缓存对象，那我们来看看在构造方法中它是怎么构建Engine对象的：
Engine(MemoryCache cache,
DiskCache.Factory diskCacheFactory,
GlideExecutor diskCacheExecutor,
GlideExecutor sourceExecutor,
GlideExecutor sourceUnlimitedExecutor,
Map<Key, EngineJob<?>> jobs,
EngineKeyFactory keyFactory,
Map<Key, WeakReference<EngineResource<?>>> activeResources,
EngineJobFactory engineJobFactory,
DecodeJobFactory decodeJobFactory,
ResourceRecycler resourceRecycler) {
this.cache = cache;
this.diskCacheProvider = new LazyDiskCacheProvider(diskCacheFactory);
if (activeResources == null) {
activeResources = new HashMap<>();
}
this.activeResources = activeResources;
if (keyFactory == null) {
keyFactory = new EngineKeyFactory();
}
this.keyFactory = keyFactory;
if (jobs == null) {
jobs = new HashMap<>();
}
this.jobs = jobs;
if (engineJobFactory == null) {
engineJobFactory = new EngineJobFactory(diskCacheExecutor, sourceExecutor,
sourceUnlimitedExecutor, this);
}
this.engineJobFactory = engineJobFactory;
if (decodeJobFactory == null) {
decodeJobFactory = new DecodeJobFactory(diskCacheProvider);
}
this.decodeJobFactory = decodeJobFactory;
if (resourceRecycler == null) {
resourceRecycler = new ResourceRecycler();
}
this.resourceRecycler = resourceRecycler;
cache.setResourceRemovedListener(this);
}
创建了几个工厂对象方法，比如EngineKeyFactory，EngineJobFactory和DecodeJobFactory，几个HashMap类型的对象集合，如：jobs ，activeResources 等等，然后就分别把这些对象赋值给Engine的成员变量，那么来看下创建Engine对象时到底初始化了那些成员变量：
ok，Engine是一个非常重要的对象，后面扮演着重要的角色，为了方面理解它所拥有那些可使用的对象，这里我做了个类图显示的标了出来。
2 RequestManagerRetriever 对象
再来看看RequestManagerRetriever 对象的创建，这个相对的简单很多，我们来看下它的构造方法：
由于我们传递过来的requestManagerFactory为空，所以factory将会使用默认的DEFAULT_FACTORY工厂，DEFAULT_FACTORY是真正创建RequestManager对象的地方，稍后介绍。
这里只是让大家知道这里的factory就是DEFAULT_FACTORY。
来看看它拥有哪些成员：
3 Glide对象
在build方法中 return new Gilde()，创建一个Glide对象并返回，那在Gilde构造方法中做了哪些初始化工作呢？
Glide(
Context context,
Engine engine,
MemoryCache memoryCache,
BitmapPool bitmapPool,
ArrayPool arrayPool,
RequestManagerRetriever requestManagerRetriever,
ConnectivityMonitorFactory connectivityMonitorFactory,
int logLevel,
RequestOptions defaultRequestOptions) {
this.engine = engine;
this.bitmapPool = bitmapPool;
this.arrayPool = arrayPool;
this.memoryCache = memoryCache;
this.requestManagerRetriever = requestManagerRetriever;
this.connectivityMonitorFactory = connectivityMonitorFactory;
DecodeFormat decodeFormat = defaultRequestOptions.getOptions().get(Downsampler.DECODE_FORMAT);
bitmapPreFiller = new BitmapPreFiller(memoryCache, bitmapPool, decodeFormat);
final Resources resources = context.getResources();
registry = new Registry();
registry.register(new DefaultImageHeaderParser());
registry.register()...append()...
ImageViewTargetFactory imageViewTargetFactory = new ImageViewTargetFactory();
glideContext = new GlideContext(context, registry, imageViewTargetFactory,
defaultRequestOptions, engine, this, logLevel);
}
这里首先是把传递进来的参数赋值给成员变量，然后创建了几个重要的对象：
①：Registry对象
Registry主要是添加很多的注册或解析方式等，这在后面用来解析是从内存，文件或是网络获取资源有着重要的作用，而且它每一类解析方式都会提供多个方法，一种方式获取不到将会使用另外一种，知道获取到资源为止，来看下它的register和append方法：
主要是存放到不同的对象中的集合变量中。
②：GlideContext对象
GlideContext对象在后面也扮演中重要的角色，创建这个对象到目前为止只是为了初始化和赋值：
总结下Glide，Registry和GlideContext对象所初始化的参数：
这是到目前对象所拥有的成员方法和成员变量。
ok，再回到上面build方法，在返回Glide对象后，调用getRequestManagerRetriever()从而获取到RequestManagerRetriever对象，从上面Glide类图我们也可以看出，Glide对象已包含RequestManagerRetriever对象。
再往上返回一步，在getRetriever(activity)方法中获取到RequestManagerRetriever对象后，调用get(activity)来获取RequestManager对象，那么我们来看看它是怎么获取到的？
首先判断是否在子线程执行，否则就调用supportFragmentGet方法来获取RequestManager对象，那么来看下它的源码：
还记得我们的RequestManagerRetriever拥有哪些成员吗，不记得就去看看上面它的类图吧，由它的源码我们可以看到它将会使用factory并调用它的build方法，还记得factory是什么吗？上面已分析factory就是DEFAULT_FACTORY，那来看看它的源码实现：
在build中创建一个RequestManager对象并返回，来看下RequestManager的构造方法中做了哪些操作：
RequestManager(
Glide glide,
Lifecycle lifecycle,
RequestManagerTreeNode treeNode,
RequestTracker requestTracker,
ConnectivityMonitorFactory factory) {
this.glide = glide;
this.lifecycle = lifecycle;
this.treeNode = treeNode;
this.requestTracker = requestTracker;
final Context context = glide.getGlideContext().getBaseContext();
connectivityMonitor =
factory.build(context, new RequestManagerConnectivityListener(requestTracker));
if (Util.isOnBackgroundThread()) {
mainHandler.post(addSelfToLifecycle);
} else {
lifecycle.addListener(this);
}
lifecycle.addListener(connectivityMonitor);
setRequestOptions(glide.getGlideContext().getDefaultRequestOptions());
glide.registerRequestManager(this);
}
主要是赋值，添加生命周期监听器，设置请求属性，以及注册请求管理器，代码还是很简单的，都能看的明白。
来看下它的类图：
ok，到此，我们的with方法中获取RequestManager对象就已完成。
来看下with方法执行的顺序图：
注：流程图看不清楚，可以选择在“新标签中打开图片”查看。
load()
在调用with方法获取到RequestManager对象的前提下，调用load方法，并传递我们的url参数，来看下它的源码：
这里并没有直接的去加载我们的url获取资源，而是首先调用asDrawable方法来配置图片的信息，其实就是说加载获取的图片资源是转换为drawale或是bitmap或是gif进行图片显示，默认的是使用drawale，你也可以使用asGif()/asBitmap()来设置它是已什么形式来展示。这里我们按默认的方式来分析。
load方法目的是为了获取RequestBuilder对象，下面来一步步分解它源码：
首先来看下asDrawable()的源码：
asDrawable()中首先调用as方法，并传进Drawable.class作为参数，来看下as方法的源码：
由as方法，我们可看到它直接的创建一个RequestBuilder对象，并传递了相关的参数进去，这里要注意下resourceClass就是Drawable.class这里在后面有个选择分支时使用到。
来看下RequestBuilder的构造方法中做了哪些初始化布局。
很简单的赋值，这里也需要注意的是transcodeClass就是Drawable.class类。
ok，获取到RequestBuilder对象后，它又做了进一步的赋值操作，就是在transition方法中，
把创建的DrawableTransitionOptions对象赋值给transitionOptions变量。
ok，再往上来看，完成asDrawable方法对RequestBuilder的创建后才调用load方法来传递我们的url地址，其实在load也没有做什么事，就是一个中转站，转给了loadGeneric方法，来看：
在loadGeneric方法中也没做其他太多的操作，也是保存了我们的url并且isModelSet设置为true，意思就是说Model已有设置了。来看下它的类图：
它到目前为止所包含的成员变量和方法都在此。
ok，到此我们的load方法也分析完毕，来看下它的流程图：
注：流程图看不清楚，可以选择在“新标签中打开图片”查看。
由于Glide源码很是复杂，写的很长，所以只能分两篇来发布，第一篇分析了Glide的with和load方法源码，第二篇将会分析into方法，说实在的into方法复杂程度远超过with和load方法总和，但是没关系，还是保持一贯的风格，一步步的分析其执行流程，相信大家学完肯定能完全的掌握它的源码结构。
ok，今天就先发布这一篇吧。
各位如果还有哪里不明白的，或是我这里讲的还不够透彻，亦或是讲错了的地方请留言指正，让我们共同进步，谢谢
同时，请大家扫一扫关注我的微信公众号，虽然写的不是很勤，但是每一篇都有质量保证，让您学习到真正的知识。