通过这些方法获取或者创建 Fragment

@NonNullprivate RequestManager supportFragmentGet(@NonNull Context context,@NonNull FragmentManager fm,@Nullable Fragment parentHint,boolean isParentVisible) {SupportRequestManagerFragment current =getSupportRequestManagerFragment(fm, parentHint, isParentVisible);RequestManager requestManager = current.getRequestManager();if (requestManager == null) {// TODO(b/27524013): Factor out this Glide.get() call.Glide glide = Glide.get(context);requestManager =factory.build(glide, current.getGlideLifecycle(), current.getRequestManagerTreeNode(), context);current.setRequestManager(requestManager);}return requestManager;}

• 使用 getSupportRequestManagerFragment（）方法获的 SupportRequestManagerFragment。

• 如果是第一次，创建 RequestManager，并设置设置给 SupportRequestManager。如果不是第一次，直接从 SupportRequestManagerFragment 中获取。

• 返回 RequestManager 对象

1.3、 SupportRequestManager 的构建

...final Map<FragmentManager, SupportRequestManagerFragment> pendingSupportRequestManagerFragments =new HashMap<>();...@NonNullprivate SupportRequestManagerFragment getSupportRequestManagerFragment(@NonNull final FragmentManager fm, @Nullable Fragment parentHint, boolean isParentVisible) {//在 Fragment 中找 ManagerFragmentSupportRequestManagerFragment current =(SupportRequestManagerFragment) fm.findFragmentByTag(FRAGMENT_TAG);

if (current == null) {//如果在没找到，就在存储的 map 中尝试获取 current = pendingSupportRequestManagerFragments.get(fm);if (current == null) {//没有就创建新的。current = new SupportRequestManagerFragment();current.setParentFragmentHint(parentHint);if (isParentVisible) {current.getGlideLifecycle().onStart();}pendingSupportRequestManagerFragments.put(fm, current);//移除 handler.obtainMessage(ID_REMOVE_SUPPORT_FRAGMENT_MANAGER, fm).sendToTarget();}}return current;}

如注释中所言，

• 如果 FragmentManager 中不存在 tag 为 FRAGMENT_TAG 然后返回

• 简而言之，RequestManagerTreeNode 用来获取绑定该 RequestManagerFragment 的 Fragment 的所有子 Fragment 所绑定的 RequestManagerFragment 所绑定的 RequestManager

• 值得注意在 FragmentManager 中没有发现 TAG 为 fragement_tag 的时候会从 pendingSupportRMF 中获取如果没有就创建新的然后先将新创建的 RMF 放入 pendingSupportRM 中然后执行添加 transaction 紧接着通过 handler 又将 RMF 从 pendingSupportRM 中移除了，思考，为什么？ 因为

fm.beginTransaction().add(current, FRAGMENT_TAG).commitAllowingStateLoss();

这个操作是异步的！什么概念就是试想：这样的情况

public test(){Glide.with(activity).load("xxx1").into(target1);//1Glide.with(activity).load("xxx1").into(target2);//2}

代码 1 和代码 2 被调用假设当前的 activity 还没有 RequestManagerFragemnt，必然就会执行去创建的流程，代码 1 执行到了 pendingSupportRequestManagerFragments.put(fm, current);异步去添加，也就是使用 handler 将整个添加操作包装成了 Message 发送到了主线程的 Looper 中的 messageQueue 中而不是立即执行会等到 Looper.looper（）中遍历到它然后交给他的 handler 去处理他。异步添加在 RFM 没有添加到 Activity 中的时候，然后代码 2 就执行了同样也 Activity 中没有 RFM 也会去创建，这样就会在同一 Activity 中有两个 RequesManagerFragment 就出事了，所以引入了 pendingSupportRequestManagerFragments，保证不会有上述情况的发生。向 Activity 中添加 RFM 这个异步任务之后，向 Handler 发送移除从 pendingSupportRequestManagerFragments 移除，这样就保证，在添加成功之前，都能在 pendingSupportRequestManagerFraments 中获取到 RFM。

1.4、SupportRequestManagerFragment

public class SupportRequestManagerFragment extends Fragment {

private final ActivityFragmentLifecycle lifecycle;private final RequestManagerTreeNode requestManagerTreeNode = ...@Nullable private SupportRequestManagerFragment rootRequestManagerFragment;@Nullable private RequestManager requestManager;...public SupportRequestManagerFragment() {this(new ActivityFragmentLifecycle());}ActivityFragmentLifecycle getGlideLifecycle() {return lifecycle;}...private void addChildRequestManagerFragment(SupportRequestManagerFragment child) {childRequestManagerFragments.add(child);}

private void removeChildRequestManagerFragment(SupportRequestManagerFragment child) {childRequestManagerFragments.remove(child);}......@Overridepublic void onAttach(Context context) {super.onAttach(context);registerFragmentWithRoot(getActivity());}

@Overridepublic void onDetach() {super.onDetach();unregisterFragmentWithRoot();}...

• RequestManagerFragment 在构造函数中默认创建一个 ActivityFragmentLifecycle 类型的成员变量。

• 在 attach 中 registerFragmentWithRoot(),在 onDetach()中 unregisterFragmentWithRoot();

• 在 RequestManagerFragment 的对象中 onStart（），onStop，中调用 Lifecycle 的响应函数

• 在 RequestManager 当中会向 ActivityFragmentLifecycle 注册监听对象，于是 RequestManager 就会对组件生命周期做出相应的反应。

• 另外当该 Fragment 作为一个子 Fragment 被添加到 Fragment 当中感知 Fragment 时，涉及到子 Fragment 管理可参考

1.5、RequestManager 对 Activity/Fragment 生命周期感知

public class RequestManager implements LifecycleListenerprotected final Glide glide;protected final Context context;final Lifecycle lifecycle;private final RequestTracker requestTracker;...RequestManager(...) {...//RequestManager 将自身注册到 Lifecycle 中也就是 RequestManagerFragment 中的 Lifecyclelifecycle.addListener(this);lifecycle.addListener(connectivityMonitor);}public synchronized boolean isPaused() {return requestTracker.isPaused();}public synchronized void pauseRequests() {requestTracker.pauseRequests();}public synchronized void pauseAllRequests() {requestTracker.pauseAllRequests();}public synchronized void resumeRequests() {requestTracker.resumeRequests();}//相应的生命周期函数中使用处理土拍你请求 @Overridepublic synchronized void onStart() {resumeRequests();targetTracker.onStart();}@Overridepublic synchronized void onStop() {pauseRequests();targetTracker.onStop();}//在 onDestoty 中取消解除绑定释放请求中的设计的资源 @Overridepublic synchronized void onDestroy() {targetTracker.onDestroy();targetTracker.clear();requestTracker.clearRequests();lifecycle.removeListener(this);...glide.unregisterRequestManager(this);}}

• RequestManager 实现了 LifecycleListener,且创建的时候传入了 Lifecycle 参数赋值给成员变量。

• 被该 RequestManager 管理的请求都存放在 RequestTracker 对象这个成员变量属性中。

• RequestManager 通过 Lifecycle 感知组件生命周期变化，在相应的生命周期状态下实现的 LifecyleListener 对应的回调函数会被执行，然后通过 RequestTracker 管理自己所关联的 Request 对象们。

Glide 中 Lifecycle 小结

为一个 Request 拥有所在组件的感知能力需要以下步骤：

1.从给定的组件（Fragment/FragmentActivity/Activity...）获取出 FragmentManager。

2.创建一个不带界面的 Fragment（SupportRequestManagerFragment/RequestManagerFragment),这个不带界面的 Frament 有个 Lifecycle 成员变量，在 Fragment 创建的时候被初始化，用于监听此 Fragment 的生命周期。

3.将不带界面的 Frament 添加进给定组件。

4.创建 RequestManager，RequestManager 实现了 LifecycleListener，创建的时候会传入无界面 fragment 中成员 Lifecyle，RequestManager 会把自己注册到 Lifecycle 中，这样 RequestManager 就拥有了感知组件生命周期的能力。

2、RxLifecycle

对 RxLifecycle 原理分析主要是依据 trello 的 RxLifecycle，github 传送门[点这里](

)

2.1、简单使用

在 Activity 中使用为例，主要是使用以下两个方法：

bindUntilEvent(@NonNull ActivityEvent event)

bindToLifecycle()

使用的姿势是这样的：当 Activity 回调 onDestory 生命周期函数的时候，就会解除订阅。

Observable.interval(1, TimeUnit.SECONDS).compose(bindUntilEvent(ActivityEvent.DESTROY)).subscribe();

2.2、RxActivity 构成

追根溯源看看 要先理解 Rxjava2 中 compose()操作符的含义 compose 操作符是在不破坏 rxjava 流式基础上把当前的 Observable 转换为另一个 Observable，传入的是一个 Transformer 对象使用。更为详细的关于这个操作符的介绍[点这](

)

public abstract class RxActivity extends Activity implements LifecycleProvider<ActivityEvent> {

private final BehaviorSubject<ActivityEvent> lifecycleSubject = BehaviorSubject.create();@CheckResultpublic final <T> LifecycleTransformer<T> bindUntilEvent(@NonNull ActivityEvent event) {return RxLifecycle.bindUntilEvent(lifecycleSubject, event);}

public final <T> LifecycleTransformer<T> bindToLifecycle() {return RxLifecycleAndroid.bindActivity(lifecycleSubject);}

protected void onCreate(@Nullable Bundle savedInstanceState) {super.onCreate(savedInstanceState);lifecycleSubject.onNext(ActivityEvent.CREATE);}........protected void onDestroy() {lifecycleSubject.onNext(ActivityEvent.DESTROY);super.onDestroy();}}

• Activity 中有个一个 BehaviorSubject 的成员变量：lifecycleSubject。BehaviorSubject 会发送离订阅最近的上一个值，当没有最近值的的时候会发送默认值。

• bindUntilEvent(ActivityEvent avt)最终会返回一个 Transformer 作为 compose()方法的参数。

• bindUtliEvent 方法是 RxActivity 实现了 LifecycleProvider 接口的方法，他的实现转交到了 RxLifecycle.bindUntilEvent()

2.3 LifecycleTransformer 构建

关于 Transformer 构建在 RxlifeCycle 类中主要是以下三个方法：

@CheckReturnValuepublic sta

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

tic <T, R> LifecycleTransformer<T> bindUntilEvent(@Nonnull final Observable<R> lifecycle,@Nonnull final R event) {...判空 return bind(takeUntilEvent(lifecycle, event));}

使用 filter()操作符，获取一个过滤出传入的指定事件，其他事件不向下游分发的 Observer，也就是只发送指定事件的 Observable。

private static <R> Observable<R> takeUntilEvent(final Observable<R> lifecycle, final R event) {return lifecycle.filter(new Predicate<R>() {@Overridepublic boolean test(R lifecycleEvent) throws Exception {return lifecycleEvent.equals(event);}});

将上一步得到的 Observable 其实是一个 BehaviorSubject，当做构造参数传入 LifecycleTransformer

public static <T, R> LifecycleTransformer<T> bind(@Nonnull final Observable<R> lifecycle) {return new LifecycleTransformer<>(lifecycle);}

2.4 LifecycleTransformer 原理

看看 LifecyclerTranformer 里卖的啥药

public final class LifecycleTransformer<T> implements ObservableTransformer<T, T>,FlowableTransformer<T, T>,SingleTransformer<T, T>,MaybeTransformer<T, T>,...@Overridepublic ObservableSource<T> apply(Observable<T> upstream) {return upstream.takeUntil(observable);}...

}

真相大白，对 upstream 也就是我们使用时，xxx.compose()时的那个 Observerable 进行了 takeUtil（）操作。 takeUtil 的语义是

Returns an Observable that emits the items emitted by the source Observable until a second ObservableSource emits an item. 返回一个发送事件的观察源，直到第二个被观察者发送数据。

综上 当给被观察序列 compose 了 Transformer 对象后，会在相应的生命周期函数中终止。

2.5 小结

• Activity 中有个 BehaviorSubject 在 Activity 的生命周期回调函数中发送向其发送相应的事件。