Glide流程分析
说到图片加载框架，大家最熟悉的莫过于Glide了，但我却不推荐简历上写熟悉Glide， 除非你熟读它的源码，或者参与Glide的开发和维护。然而很多小伙伴对于Glide的流程及其源码解读总是无从下手，本篇就从三条主线来分析一下Glide流程及源码！
第一条主线
加入队列流程：
RequestManager with = Glide.with(this);
RequestBuilder<Drawable> load = with.load(url);
load.into(iv); // 前面的暂时先不看，当调用into方法后，说明加载图片的请求才真正开始
继续调用
return into(
glideContext.buildImageViewTarget(view, transcodeClass),
/*targetListener=*/ null,
requestOptions);
继续跟踪，会发现以下代码
requestManager.clear(target);
target.setRequest(request);
requestManager.track(target, request);//发送请求开始的地方
void track(Target<?> target, Request request) {
targetTracker.track(target);
requestTracker.runRequest(request);//从名字看叫运行请求
}
继续跟踪
通过该方法得知Glide也有两个队列；运行队列和等待队列；
public void runRequest(Request request) {
requests.add(request);//加入运行队列；
if (!isPaused) {
request.begin();//开始执行
} else {
pendingRequests.add(request);//加入等待队列
}
}
第二条主线
请求如何运行？
在第一条主线中，request.begin()方法就是真正开始执行请求的时候；先找到request的实现类：SingleRequest，找到其begin方法；
为什么找到的是SingleRequest？
在第一条主线的RequestBuilder.into方法中有一句代码；
Request request = buildRequest(target, targetListener, options);
继续跟踪它
buildRequestRecursive() 找到构建request的方法；
在该方法中，又能跟踪到
Request mainRequest = buildThumbnailRequestRecursive()
继续跟踪
Request fullRequest =
obtainRequest(
target,
targetListener,
requestOptions,
coordinator,
transitionOptions,
priority,
overrideWidth,
overrideHeight);
上述代码块最终调用的是SingleRequest.obtain()方法，从而得到一个SingleRequest对象；所以能得出结论，request.begin（）方法被调用时，即调用了SingleRequest的begin方法；继续跟踪begin方法，会发现onSizeReady方法；
onSizeReady(overrideWidth, overrideHeight);
在begin方法中跟踪到engine.load方法，如下（只抽取了部分代码）：
// 从活动缓存中获取
EngineResource<?> active = loadFromActiveResources(key, isMemoryCacheable);
if (active != null) {
cb.onResourceReady(active, DataSource.MEMORY_CACHE);
if (Log.isLoggable(TAG, Log.VERBOSE)) {
logWithTimeAndKey("Loaded resource from active resources", startTime, key);
}
return null;
}
// 从内存缓存中获取
EngineResource<?> cached = loadFromCache(key, isMemoryCacheable);
if (cached != null) {
cb.onResourceReady(cached, DataSource.MEMORY_CACHE);
if (Log.isLoggable(TAG, Log.VERBOSE)) {
logWithTimeAndKey("Loaded resource from cache", startTime, key);
}
return null;
}
// 硬盘缓存，硬盘缓存也是io操作，所以也使用了线程池；动画线程池
EngineJob<?> current = jobs.get(key, onlyRetrieveFromCache);
if (current != null) {
current.addCallback(cb);
if (Log.isLoggable(TAG, Log.VERBOSE)) {
logWithTimeAndKey("Added to existing load", startTime, key);
}
return new LoadStatus(cb, current);
}
EngineJob<R> engineJob =
engineJobFactory.build(
key,
isMemoryCacheable,
useUnlimitedSourceExecutorPool,
useAnimationPool,
onlyRetrieveFromCache);
DecodeJob<R> decodeJob =
decodeJobFactory.build(
glideContext,
model,
key,
signature,
width,
height,
resourceClass,
transcodeClass,
priority,
diskCacheStrategy,
transformations,
isTransformationRequired,
isScaleOnlyOrNoTransform,
onlyRetrieveFromCache,
options,
engineJob);
jobs.put(key, engineJob);
engineJob.addCallback(cb);
engineJob.start(decodeJob); //具体的加载，engineJob为加载管理类，decodeJob则为将返回的图片数据进行编码管理的类；
调用engineJob.start()方法后，则会执行以下代码：
public void start(DecodeJob<R> decodeJob) {
this.decodeJob = decodeJob;
GlideExecutor executor = decodeJob.willDecodeFromCache()
? diskCacheExecutor
: getActiveSourceExecutor();
executor.execute(decodeJob);
}
继续跟踪找到DecodeJob的run方法；
DecodeJob.run() 继续调用 runWrapped(); 再继续调用getNextGenerator()
private DataFetcherGenerator getNextGenerator() {
switch (stage) {
case RESOURCE_CACHE:
return new ResourceCacheGenerator(decodeHelper, this);
case DATA_CACHE:
return new DataCacheGenerator(decodeHelper, this);
case SOURCE:
// 根据主线我们目前都先不去处理跟Cache相关的类，直接进入SourceGenerator；这里使用了设计模式-状态模式；（请自行根据第二节内容进行查询）
return new SourceGenerator(decodeHelper, this);
case FINISHED:
return null;
default:
throw new IllegalStateException("Unrecognized stage: " + stage);
}
}
继续跟踪到SourceGenerator类中的startNext方法；
loadData.fetcher.loadData(helper.getPriority(), this);
根据fetcher找到HttpUrlFetcher，并找到对应的loadData方法；最终发现Glide是通过HttpUrlConnection访问的服务器，并返回最终的stream；
问题来了？我怎么知道是这个类的？为什么不是其他类？在这里代码就看不懂了，怎么办？猜测；
既然应该不是再继续从缓存拿，而应该要去访问网络了；所以找到具体访问网络的；发现找不到，怎么办？
找它的实现类，有一个HttpUrlFetcher，那它在哪里初始化的？
通过Find Usages找到哪里调用了--->找到了HttpGlideUrlLoader；
再看这个方法HttpGlideUrlLoader哪里调用了；
找到了Glide，继续往上寻找，找打了Glide种的build方法 ，找就能找到Glide.get(context);方法
第三条主线
队列怎么维护的？在MainActivity中我们调用了如下代码：
RequestManager with = Glide.with(this);
继续跟踪到
getRetriever(activity).get(activity)//这里得到了一个RequestManagerRetriever对象,再通过RequestManagerRetriever调用get方法得到RequestManager
继续往下
androidx.fragment.app.FragmentManager fm = activity.getSupportFragmentManager();
return this.supportFragmentGet(activity, fm, (Fragment)null);
通过this.supportFragmentGet方法（如下代码），最终我们得到SupportRequestManagerFragment对象；
private RequestManager supportFragmentGet(@NonNull Context context, @NonNull androidx.fragment.app.FragmentManager fm, @Nullable Fragment parentHint) {
SupportRequestManagerFragment current = this.getSupportRequestManagerFragment(fm, parentHint);//这段代码的内部如果能够得到Fragment就得到，得不到就重新new一个，并且这个fragment中没有进行任何的UI处理；
RequestManager requestManager = current.getRequestManager();
if (requestManager == null) {
Glide glide = Glide.get(context);
requestManager = this.factory.build(glide, current.getGlideLifecycle(), current.getRequestManagerTreeNode(), context);
current.setRequestManager(requestManager);
}
return requestManager;
}
得到Fragment对象后，再将RequestManager对象赋值进去，如果RequestManager为空，则帮助创建；
而RequestManager对象则是生命周期管理的重要一环，因为它实现了LifecycleListener接口，并且在创建RequestManager的时候，会将这个接口设置给自己；也就意味着，Glide创建了一个无UI的fragment，这个fragment又与RequestManager进行绑定；当用户的activity或者fragment被调用，系统会自动调用fragment的生命周期方法；而生命周期方法中又会回调LifecycleListener的方法，进而调用RequestManager，RequestManager则也拥有了生命周期；
当RequestManager的onStart方法被调用后，会通过一系列的调用，将运行中的请求全部放开，进行访问；
当onStop方法被调用时，则将运行中队列的数据取出来，如果当前请求正在运行则暂停，然后将所有的数据从运行队列中添加到等待队列中去；
当onDestory方法被调用时，则将运行队列和等待队列中的数据全部清除；再将监听移除；将requestManager从Glide中的绑定关系解除；
