在Glide解析一：Glide整体流程中，我们知道RequestManager是主要用来管理、启动图片加载请求的。而它是通过RequestManagerRetriever创建、获取的。
1、为什么用RequestManagerRetriever来获取RequestManager？
RequestManagerRetriever.java
为什么用RequestManagerRetriever来获取RequestManager？而不直接使用RequestManager的单例？我们通过常用的使用方式来分析其原因：
public RequestManager get(@NonNull View view) {
if (Util.isOnBackgroundThread()) {
//如果是在非UI线程，则使用绑定Application生命周期的RequestManager
return get(view.getContext().getApplicationContext());
}
Preconditions.checkNotNull(view);
Preconditions.checkNotNull(view.getContext(),
"Unable to obtain a request manager for a view without a Context");
//根据view拿到activity
Activity activity = findActivity(view.getContext());
// The view might be somewhere else, like a service.
if (activity == null) {
return get(view.getContext().getApplicationContext());
}
// Support Fragments.
// Although the user might have non-support Fragments attached to FragmentActivity, searching
// for non-support Fragments is so expensive pre O and that should be rare enough that we
// prefer to just fall back to the Activity directly.
//如果使用的是support中的activity
if (activity instanceof FragmentActivity) {
//如果是FragmentActivity
//如果view是support fragment中的，则根据view获取其所在的support fragment，接着调用get(fragment)
//如果view是FragmentActivity中，则调用get(FragmentActivity)方法
Fragment fragment = findSupportFragment(view, (FragmentActivity) activity);
return fragment != null ? get(fragment) : get(activity);
}
//如果没有support中的组件，其原理与support中的activity一样，不展开讲解
// Standard Fragments.
android.app.Fragment fragment = findFragment(view, activity);
if (fragment == null) {
return get(activity);
}
return get(fragment);
}
private Fragment findSupportFragment(@NonNull View target, @NonNull FragmentActivity activity) {
//清空view和fragment关联列表
tempViewToSupportFragment.clear();
//从activity的所有fragment中找出fragment的根view，并将根view与fragment进行关联存放view和fragment关联列表tempViewToSupportFragment中
findAllSupportFragmentsWithViews(
activity.getSupportFragmentManager().getFragments(), tempViewToSupportFragment);
Fragment result = null;
View activityRoot = activity.findViewById(android.R.id.content);
View current = target;
while (!current.equals(activityRoot)) {
//从view和fragment关联列表中获取view所关联的fragment
result = tempViewToSupportFragment.get(current);
if (result != null) {
break;
}
if (current.getParent() instanceof View) {
//获取当前view的父级view
current = (View) current.getParent();
} else {
break;
}
}
tempViewToSupportFragment.clear();
return result;
}
private static void findAllSupportFragmentsWithViews(
@Nullable Collection<Fragment> topLevelFragments,
@NonNull Map<View, Fragment> result) {
if (topLevelFragments == null) {
return;
}
for (Fragment fragment : topLevelFragments) {
//遍历fragment
// getFragment()s in the support FragmentManager may contain null values, see #1991.
if (fragment == null || fragment.getView() == null) {
continue;
}
//将fragment的根view与fragment进行关联
result.put(fragment.getView(), fragment);
findAllSupportFragmentsWithViews(fragment.getChildFragmentManager().getFragments(), result);
}
}
一般我们都是使用support 中的fragmetactivity，所以get(view)要么转到get(Fragment)中要么转到get(FragmentActivity)中。这里先根据view找到其所在fragment的思路是拿当前view的根view与activity的所有fragment的根view进行比较，如果相等，则这个fragment就是我们要找的fragment。
1.1、get(Fragment) 的实现逻辑
public RequestManager get(@NonNull Fragment fragment) {
//...
//获取fragment的子FragmentManager
FragmentManager fm = fragment.getChildFragmentManager();
//调用supportFragmentGet
return supportFragmentGet(fragment.getActivity(), fm, fragment, fragment.isVisible());
}
}
private RequestManager supportFragmentGet(
@NonNull Context context,
@NonNull FragmentManager fm,
@Nullable Fragment parentHint,
boolean isParentVisible) {
//根据FragmentManager获取已经存在的SupportRequestManagerFragment 或者创建一个新的SupportRequestManagerFragment
SupportRequestManagerFragment current =
getSupportRequestManagerFragment(fm, parentHint, isParentVisible);
//获取与fragment关联的RequestManager
RequestManager requestManager = current.getRequestManager();
if (requestManager == null) {
// TODO(b/27524013): Factor out this Glide.get() call.
//RequestManager为空
Glide glide = Glide.get(context);
//构建一个新的RequestManager
requestManager =
factory.build(
glide, current.getGlideLifecycle(), current.getRequestManagerTreeNode(), context);
//将fragment与RequestManager进行关联
current.setRequestManager(requestManager);
}
return requestManager;
}
get(Fragment)获取SupportRequestManagerFragment 的逻辑我们看下其代码实现：
private SupportRequestManagerFragment getSupportRequestManagerFragment(
@NonNull final FragmentManager fm, @Nullable Fragment parentHint, boolean isParentVisible) {
//根据tag名称从FragmentManager中查找SupportRequestManagerFragment
SupportRequestManagerFragment current =
(SupportRequestManagerFragment) fm.findFragmentByTag(FRAGMENT_TAG);
if (current == null) {
//如果FragmentManager没有SupportRequestManagerFragment
//从等待FragmentManager添加Fragment完成列表中获取SupportRequestManagerFragment
current = pendingSupportRequestManagerFragments.get(fm);
if (current == null) {
////如果没有SupportRequestManagerFragment
//创建新的SupportRequestManagerFragment
current = new SupportRequestManagerFragment();
//将新创建的fragment加到其父级fragment列表中
current.setParentFragmentHint(parentHint);
if (isParentVisible) {
//如果父级可见，回调生命周期的onStart
current.getGlideLifecycle().onStart();
}
//将创建的fragment加入等待FragmentManager添加fragment的队列中
pendingSupportRequestManagerFragments.put(fm, current);
//将创建的fragment加入FragmentManager中
fm.beginTransaction().add(current, FRAGMENT_TAG).commitAllowingStateLoss();
//发送消息，从等待FragmentManager添加fragment的队列中删除fragment
handler.obtainMessage(ID_REMOVE_SUPPORT_FRAGMENT_MANAGER, fm).sendToTarget();
}
}
return current;
}
根据上面的代码分析可以归纳RequestManagerRetriever创建或者获取RequestManager的流程：
- 如果在子线程，则创建一个生命周期与Application一样的RequestManager
- 根据view先拿到其所属的fragment或者activity
- 从当前framgnet或者activity中获取RequestManagerFragment，如果不为空则返回与之关联的RequestManager；如果为空那么创建一个新的RequestManagerFragment，创建的情况下顺便创建RequestManager,并进行关联，并返回该RequestManager
根据这段代码有2个问题，
问题1：为什么使用pendingSupportRequestManagerFragments来添加RequestManagerManager？fm添加RequestManagerFragment之后又发送消息删除该RequestManagerFragment呢？
答案：因为fm添加fragment不是调用add方法就代表添加完成的，它有相关的生命周期是异步进行的，所以如果add之后立马又在相同fragment或者activity环境中调用get方法，那么就很有可能又创建一个新的RequestManagerFragment，而pendingSupportRequestManagerFragments就是为了杜绝重复创建RequestManagerFragment而准备的。
问题2：对于glide的get使用有什么优化的地方吗？
答案： - 尽量不要在子线程中调用，因为子线程调用意味着生命周期是全局的，不能跟activity或fragment的生命周期同步
- get的时候最好传activity、或者fragment，因为这样可以减少查找具体的fragment或者activity的步骤
问题3：为什么要用RequestManagerFragment并与RequestManager进行关联呢？
答案：是为了进行自动感应组件的生命周期
2、为什么要用RequestManagerFragment并与RequestManager进行关联？
步骤1中分析了get的流程中，fragment和activity最终是通过创建RequestManagerFragment并和RequestManager进行关联
我们看下RequestManagerFragment的几个关键生命周期函数：
@Override
public void onStart() {
super.onStart();
lifecycle.onStart();
}
@Override
public void onStop() {
super.onStop();
lifecycle.onStop();
}
@Override
public void onDestroy() {
super.onDestroy();
lifecycle.onDestroy();
unregisterFragmentWithRoot();
}
RequestManagerFragment的生命周期相关的函数调用lifecycle对象对应的方法，而lifecycle是在SupportRequestManagerFragment构造函数数中创建的：
public SupportRequestManagerFragment() {
this(new ActivityFragmentLifecycle());
}
ActivityFragmentLifecycle内部维持了生命周期的监听者列表：
class ActivityFragmentLifecycle implements Lifecycle {
private final Set<LifecycleListener> lifecycleListeners =
Collections.newSetFromMap(new WeakHashMap<LifecycleListener, Boolean>());
//...
}
当RequestManagerFragment生命周期变化时，调用ActivityFragmentLifecycle的对应生命周期方法，其实现就是遍历生命周期监听列表，并调用监听者对应的生命周期方法：
void onStart() {
isStarted = true;
for (LifecycleListener lifecycleListener : Util.getSnapshot(lifecycleListeners)) {
lifecycleListener.onStart();
}
}
那么什么时候添加监听者到ActivityFragmentLifecycle呢？答案是创建RequestManager的时候，我们看下RequestManager构成函数：
RequestManager(
Glide glide,
Lifecycle lifecycle,
RequestManagerTreeNode treeNode,
RequestTracker requestTracker,
ConnectivityMonitorFactory factory,
Context context) {
this.glide = glide;
this.lifecycle = lifecycle;
this.treeNode = treeNode;
this.requestTracker = requestTracker;
this.context = context;
connectivityMonitor =
factory.build(
context.getApplicationContext(),
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()) {
//如果是自线程，则切换到主线程监听生命周期
mainHandler.post(addSelfToLifecycle);
} else {
//监听生命周期
lifecycle.addListener(this);
}
//生命周期变化时，相应的监听网络状态和取消监听网络装
lifecycle.addListener(connectivityMonitor);
setRequestOptions(glide.getGlideContext().getDefaultRequestOptions());
glide.registerRequestManager(this);
}
ok，最后我们总结下Glide是如何自动感应生命周期的：
- 如果是在子线程，这Glide使用的RequestManager与Application一样的生命周期
- 如果是fragment、activity,则使用FragmentManagerFragment与RequestManager进行关联，通过FragmentManagerFragment的生命周期变化来调度RequestManager对图片加载请求Request采取暂停、重新开始、停止等操作。
因为Android有fragment、support包中的fragment、activity、surport中的activity，因为使用FragmentManagerFragment来实现RequestManager感应生命周期，这几个fragmengt、activity使用的FragmentManager各自不同，如果是fragment在用ChildFragmentManager或者support中的ChildFragmentManager；如果是activity则用FragmentManager或者support中的FragmentManager。所以RequestManagerRetriever主要用来根据framgnet、activity来创建对应的RequestManager。
问题：Glide中最多有几个RequestManager？
答案：5个，分别是： - 与Application生命周期一致的RequestManager
- 与app包下activity的FragmentManager关联的RequestManager
- 与app包下fragment的ChildFragmentManager关联的RequestManager
- 与support包下activity的FragmentManager关联的RequestManager
- 与support包下fragment的ChildFragmentManager关联的RequestManager
问题：Glide的get操作有哪些优化点？
答案： - 在UI线程中调用，可以避免RequestManager生命周期与Application的一直
- 尽量采用support报下的fragment/activity；一是因为兼容性；二是如果统一使用support包下的可以避免创建于与app包下FragmentManager管理的RequestManager
- get尽量传递fragment或者activity，这样可以减少通过view找到具体的fragment或者activity的步骤
网友评论