原理：

在glide中的with方法中，需要传入上下文，他底层都是调用的getretriever方法，当传入fragment的时候，通过fragment.getactivity的activity的实例。getRetriever通过该方法获取了一个requestManagerRetriever实例，调用了get方法。传入的参数，获取到fragmentMannager通过这个得到requestManagerRetriever实例。Glide和页面的生命周期是绑定到一起的，可以感知调用页面的生命周期。

缓存方式：

[if !supportLists]1. [endif]DiskCacheStrategy.NONE不缓存文件

[if !supportLists]2. [endif]DiskCacheStrategy.SOURCE只缓存原图

[if !supportLists]3. [endif]DiskCacheStrategy.RESULT只缓存最终加载的图（默认的缓存略）

[if !supportLists]4. [endif]DiskCacheStrategy.ALL同时缓存原图和结果图

Glide生命周期管理：

Glide在Glide.with(context)中就实现了生命周期管理，with根据传入的参数有不同的实现。

//传入一个Context    public static RequestManager with(@NonNull Context context)

 //传入一个activity  public static RequestManager with(@NonNull Activity activity)

  //传入一个FragmentActivity  public static RequestManager with(@NonNull FragmentActivity activity) 

 //传入一个Fragment  public static RequestManager with(@NonNull Fragment fragment) 

 //传入一个View  public static RequestManager with(@NonNull View view)

虽然有这么多类型，但其实可以分为两类的。

传入一个ApplicationContext，Glide的生命周期就相当于绑定了整个应用，只要应用不退出，任何时候都能够加载，也可以理解为不对Glide生命周期进行管理。

传入activity、FragmentActivity 、Fragment 及View ，这样就会创建一个看不见的fragment，Glide的生命周期就随着该Fragment的变化而变化。

由于ActivityFragmentLifecycle对象是在fragment中创建并且它的onStart、onStop、onDestory方法与fragment一一对应，这样就将RequestManager的生命周期就与fragment关联起来了，也就与当前activity关联起来。总体流程如下：

当fragment生命周期发生变化时，通过ActivityFragmentLifecycle将变化告诉给RequestManager与DefaultConnectivityMonitor。而RequestManager又将此变化告诉给ImageViewTarget。

至于传入参数为其他类型的实现基本上与activity的类似，就不在叙述。

Glide总结：

[if !supportLists]1. [endif]Glide在加载绑定了Activity的生命周期。

[if!supportLists]2. [endif]在Activity内新建一个无UI的Fragment，这个特殊的Fragment持有一个Lifecycle。通过Lifecycle在Fragment关键生命周期通知RequestManger进行相关的操作。

[if !supportLists]3. [endif]在生命周期onStart时继续加载，onStop时暂停加载，onDestory是停止加载任务和清除操作。