简介
1 | Glide.with(this) |
Glide加载执行流程
- 创建request
- 执行加载
- 回调刷新UI
创建request
with()
从Glide.with()开始
1 | public static RequestManager with(Activity activity) { |
所有with()均返回了一个RequestManager,进入getRetriever()
1 | private static RequestManagerRetriever getRetriever( { Context context) |
Glide通过DCL创建单例,然后RequestManagerRetriever对象通过Glide单例获取。返回到上面 getRetriever().get()
1 |
|
get方法重载参数虽然很多,但最终就返回两种类型的requestManager。一种是ApplicationManager,它自动和应用的生命周期同步,应用退出,Glide也就停止加载;另外一种则是带有Fragment生命周期的requestManager。对应上述代码中注释,可以看出,Glide添加一个隐藏的Fragment,获取对应的生命周期回调事件,这样就可在Activity销毁时停止加载图片了。这种方式比较巧妙,不仅是Glide,RxPermission项目也是这样使用的。
小结:Glide.with():它主要完成了Glide实例化,并返回requestManager对象。
load(url)
1 | public RequestBuilder<Drawable> load( { Object model) |
返回一个request构造器,接着进入into.
1 | private <Y extends Target<TranscodeType>> Y into( |
进入1处构建request
1 | private Request buildRequest( |
进入obtainRequest中
1 | private Request obtainRequest( |
最终通过RequestBuilder生成了一个SingleRequest实例。这个SingleRequest类中有各种属性,大部分都是默认了,当然可以在使用时通过RequestOptions配置。
执行加载
1 | synchronized void track( { Target<?> target, Request request) |
- 加载完成回调。这里是加载、缩放、转换之后的数据,可直接用于UI显示。后面再分析是怎么回调刷新UI的。
- 这里主要是判断overrideWidth, overrideHeight是否可用。分两种情况:1).如果设置了override(int width, int height) ,直接处理onSizeReady方法逻辑。2).没有设置override,Glide就会等到系统计算完组件宽高后再回调onSizeReady。所以两种情况最后都会调用onSizeReady方法。
- 开始前,回调设置placeholderDrawable
长宽测量完毕进入onSizeReady()
1 |
|
姗姗来迟的load方法中包含了Glid的缓存策略思想
1 | public synchronized <R> LoadStatus load( |
- 内存:
活动资源 (Active Resources) - 正在显示的资源,保护显示的图片不会被LruCache算法回收掉。
内存缓存 (Memory cache) - 显示过的资源,采取LRU算法置换 - 磁盘:
资源类型(Resource) - 被解码、转换后的资源
数据来源 (Data) - 源文件(未处理过)
进入磁盘缓存的start()
1 | //start方法就是根据diskCacheStrategy策略获取一个executor来执行DecodeJob |
从最开始没有命中内存缓存开始,然后执行Engine的start方法
- 默认情况会获取到cacheExecutor执行器来执行decodeJob任务;
- 继续decodeJob的run方法,因为RunReason==INITIALIZE,接着获取stage,默认会返回Stage.RESOURCE_CACHE,这时通过getNextGenerator就返回了ResourceCacheGenerator加载
- 紧接着就是调用 ResourceCacheGenerator的startNext方法 ,从转换后的缓存中读取已缓存的资源,如果命中则结束任务并回调结果,反之,任务切换到DataCacheGenerator加载器继续执行
- 若还是未命中,则切换到SourceGenerator加载器(第一次加载,由于没有任何缓存,就会走到这里),这时会通过任务调度,将线程运行环境切换到 SourceExecutor执行器来执行,最后,待SourceGenerator加载完成后结束任务,回调结果,流程结束。
网络加载过程
Glide底层是采用HttpUrlConnection进行网络请求,也可更换为OkHttp请求连接。
回调刷新UI
回到DecodeJob类中
1 |
|
DecodeJob加载完数据后,会做转换、磁盘缓存等操作。进入到EngineJob的onResourceReady
1 |
|
回调从Decodejob出来,在EngineJob中切换到主线程并一路回调到DrawableImageViewTarget中,至于为什么默认是DrawableImageViewTarget,请查看RequestBuilder中into方法。下面我们再看下DrawableImageViewTarget相关代码,也是设置显示图片的地方。
1 | ublic class DrawableImageViewTarget extends ImageViewTarget<Drawable> { |
onResourceReady在父类ImageViewTarget中回调,然后调用setResource将图片设置并显示出来。代码执行到这里,回调过程也就结束了。