Glide3.6.1源码解析

本文以自己理解从glide入口开始分析，主要是记录下整个学习流程，以后忘记再回顾看看。

首先从基本用法开始，with方法通过传入一个context

在这里声明了一个RequestManagerRetriever方法，并new了一个handler

再回到RequestManager的get方法，首先判断context是否为null,判断完是否在主线程且context不是application再这里可以看到分支处理。进入第一层判断当前context等于fragmentActivityde get方法

在这个判断当前进程是否为主线程，如果不是返回application的context的

判断当前版本是否大于4.2且activity是否已经被销毁，是的话抛出异常You cannot start a load for a destroyed activity

再回到supportFragmentGet方法，首先拿到一个当前com.bumptech.glide.manager的fragment，当fragment为null的时候，从map集合pendingSupportRequestManagerFragments中拿 如果还是为null直接new了一个SupportRequestManagerFragment再以key为当前activty，添加到pendingSupportRequestManagerFragments集合里，再添加一个fragment，然后发送一个ID_REMOVE_SUPPORT_FRAGMENT_MANAGER的id到handler

当系统调用SupportRequestManagerFragment.onAttach方法时，调用registerFragmentWithRoot方法，将Fragment的子Fragment关联的SupportRequestManagerFragment 添加到childRequestManagerFragments里。当调用onDetach方法时，说明Fragment不再和Activity相关联，这时要将SupportRequestManagerFragment从childRequestManagerFragments里移除，并将rootRequestManagerFragment置为空。 接下去回到supportFragmentGet方法

当RequestManager为null的时候创建了一个RequestManager传入参数context和fragment生命周期，new了一个RequestTracker实例，ConnectivityMonitorFactory判断网络请求的实例

这里主要是把生命周期的监听加入其中，再回到get方法下getApplicationManager

到这一步我们就知道了glide的生命周期 onstart，onstop,ondestroy

接下去request的load方法

主要是给ModelType赋值，接下去into方法（重点）

这里如果图片有ScaleType属性，就重写

判断clazz属于什么类型然后实例化

这里可以看到控件封装成的Target能够获取自身绑定的请求,当发现之前的请求还在的时候,会把旧的请求清除掉,绑定新的请求,这也就是为什么控件复用时不会出现图片错位的问题(这点跟我在Picasso源码中看到的处理方式很相像).

我们先看load方法的前面一段:

1.首先会尝试从cache里面取,这里cache就是Glide的构造函数里面的MemoryCache(是一个LruResourceCache),如果取到了,就从cache里面删掉,然后加入activeResources中

2.如果cache里面没取到,就会从activeResources中取,activeResources是一个以弱引用为值的map,他是用于存储使用中的资源.之所以在内存缓存的基础上又多了这层缓存,是为了当内存不足而清除cache中的资源中,不会影响使用中的资源.

load方法接着会通过EngineJobFactory创建一个EngineJob,里面主要管理里两个线程池,diskCacheService和sourceService,他们就是Glide构造函数中Engine里面创建的那两个线程池.

接着说load方法,前面创建了EngineJob,接着调用EngineJob的start方法,并将EngineRunnable放到diskCacheService(处理磁盘缓存的线程池里面运行),接着线程池就会调用EngineRunnable的run方法.

run里面调用的是decode()方法,里面会尝试先从磁盘缓存中读取,如果不行就从源资源中读取

我们可以看到这里先尝试读取处理后的图片(Result),然后再尝试读取原图,但是这里面具体逻辑会根据你设置的磁盘缓存策略来决定是否真的会读取处理图和原图

那么我们再回到EngineRunnable的run()方法中

第一次走decode的时候会先尝试从磁盘中获取,如果获取的为null,那么在onLoadFailed方法里面又会把这个run再次放入线程池中,但是这次是放入sourceService(处理源资源的线程池)

Glide的整个加载流程就基本上走完了,整个篇幅还是比较长的,第一次看得时候可能会有点懵逼,需要结合着源码多走几遍才能够更加熟悉.

一个是能够更加熟悉这个框架,那么使用的时候就更加得心应手了,比如我从源码中发现了很多文章都说错了默认的缓存策略

一个是学习里面的设计模式和思想,应用到我们自己的项目中,比如说面对接口编程,对于不同的数据,用DataFetcher的不同实现类来拉取数据