1.Glide加載圖片的步驟主要由兩個：
1、通過RequestBuilder對象創(chuàng)建Request對象
2、將Request對象交給RequestManager來管理，并發(fā)起請求
上面兩個步驟的主要在into方法中得到體現(xiàn)：
private <Y extends Target<TranscodeType>> Y into(
@NonNull Y target,
@Nullable RequestListener<TranscodeType> targetListener,
RequestOptions options) {
//、創(chuàng)建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沒有執(zhí)行，就執(zhí)行而不是創(chuàng)建新的
previous.begin();
}
return target;
}
//清除target之前的的的request
requestManager.clear(target);
//為target設置新的request
target.setRequest(request);
//設置新的reqesut
requestManager.track(target, request);
return target;
}
- into方法的主要核心是：
1、先創(chuàng)建一個request對象
2、判斷同一個target（ImageView）上次發(fā)起的網(wǎng)絡請求和步驟1創(chuàng)建的請求是否是同一個，如果是的話就繼續(xù)使用前一次發(fā)起的請求
3、如果步驟1創(chuàng)建的請求和上次發(fā)起的請求不一樣，比如URL改變了，那么就讓target清除舊的請求（哪怕是舊的請求isRunning狀態(tài)也需要中斷了），并記錄最新的請求，并且將最新的請求交給requestManager來管理（track方法）：
TargetTracker targetTracker = new TargetTracker();
RequestTracker requestTracker;
void track(Target<?> target, Request request) {
//將target加入TargetTracker的一個set集合
targetTracker.track(target);
//將request交給RequestTracker，并執(zhí)行
requestTracker.runRequest(request);
}
- track方法的核心就是將target和Request對象分別交給TargetTracker和RequestTracker處理，其中targetTracker的track方法是將Target對象添加到一個set集合里面；而requestTracker的runReqeust方法做了如下操作：
1、先將request對象添加到一個里面
2、如果已經(jīng)處于暫停狀態(tài)，則將request集合添加到 pendingRequests這個集合中，否則則執(zhí)行request的begin方法，runReqeust的代碼實現(xiàn)如下：
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集合中等待下次開始執(zhí)行
pendingRequests.add(request);
}
}
先來看看RequestTracker方法都提供了哪些public方法：
從上圖來看ReqeustTrack方法提供了restartRequest、resumeRequest等控制Request對象生命周期的方法，從代碼實現(xiàn)來看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方法調(diào)用：
@Override
public void onConnectivityChanged(boolean isConnected) {
if (isConnected) {
requestTracker.restartRequests();
}
}
那么RequestManager里面這些管理請求的方法都是什么時候調(diào)用的呢？要知道我們在使用Glide的時候在客戶端并沒有手動調(diào)用這些方法，在回答這個問題之前讓我們看看Glide的重要接口LifecycleListener：
而且我們的RequestManager類就是LifecycleListener的實現(xiàn)類，所以進入RequestManager類里面看LifecycleListener接口的方法具體實現(xiàn)
一目了然，在LifecycleListener的接口方法里面分別對應的調(diào)用了pauseRequests()方法，resumeRequets()方法等。在此需要注意一個問題，比如在onStart()方法里面也調(diào)用了targetTracker的onStart方法，那么這個方法又是來干什么呢？（此處先不討論了，先埋個坑）
看Glide對LifecycleListener的解釋我們就知道了該接口的作用：將Acitivity ／Fragment的生命周期和Request的生命周期進行綁定：
An interface for listener to Fragment and Activity lifecycle events.
從上面的講解我們看出Glide與Acitity生命周期的綁定實際上綁定的是Request對象的生命周期。
問題1：那么glide是怎么使得Activity的生命周期和Request的生命周期進行綁定的呢？
下面就來分析分析這個問題我們現(xiàn)在已經(jīng)知道RequestManager就是LifecycleListener接口的一個實現(xiàn)類。
問題2：Glide是怎么管理或者說控制LifecycleListener方法的呢？
其實Glide里面提供了另外一個接口Lifecycle來添加和刪除LifecycleListener：
且在RequestManager的內(nèi)部也有該接口的一個引用：
final Lifecycle lifecycle;
private final Runnable addSelfToLifecycle = new Runnable() {
@Override
public void run() {
//將RequestManager自身添加到lifecycle方法中
lifecycle.addListener(RequestManager.this);
}
};
RequestManager的lifecycle引用是通過構(gòu)造器來初始化的：
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);
}
上面的構(gòu)造器說明了是什么時候?qū)ifecycleListener添加到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來創(chuàng)建RuquestManager對象即可，且RequestManagerRetriever也提供了獲取RequestManager對象的重載方法
接著繼續(xù)分析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線程的調(diào)用了fragmentGet來返回了一個RequestManager對象，其代碼如下：
從上圖可以看出來初始化RequestManager需要兩個重要的步驟：
1、調(diào)用getRequestManagerFragment
方法初始化RequestManagerFrament對象，該對象是Fragment對象。2、調(diào)用RequestManagerFrament的getGlideLifecycle方法獲取Lifecyle對象交給RequestManager處理
到此為止，上面問題3的已經(jīng)算是解答完畢！
觀察源碼發(fā)現(xiàn)RequestManagerFragment就是一個Fragment,且其內(nèi)部含有一個Lifecycle的引用:
public class RequestManagerFragment extends Fragment {
//ActivityFragmentLifecycle實現(xiàn)了Lifecycle接口
private final ActivityFragmentLifecycle lifecycle;
｝
通過上文我們知道RequestManager拿到Lifecycle方法后調(diào)用lifeCycle.addListener(this)將自己交給了Lifecycle。我們來看看ActivityFragmentLifecycle的addListener方法：
如上圖所示我們最終將RequestManager對象添加到了ActivityFragmentLifecycle一個set集合里面。因為ActivityFragmentLifecycle本身也是一個Lifecycle,其也實現(xiàn)了Lifecycle的生命周期方法，如果所示：
在onStart等方法中只是遍歷了set集合，然后拿出具體的LifecycleListener對象執(zhí)行對應的方法而已。
通過上文的說明我們知道ActivityFragmentLifecycle對象引用交給了RequestManagerFragment這個Fragment對象來持有，所以我們在此有理由推斷出Glide在Fragment的生命周期函數(shù)里面調(diào)用了ActivityFragmentLifecycle這個Lifecycle的相關方法，不信看代碼：
到此為止，Glide的生命周期綁定activity 的生命周期實現(xiàn)原理以及講解完畢，總的來說就是：
1、通過Fragment的生命周期函數(shù)onStart()/onStop()/onDestory()來執(zhí)行Glide的Lifecycle的onStart()/onStop()/onDestory()方法
2、而上面Frament的lifecycle具體實現(xiàn)類就是ActivityFragmentLifecycle，其內(nèi)部持有一個集合來添加LifecycleListener接口的具體實現(xiàn)，比如RequestManager.在glide中LifecycleListener的具體實現(xiàn)有如下幾個類：
- 3、而RequestManager又是通過RequestTrack的相關方法來管理Request對象的pasue,resume,restart等
最終層層深入完成了與Acitivity生命周期的綁定。
