歡迎收看：Glide源碼分析其一：基本流程
Glide****的生命周期的實現(xiàn)主要是通過創(chuàng)建一個****Fragment進(jìn)行實現(xiàn)的
在****Glide.with(context)****這段代碼中****Glide****會創(chuàng)建一個****RequestManager****類僧鲁。該類是實現(xiàn)生命周期的關(guān)鍵方法
public class RequestManager implements LifecycleListener {
private final Context context;
private final Lifecycle lifecycle;
private final RequestManagerTreeNode treeNode;
private final RequestTracker requestTracker;
private final Glide glide;
private final OptionsApplier optionsApplier;
private DefaultOptions options;
下面是獲取RequestManager的方法：
RequestManager supportFragmentGet(Context context, FragmentManager fm) {
SupportRequestManagerFragment current = getSupportRequestManagerFragment(fm);
RequestManager requestManager = current.getRequestManager();
if (requestManager == null) {
requestManager = new RequestManager(context, current.getLifecycle(), current.getRequestManagerTreeNode());
current.setRequestManager(requestManager);
}
return requestManager;
}
其中創(chuàng)建一個了一個SupportRequestManagerFragment的對象，我們來看這個類：
public class RequestManagerFragment extends Fragment {
private final ActivityFragmentLifecycle lifecycle;
private final RequestManagerTreeNode requestManagerTreeNode = new FragmentRequestManagerTreeNode();
private RequestManager requestManager;
private final HashSet<RequestManagerFragment> childRequestManagerFragments
= new HashSet<RequestManagerFragment>();
private RequestManagerFragment rootRequestManagerFragment;
其中的ActivityFragmentLifecycle實現(xiàn)了Lifecycle寞秃，根據(jù)Lifecycle的注釋：
A {@link com.bumptech.glide.manager.Lifecycle} implementation for tracking and notifying listeners of {@link android.app.Fragment} and {@link android.app.Activity} lifecycle events.
可知斟叼，這個接口用于實現(xiàn)Activity或者Fragment的生命周期的回調(diào)
RequestManagerFragment
onAttach()
@Override
public void onAttach(Activity activity) {
super.onAttach(activity);
rootRequestManagerFragment = RequestManagerRetriever.get()
.getRequestManagerFragment(getActivity().getFragmentManager());
if (rootRequestManagerFragment != this) {
rootRequestManagerFragment.addChildRequestManagerFragment(this);
}
}
先獲取到root，如果當(dāng)前獲取的root不等于當(dāng)前的管理的Fragment春寿，則添加到當(dāng)前管理類中的一個set結(jié)合中（實際上朗涩，RequestManagerFragment既充當(dāng)了一個Fragment來組織生命周期的回調(diào)，同樣也是一個管理者的角色绑改，他管理了依附于不同fragmentActivty和Activity的fragment）谢床。
那么當(dāng)該fragment在銷毀的時候，會執(zhí)行到onDetach()放方法厘线，直接將自己銷毀：
@Override
public void onDetach() {
super.onDetach();
if (rootRequestManagerFragment != null) {
rootRequestManagerFragment.removeChildRequestManagerFragment(this);
rootRequestManagerFragment = null;
}
}
值得注意的是识腿，Glide會在actiivty進(jìn)行重新創(chuàng)建的時候，可能因為內(nèi)存不夠而無法創(chuàng)建時造壮，回調(diào)onLowMemory:
@Override
public void onLowMemory() {
super.onLowMemory();
// If an activity is re-created, onLowMemory may be called before a manager is ever set.
// See #329.
if (requestManager != null) {
requestManager.onLowMemory();
}
}
lifecycle的注入
SupportRequestManagerFragment getSupportRequestManagerFragment(final FragmentManager fm) {
SupportRequestManagerFragment current = (SupportRequestManagerFragment) fm.findFragmentByTag(
FRAGMENT_TAG);
if (current == null) {
current = pendingSupportRequestManagerFragments.get(fm);
if (current == null) {
current = new SupportRequestManagerFragment();
pendingSupportRequestManagerFragments.put(fm, current);
fm.beginTransaction().add(current, FRAGMENT_TAG).commitAllowingStateLoss();
handler.obtainMessage(ID_REMOVE_SUPPORT_FRAGMENT_MANAGER, fm).sendToTarget();
}
}
return current;
}
我們知道渡讼，在每次創(chuàng)建SupportRequestManagerFragment的時候，均需要一個fm作為參數(shù)耳璧，而該fm會根據(jù)一個TAG獲取fragment,這樣成箫，不同的activity中的Imageview在創(chuàng)Glide請求的時候，會創(chuàng)建不同的SupportRequestManagerFragment對象旨枯，并且蹬昌，我們看到SupportRequestManagerFragment的構(gòu)造方法：
public SupportRequestManagerFragment() {
this(new ActivityFragmentLifecycle());
}
// For testing only.
@SuppressLint("ValidFragment")
public SupportRequestManagerFragment(ActivityFragmentLifecycle lifecycle) {
this.lifecycle = lifecycle;
}
可以看見，每個不用的activity中創(chuàng)建的fragment會擁有自己的生命周期召廷。
接下來凳厢，我們看上面RequestManagerFragment中的其他的生命周期的回調(diào)是在何種時候進(jìn)行回調(diào)的。
1竞慢、經(jīng)過前文的分析先紫，我們知道，Glide.with(context)會創(chuàng)建一個RequestManager對象筹煮，該對象
requestManager = new RequestManager(context, current.getLifecycle(), current.getRequestManagerTreeNode());
中已經(jīng)set進(jìn)去了管理生命周期的RequestManagerfragment的lifecycle的對象遮精。
2、那么我們就繼續(xù)朝著api的調(diào)用方向：load（string）繼續(xù)向下看
public DrawableTypeRequest<String> load(String string) {
return (DrawableTypeRequest<String>) fromString().load(string);
}
首先創(chuàng)建一個DrawableTypeRequest對象，該對象本冲，會被RequestManager注入Lifecycle：
return optionsApplier.apply(
new DrawableTypeRequest<T>(modelClass, streamModelLoader, fileDescriptorModelLoader, context,
glide, requestTracker, lifecycle, optionsApplier));
這里很厲害的一個地方就是：optionsApplier.apply會把optionsApplier自己注入進(jìn)去准脂，這樣，
public <Y extends Target<TranscodeType>> Y into(Y target) {
...
Request request = buildRequest(target);
/** setTag **/
target.setRequest(request);
lifecycle.addListener(target);
requestTracker.runRequest(request);
return target;
}
中的lifecycle即為上面requestManager傳遞過去檬洞。
3狸膏、RequestTracker
該類是真正起到保證fragment的生命周期和進(jìn)行圖片資源請求的生命周期的橋梁。
從RequestManager中的其他生命周期代碼可知：
onStart()
/**
* Lifecycle callback that registers for connectivity events (if the android.permission.ACCESS_NETWORK_STATE
* permission is present) and restarts failed or paused requests.
*/
@Override
public void onStart() {
// onStart might not be called because this object may be created after the fragment/activity's onStart method.
resumeRequests();
}
其中追蹤resumeRequests()是：
/**
* Restarts any loads that have not yet completed.
*
* @see #isPaused()
* @see #pauseRequests()
*/
public void resumeRequests() {
Util.assertMainThread();
requestTracker.resumeRequests();
}
最終的執(zhí)行者是requestTracker添怔，調(diào)用該段代碼會將
isPaused = false;
這樣湾戳，在接下來的進(jìn)行請求或者重新請求時，會依據(jù)這個標(biāo)志位進(jìn)行判斷广料。
其他的生命周期也是這樣子的，就不一一說了韧衣。
****最后购桑，說明如何進(jìn)行參數(shù)****requestTracker的傳遞的
即為上面：
創(chuàng)建一個DrawableTypeRequest對象，該對象顶瞒，會被RequestManager注入Lifecycle元旬，
return optionsApplier.apply(
new DrawableTypeRequest<T>(modelClass, streamModelLoader, fileDescriptorModelLoader, context,
glide, requestTracker, lifecycle, optionsApplier));
同時，requestTracker也會被傳入進(jìn)去坑资，這樣穆端，所有的都已經(jīng)串通了，Glide的生命周期就是這樣了攒巍。
