在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主要是跟生命周期的问题。那就围绕着这个问题去分析，流程打通，就可以了。
网友评论