在《Glide 4.x工作總體執行流程概述》一篇博文中我們直到Glide載入圖片的步驟主要由兩個：
1、通過RequestBuilder物件建立Request物件
2、將Request物件交給RequestManager來管理，併發起請求
上面兩個步驟的主要在into方法中得到體現：

private <Y extends Target<TranscodeType>> Y into(
    @NonNull Y target,
    @Nullable RequestListener<TranscodeType> targetListener,
    RequestOptions options) {

  //、建立request物件
 

  Request request = buildRequest(target, targetListener, options);

  //獲取target物件的Request物件
  Request previous = target.getRequest();
  //如果同一個target的請求一樣
  if (request.isEquivalentTo(previous)) {

    if (!Preconditions.checkNotNull(previous).isRunning()) {
      //如果同一個target的同一個request沒有執行，就執行而不是建立新的
 

      previous.begin();
    }
    return target;
  }

  //清除target之前的的的request
  requestManager.clear(target);
  //為target設定新的request
  target.setRequest(request);
  //設定新的reqesut
  requestManager.track(target, request);

  return target;
}

into方法的主要核心是：
1、先建立一個request物件
2、判斷同一個target（ImageView）上次發起的網路請求和步驟1建立的請求是否是同一個，如果是的話就繼續使用前一次發起的請求
3、如果步驟1建立的請求和上次發起的請求不一樣，比如URL改變了，那麼就讓target清除舊的請求（哪怕是舊的請求isRunning狀態也需要中斷了），並記錄最新的請求，並且將最新的請求交給requestManager來管理（track方法）：

 TargetTracker targetTracker = new TargetTracker();

 RequestTracker requestTracker;

void track(Target<?> target, Request request) {
  //將target加入TargetTracker的一個set集合
  targetTracker.track(target);

  //將request交給RequestTracker，並執行
  requestTracker.runRequest(request);
}

track方法的核心就是將target和Request物件分別交給TargetTracker和RequestTracker處理，其中targetTracker的track方法是將Target物件新增到一個set集合裡面；而requestTracker的runReqeust方法做了如下操作：
1、先將request物件新增到一個裡面
2、如果已經處於暫停狀態，則將request集合新增到 pendingRequests這個集合中，否則則執行request的begin方法，runReqeust的程式碼實現如下：

Set<Request> requests =Collections.newSetFromMap(new WeakHashMap<Request, Boolean>());

List<Request> pendingRequests = new ArrayList<>();

public void runRequest(Request request) {
  //將request加入集合
  requests.add(request);
  //如果沒有暫停，那麼
  if (!isPaused) {
    request.begin();
  } else {
    //放入pending集合中等待下次開始執行
    pendingRequests.add(request);
  }
}

先來看看RequestTracker方法都提供了哪些public方法：

從上圖來看ReqeustTrack方法提供了restartRequest、resumeRequest等控制Request物件生命週期的方法，從程式碼實現來看RequestTracker倒是真正的請求管理者（RequestManager），簡單看看restartRequest都是做了什麼：

  public void restartRequests() {
    //遍歷方法
    for (Request request : Util.getSnapshot(requests)) {
      if (!request.isComplete() && !request.isCancelled()) {
        //先暫停後啟動
        request.pause();
        if (!isPaused) {
          //啟動
          request.begin();
        } else {
          pendingRequests.add(request);
        }
      }
    }
  }

上面的isPause用來判斷請求是否暫停，且RequestTracker提供了pauseReqeusts 方法，另外該物件交給RequestManager 來管理，換句話說ReqeustManager來代理管理Request的生命週期方法，Request介面提供瞭如下幾個方法：

所以看看ReqeustManager都提供了哪些方法來管理Request的生命週期：

而ReqeustTracker的restartRequests方法則是在RequestManager的巢狀類RequestManagerConnectivityListener的onConnectivityChanged方法呼叫：

  @Override
    public void onConnectivityChanged(boolean isConnected) {
      if (isConnected) {
        requestTracker.restartRequests();
      }
    }

那麼RequestManager裡面這些管理請求的方法都是什麼時候呼叫的呢？要知道我們在使用Glide的時候在客戶端並沒有手動呼叫這些方法，在回答這個問題之前讓我們看看Glide的重要介面LifecycleListener：

而且我們的RequestManager類就是LifecycleListener的實現類，所以進入RequestManager類裡面看LifecycleListener介面的方法具體實現：

一目瞭然，在LifecycleListener的介面方法裡面分別對應的呼叫了pauseRequests()方法，resumeRequets()方法等。在此需要注意一個問題，比如在onStart()方法裡面也呼叫了targetTracker的onStart方法，那麼這個方法又是來幹什麼呢？（此處先不討論了，先埋個坑）
看Glide對LifecycleListener的解釋我們就知道了該介面的作用：將Acitivity ／Fragment的生命週期和Request的生命週期進行繫結：

An interface for listener to Fragment and Activity lifecycle events.

從上面的講解我們看出Glide與Acitity生命週期的繫結實際上繫結的是Request物件的生命週期。

問題1：那麼glide是怎麼使得Activity的生命週期和Request的生命週期進行繫結的呢？

下面就來分析分析這個問題我們現在已經知道RequestManager就是LifecycleListener介面的一個實現類。

**問題2：**Glide是怎麼管理或者說控制LifecycleListener方法的呢？

其實Glide裡面提供了另外一個介面Lifecycle來新增和刪除LifecycleListener：

而且在RequestManager的內部也有該介面的一個引用：

final Lifecycle lifecycle;

 private final Runnable addSelfToLifecycle = new Runnable() {
    @Override
    public void run() {
      //將RequestManager自身新增到lifecycle方法中
      lifecycle.addListener(RequestManager.this);
    }
  };

RequestManager的lifecycle引用是通過構造器來初始化的：

RequestManager(
      Glide glide,
      Lifecycle lifecycle,
      RequestManagerTreeNode treeNode,
      RequestTracker requestTracker,
      ConnectivityMonitorFactory factory,
      Context context) {

    /*初始化lifecycle*/
    this.lifecycle = lifecycle;

   /*省略來部分程式碼*/

    connectivityMonitor =
        factory.build(
            context.getApplicationContext(),
            new RequestManagerConnectivityListener(requestTracker));

    /*通過handler來保證是在UI執行緒新增*/
    if (Util.isOnBackgroundThread()) {
      mainHandler.post(addSelfToLifecycle);
    } else {
      lifecycle.addListener(this);
    }
    lifecycle.addListener(connectivityMonitor);

    /*新增RequestManger物件新增到glide的list集合裡面*/
    glide.registerRequestManager(this);
  }

上面的構造器說明了是什麼時候將LifecycleListener新增到lifecycle裡面的。

問題3：：RequestManager是什麼時候初始化的，其實這個問題應該這麼問lifecycle介面是如何初始化的。
如果問題3解答出來那麼本篇博文的主題：glide生命週期與Acticity 的繫結原理就一目瞭然了。下面就來回答這個問題：

在Glide中提供了若干個方法可以得到RequestManager物件：

在此挑with(Activity)來分析，其程式碼如下：

 public static RequestManager with(Activity activity) {
    return getRetriever(activity).get(activity);
  }

而要獲取RequestManager則需要RequestManagerRetriever的get方法，在此我們只需要知道該類有一個factory來建立RuquestManager物件即可，至於建立的流程可閱讀關於該方法的簡單說明可以在《Glide 4.x工作總體執行流程概述》 瞭解，且RequestManagerRetriever也提供了獲取RequestManager物件的過載方法：

接著繼續分析RequestManagerRetriever的get(Activity) 方法：

public RequestManager get(Activity activity) {
    //非UI執行緒
    if (Util.isOnBackgroundThread()) {
      return get(activity.getApplicationContext());
    } else {//UI執行緒
      android.app.FragmentManager fm = activity.getFragmentManager();
      return fragmentGet(activity, fm, null /*parentHint*/);
    }
  }

上面的方法在UI執行緒的呼叫了fragmentGet來返回了一個RequestManager物件，其程式碼如下：

從上圖可以看出來初始化RequestManager需要兩個重要的步驟：

1、呼叫getRequestManagerFragment
方法初始化RequestManagerFrament物件，該物件是Fragment物件。

2、呼叫RequestManagerFrament的getGlideLifecycle方法獲取Lifecyle物件交給RequestManager處理

到此為止，上面問題3的已經算是解答完畢！
觀察原始碼發現RequestManagerFragment就是一個Fragment,且其內部含有一個Lifecycle的引用:

public class RequestManagerFragment extends Fragment {
  //ActivityFragmentLifecycle實現了Lifecycle介面
  private final ActivityFragmentLifecycle lifecycle;
｝

通過上文我們知道RequestManager拿到Lifecycle方法後呼叫lifeCycle.addListener(this)將自己交給了Lifecycle。我們來看看ActivityFragmentLifecycle的addListener方法：

如上圖所示我們最終將RequestManager物件新增到了ActivityFragmentLifecycle一個set集合裡面。因為ActivityFragmentLifecycle本身也是一個Lifecycle,其也實現了Lifecycle的生命週期方法，如果所示：

在onStart等方法中只是遍歷了set集合，然後拿出具體的LifecycleListener物件執行對應的方法而已。

通過上文的說明我們知道ActivityFragmentLifecycle物件引用交給了RequestManagerFragment這個Fragment物件來持有，所以我們在此有理由推斷出Glide在Fragment的生命週期函式裡面呼叫了ActivityFragmentLifecycle這個Lifecycle的相關方法，不信看程式碼：

到此為止，Glide的生命週期繫結activity 的生命週期實現原理以及講解完畢，總的來說就是：
1、通過Fragment的生命週期函式onStart()/onStop()/onDestory()來執行Glide的Lifecycle的onStart()/onStop()/onDestory()方法

2、而上面Frament的lifecycle具體實現類就是ActivityFragmentLifecycle，其內部持有一個集合來新增LifecycleListener介面的具體實現，比如RequestManager.在glide中LifecycleListener的具體實現有如下幾個類：

3、而RequestManager又是通過RequestTrack的相關方法來管理Request物件的pasue,resume,restart等

最終層層深入完成了與Acitivity生命週期的繫結。