Glide4.6.1原理解析
2018-07-13 14:55:39 2 举报Android Glide图片加载框架原理解析
作者其他创作
大纲/内容
RequestManagerRetriever第140行Activity获取RequestManager方式是fragmentGet
ecodeJob的466行decodeFromFetcher方法通过decodeHelper获取解码模块，然后通过498行的path.load运行解码模块
RequestBuilder的618行requestManager.track正式开始请求
RequestBuilder的1020行obtainRequest方法，是通过SingleRequest的obtain来构建，SingleRequest是Glide中所有请求的唯一实现
GIF加载流程
GifFrameLoader的212行会去预加载下一帧
通过各模块返回了LoadData，然后通过loadData的loadData方法去加载图片数据
Glide的160行get方法当glide为null的时候会调用checkAndInitializeGlide(context);
RequestBuilder的847行buildRequest方法会传递给buildRequestRecursive来构建Request，增加了变换参数，优先级，视图宽高
Glide的708行with(Activity)
DecodeJob的448行decodeFromData方法decodeFromFetcher
RequestTracker的42行，调用了request.begin();也就是会调用唯一实现类SingleRequest的begin方法
DecodeJob的294行getNextGenerator方法，会根据阶段挑选生产者对象
资源解码准备好后会回调到onResourceReady，然后调用到setResourceInternal，然后调用到子类重写的setResource
是
都是为了获取RequestBuilder通过以下方式获取
Glide的776行with(View)
RequestManagerRetriever第110行获取Context对应的RequestManager
GlideBuilder的406行build方法450行会new Engine
构建参数并加载视图结束
gif加载流程结束
引擎加载图片资源
RequestManagerRetriever第127行FragmentActivity获取RequestManager方式及RequestManagerRetriever第138行FragmentActivity获取RequestManager方式都是supportFragmentGet
RequestManagerRetriever第349行去getRequestManagerFragment拿RequestManager，拿不到就新建，直接从系统FragmentManager里拿，拿不到就新建，ActivityFragmentLifecycle的生命周期
RequestBuilder的862行buildThumbnailRequestRecursive方法的最后面1008行通过obtainRequest来返回Request
返回资源，回调SingleRequest的onResourceReady，结束资源获取
Glide初始化流程
RequesManager的412行load(String)
DataCacheGenerator(数据缓存生产者)46行startNext
......等9个重载方法
RequesManager的424行load(Uri)
SourceGenerator(原始资源生产者)42行startNext
完成Glide的初始化
GlideContext的80行绑定Target
Glide的721行with(FragmentActivity)
是否UI线程
返回RequestManager结束
RequestManagerRetriever第84行获取全局唯一应用级别RequestManager即applicationManager属性
构建请求并加载到界面
DecodeHelper的144行获取解码模块，是通过Registry去获取，那么就会和加载一样到Glide里面去注册了
GifDrawable构造方法里构建了GifFrameLoader，然后再draw方法，会通过这个加载器获取下一帧图像
RequesManager的360行asGif，调用了as方法，传递的是GifDrawable的Class
RequestManger的632行track方法requestTracker.runRequest(request);运行请求（观察者模式）
都是继承自Fragment，都是无界面的，都是为了获取系统的管理生命周期，主要差别就是Support是处理SupportV4的兼容，而另外一个是系统直接兼容的。简单来说就是处理FragmentManager的引用问题
BitmapImageViewTarget的34行view.setImageBitmap
ImageViewTargetFactory类根据转换类型，new出对应的Target
资源填充到界面
Glide223行initializeGlide方法会通过反射获取注解生成的模块、Manifest里写的模块，然后226行写入设置信息，269行注册模块组件
RequesManager的388行load(Bitmap)
RequesManager类的load方法
SourceGenerator的第57行，通过DecodeHelper会从注册模块中获取并buildLoadData
从Glide.with()开始跟进
RequestManagerRetriever第97行通过RequestManagerFactory新建一个RequestManager返回出去，生命周期用应用的生命周期
Glide的662行getRetriever方法返回调用了Glide.get(context)
Glide的709行with方法返回调用了getRetriever(activity)
Glide的365行--417行添加了各种解码器（太多就不画了）
通过HttpUriLoader包装成HttpGlideUrlLoader然后返回输入流，下面去解析这个流
DecodeJob的398行decodeFromRetrievedData方法407行decodeFromData
Engine的182行，去内存缓存中获取
RequesManager的341行asBitmap，调用了as方法，传递的是Bitmap的Class
StandardGifDecode的164行会对GIF帧重复播放进行控制
RequesManager的400行load(Drawable)
SingleRequest的434行onSizeReady方法451行，交给引擎加载，然后返回加载状态，引擎加载完毕会通过回调到SingleRequest里的onResourceReady，然后加载资源到视图
构建请求参数，并加载进视图
ResourceCacheGenerator类92行，通过DecodeHelper会从注册模块中获取并buildLoadData
RequestManagerRetriever第384行去SupportRequestManagerFragment管理器拿RequestManager，拿不到就通过工厂新建。生命周期是当前ActivityFragmentLifecycle的生命周期
RequestBuilder的645行into方法，就开始把图片加载到视图里面去了。看646行，不是主线程就会抛异常了，然后读取view的Scale参数来修改掉默认的请求参数
DecodeJob的294行runGenerators方法300行stage = getNextStage(stage);会去挑选当前运行的阶段，获取生产者，并在299行currentGenerator.startNext()去执行这个生产者，301行去挑生产者
开始请求gif
Engine的173行，去活跃资源里获取，活跃资源通过弱引用抓着资源
从Glide.with跟进，有如下重载方法
RequesManager的546行as方法，返回的是根据传递的Class，new出来的RequestBuilder，new出来的RequestBuilder是读取了全局设置的默认构建请求信息的，我们拿到了这个默认的，就可以对每个请求的默认配置信息进行修改了
进入到RequestManagerRetriever复用RequestManager管理器里获取对应的RequestManager对象
开始播放是在ImageViewTarget里的OnStart里，然后就开始gif的播放了
模块是通过Registry的401行append方法注册进ModelLoaderRegistry模块注册器的
RequesManager的376行asDrawable，调用了as方法，传递的是Drawable的Class
获取RequestManager请求管理器
RequestBuilder的586行into方法滴597行buildRequest构建请求信息，传递了target，target监听，配置参数
加载数据完成后会调用到DecodeJob的363行onDataFetcherReady，注意里面修改了runReason = RunReason.DECODE_DATA;376行去解码
RequestBuilder的862行buildRequestRecursive方法979行获取构建图片请求（递归调用）
DrawableImageViewTarget的27行view.setImageDrawable
EngineJob的115行，发现是线程池去执行decodeJob，那么做的事情就在decodeJob的run方法里了
否
设置到对应的视图中，完成整个流程
Glide类的421行到482行注册了各种加载器，生成加载器是通过工厂模式（太多了，就不画了）
获取到了资源，开始填充到视图
Glide的696行with(Context)
都是继承自ImageViewTarget、ViewTarget、BaseTarget实现了生命周期回调
Glide的733行with(Fragment)
我们已经了解了构建请求，下面我们回到RequestBuilder的599行和上次这个视图的请求比较一下，如果是以前的请求，则释放掉当前的，继续以前的请求。不是的话，则保存新的请求
ResourceCacheGenerator（资源缓存生产者）41行startNext
会到StreamGifDecoder，看decode方法，会被包装成byteBufferGifDecoder
DataCacheGenerator的第69行，通过DecodeHelper会从注册模块中获取并buildLoadData
经过StringLoader，包装成HttpUriLoader
Glide的Engine是如何工作的
DecodeHelper的184行getModelLoaders方法通过glideContext.getRegistry()去获取模块列表
Engine的268行去内存缓存中获取资源，内存缓存cache是我们一开始GlideBuider时传递的缓存
SingleRequest的226行begin方法262行当大小准备好后，会运行onSizeReady方法
GifFrameLoader的225行加载下一帧的时候会构建一个DelayTarget通过GifFrameResourceDecoder的解码，获取下一帧的内容
DecodeJob类的217行run方法230行把run包装了出去
DecodeJob类的217行runWrapped方法开始请求资源工作流，会根据当前的运行阶段，判断试运行本地加载资源、服务端获取资源还是解码资源
开始加载资源，调用到Engine的148行load方法170行通过主键工厂获取引擎资源唯一key
获取RequestManager流程
收藏
0 条评论
下一页
