接着上一次https://www.cnblogs.com/webor2006/p/12324332.html的源码继续分析。
Glide框架源码分析：
Request.begin()：
在上一次中已经分析到了这：
也就是准备要开始发起请求了：
那这个engine是在哪创建的呢？
而这个GlideContext是在构建的：
Engine.load()：
好继续回到主流程：
首先从活动资源中来查找，如之前我们手写的流程一要，如果找到，则会回调onResourceReady方法，咱们看一下它回调的处理：
嗯，整个流程则通了，接下来继续回到主流程：
下面具体来看一下：
原来DecodeJob是一个线程，那很明显这个EngineJob肯定有线程池，为啥？
能启动线程基本上都会用线程池的，跟进去验证一下：
妥妥的，接下来直接来看一下加载线程执行的逻辑。
DecodeJob.run()：
看一下生成器的构建：
很明显首先是拿磁盘加载器来加载，为啥？
所以开始来使用一下这个生成器：
其中咱们注册了一个Bitmap解码器，从InputStream到Bitmap，如下：
看一下这个解码器的大致内容：
好，回到主流程：
其实它里面就是判断有没有注册解码器：
而它则是我们在注册机中添加的解码器：
好，回主流程继续往下分析：
而此时cb是在它的构造方法中来传过来的：
所以最终的回调会到DecodeJob，如下：
此时再往下回调：
以上是在磁盘缓存中获取到了图片，但是！！假如没有获取呢？接下来则就需要加载原始图了。
SourceGenerator：原数据生成器
此时又回到DecodeJob.run()方法中：
而它里面的逻辑跟DataCacheGenerator差不多，只是加载器不一样了而已，如下：
此时的Loader则为：
接下来的回调流程就跟之前分析的那个是一样的了，就不再分析了。至此整个关于Glide的加载主流程就分析完了，要是手写的话还真得挺难的，先把主流程搞清楚。
生命周期管理：
关于Glide生命周期的管理在上面分析Glide的整体加载流程时也提及到了，它内部其实是用了一个Fragment来进行管理的，但是只是提及了一下分析得不够详细，所以接下来再彻底的分析一下这块，毕境这块也是非常重要的，先贴一下整个Glide生周周期相关的类图：
下面则以此为蓝本进行分析，先来从头来定位到生命周期的源代码处：
我们只来关注是在FragmentActivity中使用情况下的生命周期，好继续往下：
这里有一个很奇怪的代码：
这个在博主这块https://www.jianshu.com/p/14dbc0c609ec有详细说明，这里直接贴出来理解一下：
这里有个问题，为什么需要使用pendingRequestManagerFragments这样一个集合来临时存储一下fragment，然后又马上通过handler发送消息移除？这其实是跟主线程的Looper机制和Fragment的事务机制有关的。我们知道，android中的主线程是一个闭环，通过Handler发送消息到MessageQueue，然后通过Looper轮询获取消息并交给Handler处理。如下面一个常见场景：
Glide.with(this).load(url_1).into(mImageView_1); Glide.with(this).load(url_2).into(mImageView_2);这段代码通过Glide加载了两张图片并设置到了两个ImageView上，当以上代码块执行时，其所属的代码群的Message刚刚从MessageQueue中取出正在被处理，我们假设这个Message为m1，并且这个MessageQueue中没有其他消息。此时情形是这样的：
当代码执行到getRequestManagerFragment这个方法时，会通过开启事务的方式来绑定这个fragment到activity，相关源码如下，这个方法在FragmentManagerImpl.java中：
public void enqueueAction(Runnable action, boolean allowStateLoss) { if (!allowStateLoss) { checkStateLoss(); } synchronized (this) { if (mDestroyed || mHost == null) { throw new IllegalStateException("Activity has been destroyed"); } if (mPendingActions == null) { mPendingActions = new ArrayList<Runnable>(); } mPendingActions.add(action); if (mPendingActions.size() == 1) { mHost.getHandler().removeCallbacks(mExecCommit); mHost.getHandler().post(mExecCommit); } } }这里的mHost其实就是activity创建的，并且持有activity以及mMainHandler的引用，根据上述代码可以知道，其实绑定fragment的操作最终是通过主线程的handler发送消息处理的，我们假设这个消息为m2。然后handler.obtainMessage(ID_REMOVE_FRAGMENT_MANAGER, fm).sendToTarget();这句代码发送的消息为m3。那么当Glide.with(this).load(url_1).into(mImageView_1);这句代码执行这里时，消息队列有了变化：
但是m2这个消息并不会马上被处理，这是因为m1还有代码还没有执行完毕，也就是说这个fragment并不会马上被绑定，此时m1继续向下执行到第二句代码Glide.with(this).load(url_2).into(mImageView_2);当这句代码走到getRequestManagerFragment时，如果在m1时，我们不将fragment临时存储在pendingRequestManagerFragments中，由于m2还没有被处理，那么
RequestManagerFragment current = (RequestManagerFragment) fm.findFragmentByTag(FRAGMENT_TAG);必然是找不到这个fragment的，那么就会导致重新创建一个新的重复的fragment，并开启事务绑定，这显然是不合情理的，因为Glide需要保证rootFragment的唯一性，rootFragment即fragment依附或者没有fragment依附的activity所创建的最上层RequestManagerFragment。
也就是说：
上面的策略也就保证了在FragmentActivity中只有一个供Glide管理生周期的Fragment，不会生成多个，另外对于Fragment提交方式除了上图所用的：
还可以用：
这俩有啥区别呢？对于commit()来说是立马提交，但是如果出现提交失败的情况则会造成应用崩溃；而commitAllowingStateLoss()它允许处理消息丢失，但是不会造成应用崩溃的。
好，接下来看一下SupportRequestManagerFragment：
这个类就是生命周其的监听类，然后它里面就有添加监听的方法：
另外它实现了一个Lifecycle的接口：
而注册生命周期的监听在这：
也就是如果不是在前台了则所有图片的请求都会停止掉，而如果再回到前台时又会恢复请求，真心觉得这块还是挺复杂的，关于Glide的生命周期核心原码就分析到这了。
FAQ：
1、既然你已经看过了Glide的源码，那你分析过来印象最深刻的是啥呢？
缓存机制。
2、那Glide中到底都有哪机缓存机制呢？
三大缓存：弱引用缓存（活动资源）、LRU内存缓存、磁盘缓存。
3、Glide中的各缓存读取图片和写入图片的顺序又是什么样的呢？
写入：弱引用(活动资源)----->LRU内存缓存------>磁盘缓存。
读取：LRU内存缓存----->弱引用(活动资源)------>磁盘缓存。
4、如果叫你来设计Glide这样的框架，打算怎么设计呢？
大致可以这样：
好，关于Glide框架的学习就到这，收获颇多~~