Glide 源码 4.12.0
文章目录
Glide.with(this).load(url).apply(xxx).into(imageView);
with()
with() 方法是 Glide 类中的一组静态方法,可以传入 Activity Fragment Context View。每个 with()方法都是通过 getRetriever() 得到 RequestManagerRetriever 然后调用 RequestManagerRetriever 的 get() 方法获取 RequestManager 对象
RequestManagerRetriever 的 get() 和 with() 类似,有很多个方法,可以传入 Context Activity Fragment 等参数。这些可以分两种情况,即传入 Application 类型的参数,和非 Application 类型的参数。
传入 Application 参数的情况 :
- 在传入 Context 参数的方法中,通过判断 context 是否是 Application 并且是否在主线程,符合条件则直接通过 getApplicationManager() 来获取一个 RequestManager 对象,否则判断 context 类型调用其他 get() 方法。
- 因为 Application 对象的生命周期即应用程序的生命周期,因此 Glide 并不需要做什么特殊的处理,它自动就是和应用程序的生命周期是同步的,如果应用程序关闭的话,Glide 的加载也会同时终止。
传入非Application 参数的情况 :
- 如果在非主线程当中使用的 Glide 都当成传入 Application 参数的情况来处理。
- 会向当前的 Activity 当中添加一个隐藏的 Fragment 。
- Glide 通过添加隐藏 Fragment 监听生命周期。 例如 Activity 被销毁,Fragment 监听到,就可以停止图片加载。(或者有什么办法直接知道 Activity 的生命周期?)
RequestManager 实现 LifecycleListener 接口去监听生命周期,作出相应的处理
简单的说就是为了得到一个 RequestManager 对象,然后 Glide 会根据传入 with() 方法的参数来确定图片加载的生命周期
Glide 中的 with() ,getRetriever()
|
|
RequestManagerRetriever 的部分 get() 和添加 fragment 的地方
|
|
load()
with() 返回 RequestManager 调用 load(),load() 也有多个,都是调用 asDrawable().load(xxx) 返回 RequestBuilder<Drawable>。
asDrawable() 返回 new RequestBuilder 并把 Drawable.class 作为参数传入 RequestBuilder 构造方法,最终在 RequestBuilder 执行 load() 方法。
RequestBuilder 中 load() 也有多个,都是根据上一步 asDrawable().load(xxx) 中的 xxx 参数类型,调用 loadGeneric(xxx)。
loadGeneric(xxx) 内容如下
|
|
apply()
loadGeneric() 最终返回 BaseRequestOptions ,apply() 方法在 RequestBuilder 中如下,重写了父类 BaseRequestOptions 的 apply() ,在 BaseRequestOptions 的 apply() 中最后和 loadGeneric() 一样,返回了 selfOrThrowIfLocked() 。apply() 可以设置一些参数,如错误时加载图片,占位图等。
|
|
into()
RequestBuilder 调用 into() 设置数据到 Imageview 。这块代码有点多,包括请求失败,占位图,图片长宽等,就不全贴出来了。RequestBuilder 经过 buildRequest 一系列的调用最终 obtainRequest 方法进入到 SingleRequest 。
可以根据状态看执行相关操作,在构造方法中是 status = Status.PENDING; 在 onSizeReady 方法中 status = Status.RUNNING;
可以选择看 model 被做了什么,在 onSizeReady 有个 engine.load 方法把 model 等数据传入 Engine 然后在 waitForExistingOrStartNewJob 中被放入 DecodeJob<R> ,再由 EngineJob 处理 DecodeJob。
DecodeJob 实现了 Runable , FetcherReadyCallback 等接口。在 DecodeJob 中 model 被赋值给 currentData 变量, run 方法 和 重写的 onDataFetcherReady 都会调用到 decodeFromRetrievedData(),在 decodeFromRetrievedData() 中调用 decodeFromData(currentFetcher, currentData, currentDataSource) ,在 decodeFromData 中调用 decodeFromFetcher(data, dataSource) ,最后调用 runLoadPath(data, dataSource, path)。
有点晕,直接着用 debug 的方式看 runLoadPath 方法,data 先是会被处理成 rewinder ,最终在 decodeResourceWithList 方法中通过 decoder.decode 获取到 InputStream 然后转成 Bitmap
大致流程如下:
- RequestBuilder 中的 into 方法调用 buildRequest 由 obtainRequest 方法进入到 SingleRequest
- SingleRequest 的 onSizeReady 中 engine.load 开始处理数据
- Engine 运行 DecodeJob 做各种操作
- 完成后释放资源
SingleRequest 有多个工作状态,按流程执行
DataSource 数据来源,有本地,远程,缓存等
DataFetcher 数据获取接口?
DataRewinder 像是用来把要显示的图片资源接收为流数据?
DataRewinderRegistry 可以获取 DataRewinder
以下源码按顺序阅读
RequestBuilder 的 into() 和 obtainRequest
|
|
SingleRequest 部分代码,由 obtainRequest 方法进入到 SingleRequest
|
|
Engine 部分代码 ,由 SingleRequest 的 onSizeReady 中 engine.load 进入
|
|
DecodeJob 部分代码,由 engineJob.start(decodeJob) 进入
|
|
LoadPath 部分代码
|
|
DecodePath 部分代码
|
|