前言
最近使用到 Glide 加載本地大圖，寫代碼時想看看 Glide 有沒有壓縮圖片避免出現 OOM 問題，隨手點進源碼一看，發現事情并不是那么簡單。
Glide 源碼錯綜復雜，閱讀起來十分困難，為了知道代碼內部是如何處理本地大圖也是下費了一番功夫。
想想也知道，Glide 這一優秀的圖片加載框架肯定對圖片進行了壓縮處理，但是眼見為實，這次分析的最終目的就是通過Glide.with(this).load(resourceId).into(imageView)這行代碼，來搞清楚 Glide 到底在哪里對圖片進行了壓縮。
為了方便閱讀，文章中使用了錨點關鍵字，可以使用瀏覽器搜索功能進行快速跳轉。
Glide 版本：3.7.0
with
with() 方法共有5種重載：
public static RequestManager with(Context context) {
RequestManagerRetriever retriever = RequestManagerRetriever.get();
return retriever.get(context);
}
public static RequestManager with(Activity activity) {
RequestManagerRetriever retriever = RequestManagerRetriever.get();
return retriever.get(activity);
}
public static RequestManager with(FragmentActivity activity) {
RequestManagerRetriever retriever = RequestManagerRetriever.get();
return retriever.get(activity);
}
@TargetApi(Build.VERSION_CODES.HONEYCOMB)
public static RequestManager with(android.app.Fragment fragment) {
RequestManagerRetriever retriever = RequestManagerRetriever.get();
return retriever.get(fragment);
}
public static RequestManager with(Fragment fragment) {
RequestManagerRetriever retriever = RequestManagerRetriever.get();
return retriever.get(fragment);
}
5種重載都是為了得到 RequestManager 對象，以及做好生命周期的管理，因為 Glide 需要根據自己所在環境的生命周期來判斷是否繼續加載圖片，比如說當 Activity 銷毀后，Glide 應當停止加載。
RequestManagerRetriever 通過靜態內部類的方式實現單例模式。
5種重載方法的第一行都通過調用**靜態方法 get() **來獲得 RequestManagerRetriever 對象。
然后再調用 RequestManagerRetriever 對象的 get() 方法獲取 RequestManager 對象。
RequestManagerRetriever 對象的 get() 方法，這里為了更清晰將 get() 重載方法分為了兩類：
1. 傳入參數為 Context
public RequestManager get(Context context) {
if (context == null) {
throw new IllegalArgumentException("You cannot start a load on a null Context");
} else if (Util.isOnMainThread() && !(context instanceof Application)) {
if (context instanceof FragmentActivity) {
return get((FragmentActivity) context);
} else if (context instanceof Activity) {
return get((Activity) context);
} else if (context instanceof ContextWrapper) {
return get(((ContextWrapper) context).getBaseContext());
}
}
return getApplicationManager(context);
}
可以看到邏輯分為兩種情況：
- 傳入參數屬于 Application 或非主線程調用
- 傳入參數不屬于 Application（錨點1）
當參數屬于 Application 時，因為 Application 的生命周期就是應用程序的生命周期，如果應用程序都銷毀了，Glide 肯定不會繼續加載，所以不需要做生命周期的特殊處理，所以在 getApplicationManager() 方法中使用了 ApplicationLifecycle（錨點2）用于生命周期的管理。
當參數不屬于 Application 時，會調用傳入參數為 Context 子類的重載方法。
2. 傳入參數為 Context 子類
@TargetApi(Build.VERSION_CODES.HONEYCOMB)
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(FragmentActivity activity) {
if (Util.isOnBackgroundThread()) {
return get(activity.getApplicationContext());
} else {
assertNotDestroyed(activity);
FragmentManager fm = activity.getSupportFragmentManager();
return supportFragmentGet(activity, fm);
}
}
@TargetApi(Build.VERSION_CODES.JELLY_BEAN_MR1)
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);
}
}
public RequestManager get(Fragment fragment) {
if (fragment.getActivity() == null) {
throw new IllegalArgumentException("You cannot start a load on a fragment before it is attached");
}
if (Util.isOnBackgroundThread()) {
return get(fragment.getActivity().getApplicationContext());
} else {
FragmentManager fm = fragment.getChildFragmentManager();
return supportFragmentGet(fragment.getActivity(), fm);
}
}
這4個重載函數都是拿到 Activity 向其添加一個隱藏的 Fragment，具體添加過程如下：
@TargetApi(Build.VERSION_CODES.HONEYCOMB)
RequestManager fragmentGet(Context context, android.app.FragmentManager fm) {
RequestManagerFragment current = getRequestManagerFragment(fm);
RequestManager requestManager = current.getRequestManager();
if (requestManager == null) {
requestManager = new RequestManager(context, current.getLifecycle(), current.getRequestManagerTreeNode());（錨點3）
current.setRequestManager(requestManager);
}
return requestManager;
}
@TargetApi(Build.VERSION_CODES.JELLY_BEAN_MR1)
RequestManagerFragment getRequestManagerFragment(final android.app.FragmentManager fm) {
RequestManagerFragment current = (RequestManagerFragment) fm.findFragmentByTag(FRAGMENT_TAG);
if (current == null) {
current = pendingRequestManagerFragments.get(fm);
if (current == null) {
current = new RequestManagerFragment();（錨點4）
pendingRequestManagerFragments.put(fm, current);
fm.beginTransaction().add(current, FRAGMENT_TAG).commitAllowingStateLoss();
handler.obtainMessage(ID_REMOVE_FRAGMENT_MANAGER, fm).sendToTarget();
}
}
return current;
}
supportFragmentGet() 同理。
添加過后創建 RequestManager（見：錨點3）。
Glide.with() 方法返回的 RequestManager 就是從這里來的。
至此 with() 方法主線的分析就結束了，下邊會分析之前提到的生命周期。
生命周期
Glide 通過向 Activity 添加隱藏的 Fragment 進行生命周期管理，具體是在哪里實現的？
在錨點4處，使用無參構造創建 RequestManagerFragment 對象時方法內部創建了一個 ActivityFragmentLifecycle 對象：
public RequestManagerFragment() {
this(new ActivityFragmentLifecycle());
}
RequestManagerFragment(ActivityFragmentLifecycle lifecycle) {
this.lifecycle = lifecycle;
}
然后在 RequestManagerFragment 的生命周期回調方法中，調用 ActivityFragmentLifecycle 相應的函數，實現綁定：
@Override
public void onStart() {
super.onStart();
lifecycle.onStart();
}
@Override
public void onStop() {
super.onStop();
lifecycle.onStop();
}
@Override
public void onDestroy() {
super.onDestroy();
lifecycle.onDestroy();
}
ActivityFragmentLifecycle 實現了 Lifecycle 接口的 addListener() 方法，添加 LifecycleListener 時就會根據當前的生命周期調用其相應的方法：
@Override
public void addListener(LifecycleListener listener) {
lifecycleListeners.add(listener);
if (isDestroyed) {
listener.onDestroy();
} else if (isStarted) {
listener.onStart();
} else {
listener.onStop();
}
}
當 ActivityFragmentLifecycle 生命周期方法被調用時，會改變當前的狀態，并通知已注冊的 LifecycleListener：
void onStart() {
isStarted = true;
for (LifecycleListener lifecycleListener : Util.getSnapshot(lifecycleListeners)) {
lifecycleListener.onStart();
}
}
void onStop() {
isStarted = false;
for (LifecycleListener lifecycleListener : Util.getSnapshot(lifecycleListeners)) {
lifecycleListener.onStop();
}
}
void onDestroy() {
isDestroyed = true;
for (LifecycleListener lifecycleListener : Util.getSnapshot(lifecycleListeners)) {
lifecycleListener.onDestroy();
}
}
而 LifecycleListener 的實現類，就有 RequestManager：
public class RequestManager implements LifecycleListener {
public RequestManager(Context context, Lifecycle lifecycle, RequestManagerTreeNode treeNode) {
this(context, lifecycle, treeNode, new RequestTracker(), new ConnectivityMonitorFactory());
}
RequestManager(Context context, final Lifecycle lifecycle, RequestManagerTreeNode treeNode,
RequestTracker requestTracker, ConnectivityMonitorFactory factory) {
···
if (Util.isOnBackgroundThread()) {
new Handler(Looper.getMainLooper()).post(new Runnable() {
@Override
public void run() {
lifecycle.addListener(RequestManager.this);
}
});
} else {
lifecycle.addListener(this);
}
···
}
@Override
public void onStart() {
resumeRequests();（錨點5）
}
@Override
public void onStop() {
pauseRequests();（錨點6）
}
@Override
public void onDestroy() {
requestTracker.clearRequests();（錨點7）
}
}
所以我們拿著 Glide.with() 方法返回的 RequestManager 進行后續操作時，它就已經具有生命周期的功能了。
需要注意以上的前提是我們在調用 RequestManagerRetriever 對象的 get() 方法時傳入參數不屬于 Application（見：錨點1）。
當傳入參數屬于 Application 時，使用了 ApplicationLifecycle 進行管理（見：錨點2）。
而 ApplicationLifecycle 內部只有 start 一種狀態：
class ApplicationLifecycle implements Lifecycle {
@Override
public void addListener(LifecycleListener listener) {
listener.onStart();
}
}
所以當傳入參數屬于 Application 時，可以認為 Glide 沒有進行生命周期的管理。
至此，通過 with() 方法傳入的參數，獲得 Activity 并添加 Fragment，在 Fragment 的生命周期中層層回調到 RequestManager 進而控制圖片的加載（見：錨點5）、暫停（見：錨點6）和清除加載請求（見：錨點7）的這一流程就分析完畢了。
在下一篇中，我們會繼續分析 load() 方法：Glide 源碼分析之二 load.
謝謝大家。
