前言
最近使用到 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.
谢谢大家。
参考链接
Android图片加载框架最全解析（二），从源码的角度理解Glide的执行流程