作者：他的大姨父
連結：
https://www.jianshu.com/p/317b2d6bde1b本文是Glide源碼解析系列的第一篇，通過這篇文檔，将可以了解到：
- 1.Glide如何綁定Activity、Fragment生命周期。
- 2.Glide如何監聽記憶體變化、網絡變化。
- 3.Glide如何處理請求的生命周期。
1.0 生命周期相關UML類圖
2.0 生命周期綁定
Glide生命周期綁定是從入口單例類Glide開始的，通過with()多個重載方法來實作對生命周期的綁定工作。
public static RequestManager with(Fragment fragment)
public static RequestManager with(FragmentActivity activity)
public static RequestManager with(Activity activity)
public static RequestManager with(Context context)
以Activity的參數為例：
public static RequestManager with(Activity activity) {
RequestManagerRetriever retriever = RequestManagerRetriever.get();
return retriever.get(activity);
}
RequestManagerRetriever是一個單例類，可以了解為一個工廠類，通過get方法接收不同的參數，來建立RequestManager。
public RequestManager get(Activity activity) {
if (Util.isOnBackgroundThread() || Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
return get(activity.getApplicationContext());
} else {
assertNotDestroyed(activity);
android.app.FragmentManager fm = activity.getFragmentManager();
return fragmentGet(activity, fm);
}
}
public RequestManager get(android.app.Fragment fragment) {
if (fragment.getActivity() == null) {
throw new IllegalArgumentException("You cannot start a load on a fragment before it is attached");
}
if (Util.isOnBackgroundThread() || Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR1) {
return get(fragment.getActivity().getApplicationContext());
} else {
android.app.FragmentManager fm = fragment.getChildFragmentManager();
return fragmentGet(fragment.getActivity(), fm);
}
}
如果是在子線程進行的with操作，那麼Glide将預設使用ApplicationContext，可以了解為不對請求的生命周期進行管理，通過Activity拿到FragmentManager，并将建立RequestManager的任務傳遞下去。最終都走到了fragmentGet方法，注意細微差別是Activity傳的參數的是Activity的FragmentManager，Fragment傳的參數的是ChildFragmentManager，這兩者不是一個東西。
RequestManager fragmentGet(Context context, android.app.FragmentManager fm) {
//擷取RequestManagerFragment，并擷取綁定到這個fragment的RequestManager
RequestManagerFragment current = getRequestManagerFragment(fm);
RequestManager requestManager = current.getRequestManager();
if (requestManager == null) {
//如果擷取RequestManagerFragment還沒有綁定過RequestManager，那麼就建立RequestManager并綁定到RequestManagerFragment
requestManager = new RequestManager(context, current.getLifecycle(), current.getRequestManagerTreeNode());
current.setRequestManager(requestManager);
}
return requestManager;
}
2.0.1 建立RequestManagerFragment
這個方法建立了一個fragment，并且建立并綁定了一個RequestManager，看看getRequestManagerFragment如何擷取的RequestManagerFragment。
RequestManagerFragment getRequestManagerFragment(final android.app.FragmentManager fm) {
//嘗試根據id去找到此前建立的RequestManagerFragment
RequestManagerFragment current = (RequestManagerFragment) fm.findFragmentByTag(FRAGMENT_TAG);
if (current == null) {
//如果沒有找到，那麼從臨時存儲中尋找
current = pendingRequestManagerFragments.get(fm);
if (current == null) {
//如果仍然沒有找到，那麼建立一個RequestManagerFragment，并添加到臨時存儲中。
//然後開啟事務綁定fragment并使用handler發送消息來将臨時存儲的fragment移除。
current = new RequestManagerFragment();
pendingRequestManagerFragments.put(fm, current);
fm.beginTransaction().add(current, FRAGMENT_TAG).commitAllowingStateLoss();
handler.obtainMessage(ID_REMOVE_FRAGMENT_MANAGER, fm).sendToTarget();
}
}
return current;
}
這裡有個問題，為什麼需要使用pendingRequestManagerFragments這樣一個集合來臨時存儲一下fragment，然後又馬上通過handler發送消息移除？這其實是跟主線程的Looper機制和Fragment的事務機制有關的（點選這裡檢視Fragment事務流程分析）。我們知道，android中的主線程是一個閉環，通過Handler發送消息到MessageQueue，然後通過Looper輪詢擷取消息并交給Handler處理（點選這裡檢視Activity啟動流程分析）。如下面一個常見場景：
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，相關源碼如下（有興趣了解的點選這裡檢視Fragment事務流程分析），這個方法在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。
接着往下看RequestManagerFragment的構造方法做了什麼。
public RequestManagerFragment() {
this(new ActivityFragmentLifecycle());
}
直接建立一個ActivityFragmentLifecycle，這個類實際是一個生命周期回調的管理類，實作了Lifecycle接口。所有的LifecycleListener會添加到一個集合中，當RequestManagerFragment生命周期方法觸發時，會調用ActivityFragmentLifecycle相應生命周期方法，這個方法然後再周遊調用所有LifecycleListener的生命周期方法，以onStart生命周期方法為例，RequestManagerFragment中：
public void onStart() {
super.onStart();
lifecycle.onStart();
}
然後ActivityFragmentLifecycle中：
void onStart() {
isStarted = true;
for (LifecycleListener lifecycleListener : Util.getSnapshot(lifecycleListeners)) {
lifecycleListener.onStart();
}
}
2.0.2 rootRequestManagerFragment
上面UML圖上，可以知道RequestManagerFragment還有一個rootRequestManagerFragment的成員變量，Glide每建立一個RequestManagerFragment，都會嘗試執行個體化rootRequestManagerFragment，這個fragment即頂級的Activity所建立的RequestManagerFragment，相關代碼：
public void onAttach(Activity activity) {
super.onAttach(activity);
rootRequestManagerFragment = RequestManagerRetriever.get()
.getRequestManagerFragment(getActivity().getFragmentManager());
if (rootRequestManagerFragment != this) {
rootRequestManagerFragment.addChildRequestManagerFragment(this);
}
}
@Override
public void onDetach() {
super.onDetach();
if (rootRequestManagerFragment != null) {
rootRequestManagerFragment.removeChildRequestManagerFragment(this);
rootRequestManagerFragment = null;
}
}
可以看到，不管目前的RequestManagerFragment是通過何種方式建立的，都會在OnAttach時，拿到目前所綁定的Activity的FragmentManager來初始化一個RequestManagerFragment，這個RequestManagerFragment有可能是自身，有可能已經被初始化過了，比如是通過with(Activity activity)的方式初始化的，那麼很顯然
RequestManagerRetriever.get().getRequestManagerFragment(getActivity().getFragmentManager());
這句代碼拿到的會是自己本身，而如果是通過with(Fragment fragment)的形式建立的，rootRequestManagerFragment将指向目前fragment綁定到Activity所綁定的RequestManagerFragment，如果該Activity沒有綁定過，那麼會開啟事務綁定一個RequestManagerFragment。并且如果自己不是rootRequestManagerFragment的話，那麼将會把自己儲存到rootRequestManagerFragment中的一個集合：
private void addChildRequestManagerFragment(RequestManagerFragment child) {
childRequestManagerFragments.add(child);
}
簡而言之，Glide會為Activity建立一個RequestManagerFragment做為rootFragment，并儲存該Activity底下所有Fragment（如果有的話）所建立的RequestManagerFragment。
2.0.3 RequestManagerTreeNode
RequestManagerFragment初始化時，還會初始化RequestManagerTreeNode，顧名思義，這個類是用來儲存請求樹節點的，比如一個Activity采用Viewpager + Fragment的形式，而裡面的Fragment又是一個ViewPager + Fragment的形式，這個時候，假設其中一個RequestManagerFragment生命周期方法走了，怎麼知道哪些RequestManagerFragment綁定的LifeCycle應該得到調用呢？理想的情況是，應該讓綁定該RequestManagerFragment的Fragment所有的子Fragment的RequestManagerFragment的生命周期得到調用，比如如下場景中，Activity中各有兩個Fragment，兩個Fragment又各有兩個子Fragment，在所有Fragment中，均通過with(this)的方式來加載圖檔，經過之前的分析我們可以知道的是，ROOT RMF 中會儲存有6個RMF（RMF即RequestManagerFragment）：
當如果F1 RMF生命周期做出反應時，因為RequestManagerFragment是無界面的，是以可以了解為F1的生命周期做出反應。我們希望F11和F12所綁定的RequestManagerFragment也要立即做出反應。但是F2以及其底下的RequestManagerFragment則不應響應對應生命周期事件，我們知道任何一個RequestManagerFragment可以通過rootRequestManagerFragment拿到這6個RMF，繼而拿到其所對應的RequestManager，那麼怎麼去确定F11 RMF 和 F12 RMF呢？這就是RequestManagerTreeNode幹的事情了，RequestManagerFragment中的非靜态内部類FragmentRequestManagerTreeNode實作了RequestManagerTreeNode：
private class FragmentRequestManagerTreeNode implements RequestManagerTreeNode {
@Override
public Set<RequestManager> getDescendants() {
Set<RequestManagerFragment> descendantFragments = getDescendantRequestManagerFragments();
HashSet<RequestManager> descendants =
new HashSet<RequestManager>(descendantFragments.size());
for (RequestManagerFragment fragment : descendantFragments) {
if (fragment.getRequestManager() != null) {
descendants.add(fragment.getRequestManager());
}
}
return descendants;
}
}
這個類做的事情比較簡單，調用外部類RequestManagerFragment的方法getDescendantRequestManagerFragments拿到所有的“後裔”Fragment,然後再取出它的RequestManager，然後集合裝起來傳回，這裡的後裔在前面的例子中，指的就是F11 RMF 和 F12 RMF，看看getDescendantRequestManagerFragments是怎麼拿到的F11和F12:
@TargetApi(Build.VERSION_CODES.JELLY_BEAN_MR1)
public Set<RequestManagerFragment> getDescendantRequestManagerFragments() {
//如果自己是rootFragment，那麼直接傳回childRequestManagerFragments
if (rootRequestManagerFragment == this) {
return Collections.unmodifiableSet(childRequestManagerFragments);
} else if (rootRequestManagerFragment == null || Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR1) {
// Pre JB MR1 doesn't allow us to get the parent fragment so we can't introspect hierarchy, so just
// return an empty set.
return Collections.emptySet();
} else {
HashSet<RequestManagerFragment> descendants = new HashSet<RequestManagerFragment>();
for (RequestManagerFragment fragment
//周遊取出rootFragment中的RMF，并擷取到其parentFragment，找出後裔。
: rootRequestManagerFragment.getDescendantRequestManagerFragments()) {
if (isDescendant(fragment.getParentFragment())) {
descendants.add(fragment);
}
}
return Collections.unmodifiableSet(descendants);
}
}
看看isDescendant方法是如何判斷的：
private boolean isDescendant(Fragment fragment) {
Fragment root = this.getParentFragment();
while (fragment.getParentFragment() != null) {
if (fragment.getParentFragment() == root) {
return true;
}
fragment = fragment.getParentFragment();
}
return false;
}
依上面的例子，當周遊到F11 RMF時，參數傳遞過來的是F11，root 則為F1，F11再拿到parent，也是F1，傳回true，F12 RMF類似也傳回true；
當周遊到F21 RMF時，參數傳入F21，root仍是F1，此時F21再怎麼拿Parent也不可能是root,傳回false。
簡而言之，RequestManagerTreeNode用來擷取綁定該RequestManagerFragment的Fragment的所有子Fragment所綁定的RequestManagerFragment所綁定的RequestManager
2.0.4 RequestManager
上面一直在說RequestManagerFragment，下面回到FragmentGet方法中，再貼一次，免得上翻麻煩:
RequestManager fragmentGet(Context context, android.app.FragmentManager fm) {
//擷取RequestManagerFragment，并擷取綁定到這個fragment的RequestManager
RequestManagerFragment current = getRequestManagerFragment(fm);
RequestManager requestManager = current.getRequestManager();
if (requestManager == null) {
//如果擷取RequestManagerFragment還沒有綁定過RequestManager，那麼就建立RequestManager并綁定到RequestManagerFragment
requestManager = new RequestManager(context, current.getLifecycle(), current.getRequestManagerTreeNode());
current.setRequestManager(requestManager);
}
return requestManager;
}
根據上面的UML圖，可以知道RequestManager是一個非常核心的類，并且還實作了LifecycleListener來處理請求的生命周期。上述代碼在建立RequestManager時，傳遞了3個參數，分别是context，前面分析過的初始化RequestManagerFragment所建立的LifeCycle和RequestManagerTreeNode。直接看RequestManager的構造函數：
public RequestManager(Context context, Lifecycle lifecycle, RequestManagerTreeNode treeNode) {
this(context, lifecycle, treeNode, new RequestTracker(), new ConnectivityMonitorFactory());
}
調用的另一個構造方法，并增加了兩個新的參數RequestTracker和ConnectivityMonitorFactory。
RequestManager(Context context, final Lifecycle lifecycle, RequestManagerTreeNode treeNode,
RequestTracker requestTracker, ConnectivityMonitorFactory factory) {
this.context = context.getApplicationContext();
this.lifecycle = lifecycle;
this.treeNode = treeNode;
this.requestTracker = requestTracker;
this.glide = Glide.get(context);
this.optionsApplier = new OptionsApplier();
ConnectivityMonitor connectivityMonitor = factory.build(context,
new RequestManagerConnectivityListener(requestTracker));
// If we're the application level request manager, we may be created on a background thread. In that case we
// cannot risk synchronously pausing or resuming requests, so we hack around the issue by delaying adding
// ourselves as a lifecycle listener by posting to the main thread. This should be entirely safe.
if (Util.isOnBackgroundThread()) {
new Handler(Looper.getMainLooper()).post(new Runnable() {
@Override
public void run() {
lifecycle.addListener(RequestManager.this);
}
});
} else {
lifecycle.addListener(this);
}
lifecycle.addListener(connectivityMonitor);
}
RequestTracker即所有請求操作的真正處理者，所有Request的暫停取消執行操作都由RequestTracker來完成，如RequestManager暫停請求的實作：
public void pauseRequests() {
Util.assertMainThread();
requestTracker.pauseRequests();
}
2.0.5 網絡狀态監測
請求生命周期的實作細節後面再說，暫時埋坑，先來看看ConnectivityMonitorFactory這個工廠生産了什麼。
public class ConnectivityMonitorFactory {
public ConnectivityMonitor build(Context context, ConnectivityMonitor.ConnectivityListener listener) {
final int res = context.checkCallingOrSelfPermission("android.permission.ACCESS_NETWORK_STATE");
final boolean hasPermission = res == PackageManager.PERMISSION_GRANTED;
if (hasPermission) {
return new DefaultConnectivityMonitor(context, listener);
} else {
return new NullConnectivityMonitor();
}
}
}
很簡單，接收一個ConnectivityListener根據是否有監控網絡狀态的權限來建立相應的網絡監控器。
DefaultConnectivityMonitor也比較簡單，就是内部定義了一個廣播接收者，并且也實作了lifeCycleListener。在上面RequestManager的構造方法中，建立了一個RequestManagerConnectivityListener：
private static class RequestManagerConnectivityListener implements ConnectivityMonitor.ConnectivityListener {
private final RequestTracker requestTracker;
public RequestManagerConnectivityListener(RequestTracker requestTracker) {
this.requestTracker = requestTracker;
}
@Override
public void onConnectivityChanged(boolean isConnected) {
if (isConnected) {
requestTracker.restartRequests();
}
}
}
這個listener很簡單，收到網絡狀态連接配接就重新開機請求。然後通過工廠建立出了DefaultConnectivityMonitor，并把它添加到了lifecycle中。到這裡，Glide監測網絡狀态來重新開機請求的實作方式就呼之欲出了，大體步驟如下：
在相應的生命周期方法中，會調用lifecycle的生命周期方法，lifecycle會調用DefaultConnectivityMonitor所實作的相應生命周期方法來注冊及解除注冊網絡狀态的廣播接收者，收到廣播後，會回調之前傳遞的參數ConnectivityListener的onConnectivityChanged方法來處理Request。
2.0.6 記憶體狀态監測
RequestManager中還存有Glide這個入口類的執行個體，構造方法中直接擷取到的，用來對記憶體狀态的變更作出處理，比較簡單，看看流程便可以了，以onTrimMemory為例,
當RequestManagerFragment的onTrimMemory被調用時，會調用其綁定的RequetManager的相應方法來處理:
@Override
public void onTrimMemory(int level) {
// If an activity is re-created, onTrimMemory may be called before a manager is ever set.
// See #329.
if (requestManager != null) {
requestManager.onTrimMemory(level);
}
}
然後RequestManager再調用Glide入口類的trimMemory來釋放更多記憶體：
public void onTrimMemory(int level) {
glide.trimMemory(level);
}
2.0.7 生命周期回調流程總結
在RequestManager構造方法中，還會将自身添加到LifeCycle中，這樣，整個流程就暢通了：
細心的可以發現，雖然在構造RequestManager時傳遞了參數RequestManagerTreeNode，但是在這個回調流程中，并沒有對所有後裔RMF的RequestManager進行調用，Glide預設确實是不會去調用，但這裡并不意味着這些RequestManager不會被調用到，事實上，目前RMF生命周期被調用時，就意味後裔Fragment生命周期也會被調用，那麼後裔Fragment這個流程仍然會走一遍，那麼RequestManagerTreeNode到底有什麼用呢?答案是沒用，完全沒用，如果隻是簡單使用Glide的話。當然，RequestManager暴露了相關接口給開發者使用：
public void resumeRequestsRecursive() {
Util.assertMainThread();
resumeRequests();
for (RequestManager requestManager : treeNode.getDescendants()) {
requestManager.resumeRequests();
}
}
調用這個方法将會把所有後裔的請求同時一起處理。
**推薦閱讀：[2017-2020曆年位元組跳動Android面試真題解析（累計下載下傳1082萬次，持續更新中）
](
https://www.jianshu.com/p/7f9ade51232e)**
2020最新Android大廠高頻面試題解析大全(BAT TMD JD 小米)![轉 UML應用的三重境界[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)