Glide源码解析第一篇

在Android开发过程中，加载图片是日常开发中最普通的操作了，市面上也有很多的优秀图片处理框架，如开源组织Square出品的Picasso，Android Universal Image Loader，Glide等，但是到现在最常用的，强大的开源框架是Glide.也是Google官网推荐使用的图片处理框架。所以在这里对Glide进行分析。

本系列分为几个步骤进行解析：从Glide最简单的使用来看：

Glide.with(this).load(R.drawable.ic_launcher_background).into(ivPic);

我分为三个步骤：

第一步：with()-------------------------> 生命周期管理，空白的Fragment管理

第二步：load()-------------------------> 构建出RequestBuilder对象等(后面文章再细讲)

第三步：into()------------------------->1.运行队列，等待队列 2.活动缓存，内存缓存 3.网络模型(后面文章再细讲)

因为这三个方法我觉得是Glide的精髓部分，就是这三个方法构成了整个加载图片的体系，用户使用起来，可能觉得很简单，但是在方法背后是有成堆的代码去维护它，解析这个框架的确是有难度的。

本文目录:

1.Glide的使用。

2.Glide的with()源码分析。

3.仿照源码手写一个Glide的with()调用流程。

4.总结。

一.Glide的使用：

第一步：引入(app module)

第二步：在代码中使用

第三步：显示的效果:

以上几步是Glide最简单也是最重要的应用，这里就不多说了。

二.Glide的with()源码分析：

在这里要抓住主线：with主要是感知生命周期，按照正常流程来说，我们使用一次Glide就得释放一次Glide的内存：

这个操作给用户来说是存在不确定性因素的，所以在这里进行感知生命周期，自己去完成一系列的操作。

Glide是怎么监听生命周期的呢？

简述：一个Activity有onStart()方法和onStop等生命周期方法，然后Glide搞了一个空白的Fragment进去，当执行onStrat的时候或者onStop都会被感知。RequestManager 会接收到onStart和onStop的请求。去通知Glide的其他类。比如ImageViewTarget .当Glide进行请求的时候，用户把页面销毁了，则在ImageViewTarget通过onStop就可以把所有正在请求的任务全部停止了。

从with进入：会跳转到Glide类，记住with里的参数如果是从Actiivty进入的就是Activity的环境(具体分析是从哪里进入的，则对应相应的环境)。：

可以看到有多个重载的方法，参数对应不同的环境

我们选择一个看：with(Context)

发现不管中间经历了什么最后一定是返回RequestManager。

从getRetriever()进入：

发现它返回的是RequestManagerRetriever。（调用RequestManagerRetriever的get方法去返回RequestManager）

从get()进入：跳转到RequestManagerRetriever类，我觉得它是管理RequestManager的类

在这里引入一个作用域的问题，其实这个作用域在上面已经讲到过了。分析上面一段代码：

第114行：判断是否在主线程中，并且上下文环境如果是Application则直接跳到124行。

第124行进入：

可以发现没有添加任何的fragment,在这里可以得出一个结论：如果不是在主线程中，并且上下问环境如果是Application就不用感知生命周期了，也就不需要添加空白的Fragment了。

如果是从主线程中进入，并且上下文环境不是Application,则我们选一行进行分析，其他一致，比如传入的环境是FragmentActivity则进入：

第115行：照样进行判断如果是子线程，则走上面一样的方法，不是进入else

上面代码可以看到增加了一个fragement.证实上述验证是正确的。

总结：1.子线程 Application作用域不会搞空白的Fragment

2.主线程非Application作用域会弄一个空白的Fragment监听

接下来我们要进入那个空白的Fragment进行分析，因为要看一下它是怎么感知生命周期的

上述代码可以看到SupportRequestManagerFragment就是空白的Fragment，这里可能对应的包不一样，空白的Fragment也就不一样，但是总体的流程代码是一样的，所以这里只分析这个SupportRequestManagerFragment。

进入SupportRequestManagerFragment：会发现没有任何的ui只有这几个重要的回调：lifecycle其实就是ActivityFragmentLifecycle的实例，先记住。

到这里会发现都是通过lifecycle发送通知的。

不得不去分析一下lifecycle ：是一个接口：

它由以下类进行调用，很清晰的发现，是activity/fragment的就给ActivityFragmentLifecycle 是application或者子线程就给ApplicationLifecycle

在上面的分析中有一个这样的截图：

看画红线的地方这是子线程或者上下文环境是Application进入的：

发现它只是在注册的时候会启动onStart()方法，但是注销确没做任何事，这是因为它是跟着app的生命周期进行活动的。只要app启动了，就会走onStart()方法，app销毁了，则Glide的自然也就销毁了。

来看看ActivityFragmentLifecycle：这是面向某个页面的生命周期：

在removeListener 和 addListener中发现还有一个接口，我们都是操作这个接口LifecycleListener：

现在可以连起来了：

在空白的fragemnt感知到onStart()或者相关生命周期后：lifecycle实际上就是：ActivityFragmentLifecycle

会调用到ActivityFragmentLifecycle的onStart();这个onStart()并不是接口的onStart()，而是代码写的onStart();

随后会对LifecycleListener的onStart()进行调用.主要是遍历这个集合();

而前面提到要返回的RequestManager实现了这个接口的LifecycleListener，所以调用后会给通知到RequestManager，RequestManager再继续向有关方法发送相关业务的指令。

RequestManager大概源码精简了的：

流程总结：

1.空白Fragment感知到Activity的生命周期变化后，会进行调用ActivityFragmentLifecycle的onStart()方法，

2.进而会调用Set<LifecycleListener> 这个集合：遍历调用LifecycleListener 的相关三个方法

3.通知RequestManager去通知相关类(比如ImageViewTarget）做相关业务。

至此with()的大概流程操作至此结束。

三.仿照源码手写一个Glide的with()调用流程。

1.首先先写完Glide(仿照):

2.RequestManagerRetriever:

3.RequestManager

4.Lifecycle

5.LifecycleListener

6.ActivityFragmentLifecycle

7.ApplicationLifecycle

8.SupportRequestManagerFragment

代码至此完成，调用查看打印：

当进入页面的时候:

当退出页面的时候:

对于为什么先执行onStop的问题：

可以看到注册之后，isStarted,isDestroyed都是false.

四.总结

Glide的源码非常庞大，所以要分析源码，把握住主线即可，看每个方法的主要功能是什么，比如with主要是跟生命周期的问题。那就围绕着这个问题去分析，流程打通，就可以了。