Glide4.9图片框架源码(二)之如何绑定Activity的生命周期

上一节我们简单的介绍了Glide的常规使用方法，有需要的话可以看看上一节：

Glide框架之加载图片的常规使用方式

Glide.with(this).load(url).into(imageView)

标题这一句代码，囊括了整个Glide的核心功能，可以说Glide在这一行代码中做了成吨的工作，最繁重的任务是在into方法中，但是我们根据顺序，首先看一下with方法。说到Glide源码，面试中大家可能都知道Glide为何能监听页面或者application的生命周期，从而及时的取消请求和回收对象，是通过绑定一个空的fragment。那么我们就来看一下，with方法中，是如何实现这个操作的。

Glide.with(this)方法

    @NonNull
    public static RequestManager with(@NonNull Context context) {
        return getRetriever(context).get(context);
    }

    @NonNull
    public static RequestManager with(@NonNull Activity activity) {
        return getRetriever(activity).get(activity);
    }

    @NonNull
    public static RequestManager with(@NonNull FragmentActivity activity) {
        return getRetriever(activity).get(activity);
    }

    @NonNull
    public static RequestManager with(@NonNull Fragment fragment) {
        return getRetriever(fragment.getActivity()).get(fragment);
    }

    /** @deprecated */
    @Deprecated
    @NonNull
    public static RequestManager with(@NonNull android.app.Fragment fragment) {
        return getRetriever(fragment.getActivity()).get(fragment);
    }

    @NonNull
    public static RequestManager with(@NonNull View view) {
        return getRetriever(view.getContext()).get(view);
    }

glide提供的with方法比较多，其实这里看的出来，不管是传入context还是activity亦或是fragment，其实还是拿到当前页面所属的context，那么这里是情况其实只有两种，一种是普通的context，另一种这是applicationcontext。我们以传入context为例，调用的是return getRetriever(context).get(context)，返回值则是一个RequestManager，我们跟进去看看getRetriever(context)方法：

    @NonNull
    private static RequestManagerRetriever getRetriever(@Nullable Context context) {
        Preconditions.checkNotNull(context, "You cannot start a load on a not yet attached View or a Fragment 
          where getActivity() returns null (which usually occurs when getActivity() is called 
          before the Fragment is attached or after the Fragment is destroyed).");
        return get(context).getRequestManagerRetriever();
    }

checkNotNull方法执行的是context的空检查，我们继续看一下get(context).getRequestManagerRetriever()中的get(context)

 @NonNull
    public static Glide get(@NonNull Context context) {
        if (glide == null) {
            Class var1 = Glide.class;
            synchronized(Glide.class) {
                if (glide == null) {
                    checkAndInitializeGlide(context);
                }
            }
        }
        return glide;
    }

这里get方法是获取glide实例，实现的一个单例方法，其中checkAndInitializeGlide对glide进行初始化，这里我们不去细究回到上一步继续看看get(context).getRequestManagerRetriever()的getRequestManagerRetriever()方法

    @NonNull
    public RequestManagerRetriever getRequestManagerRetriever() {
        return this.requestManagerRetriever;
    }

这里直接返回的是RequestManagerRetriever，那么这个变量是什么时候初始化的呢，我们看下Glide的build方法发现这里初始化了RequestManagerRetriever。到这里with方法中的getRetriever(context).get(context)的getRetriever结束，我们继续看看get(context)，这里应该返回了一个RequestManagerRetriever里面的RequestManager，来看下源码：

 @NonNull
    public RequestManager get(@NonNull 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 this.get((FragmentActivity)context);
                }
                if (context instanceof Activity) {
                    return this.get((Activity)context);
                }
                if (context instanceof ContextWrapper) {
                    return this.get(((ContextWrapper)context).getBaseContext());
                }
            }
            return this.getApplicationManager(context);
        }
    }

这里看出将context分成了两种类型，一种是context instanceof Application，另一种则是普通context。先看看如果是普通的context，这里FragmentActivity、Activity其实差不多，内部创建的fragment支持的类型不同。如果是ContextWrapper类型则继续取到baseContext，递归调用get(context)。那么这里我们看看Activity的场景的源码this.get((Activity)context)：

@NonNull
    public RequestManager get(@NonNull Activity activity) {
        if (Util.isOnBackgroundThread()) {
            return this.get(activity.getApplicationContext());
        } else {
            assertNotDestroyed(activity);
            FragmentManager fm = activity.getFragmentManager();
            return this.fragmentGet(activity, fm, (android.app.Fragment)null, isActivityVisible(activity));
        }
    }

这里的if判断表示如果当前程序是在后台运行，那么传入getApplicationContext去get RequestManager ，这里ApplicationContext的情况我们等会儿单独再讲，继续看下面的代码，我们看到activity.getFragmentManager()，获取当前activity的FragmentManager，然后调用了fragmentGet方法，那么继续看看这个方法的源码：

   /** @deprecated */
    @Deprecated
    @NonNull
    private RequestManager fragmentGet(@NonNull Context context, @NonNull FragmentManager fm, @Nullable android.app.Fragment parentHint, boolean isParentVisible) {
        RequestManagerFragment current = this.getRequestManagerFragment(fm, parentHint, isParentVisible);
        RequestManager requestManager = current.getRequestManager();
        if (requestManager == null) {
            Glide glide = Glide.get(context);
            requestManager = this.factory.build(glide, current.getGlideLifecycle(), current.getRequestManagerTreeNode(), context);
            current.setRequestManager(requestManager);
        }
        return requestManager;
    }

重点来了，我们看到第一行返回了一个RequestManagerFragment ，我们跟进去看看这个fragment是怎么创建的：

  @NonNull
    private RequestManagerFragment getRequestManagerFragment(@NonNull FragmentManager fm, @Nullable android.app.Fragment parentHint, boolean isParentVisible) {
        RequestManagerFragment current = (RequestManagerFragment)fm.findFragmentByTag("com.bumptech.glide.manager");
        if (current == null) {
            current = (RequestManagerFragment)this.pendingRequestManagerFragments.get(fm);
            if (current == null) {
                current = new RequestManagerFragment();
                current.setParentFragmentHint(parentHint);
                if (isParentVisible) {
                    current.getGlideLifecycle().onStart();
                }
                this.pendingRequestManagerFragments.put(fm, current);
                fm.beginTransaction().add(current, "com.bumptech.glide.manager").commitAllowingStateLoss();
                this.handler.obtainMessage(1, fm).sendToTarget();
            }
        }
        return current;
    }

这里我们先通过pendingRequestManagerFragments从缓存中去拿RequestManagerFragment ，这里的pendingRequestManagerFragment就是一个hashmap，Map<FragmentManager, RequestManagerFragment>，如果缓存中没有，那么去new一个fragment并且将其添加到缓存中，重点来了， fm.beginTransaction().add(current, "com.bumptech.glide.manager").commitAllowingStateLoss();这里便将一个没有ui的fragment添加到了context对应的activity上。回到前面我们提到的applicationcontext，看看这种情况，调用的是getApplicationManager：

 @NonNull
    private RequestManager getApplicationManager(@NonNull Context context) {
        if (this.applicationManager == null) {
            synchronized(this) {
                if (this.applicationManager == null) {
                    Glide glide = Glide.get(context.getApplicationContext());
                    this.applicationManager = this.factory.build(glide, new ApplicationLifecycle(), new EmptyRequestManagerTreeNode(), context.getApplicationContext());
                }
            }
        }
        return this.applicationManager;
    }

这里我们直接看factory的build方法，跟进去看一源码：

private static final RequestManagerFactory DEFAULT_FACTORY = new RequestManagerFactory() {
    @NonNull
    @Override
    public RequestManager build(@NonNull Glide glide, @NonNull Lifecycle lifecycle,
        @NonNull RequestManagerTreeNode requestManagerTreeNode, @NonNull Context context) {
      return new RequestManager(glide, lifecycle, requestManagerTreeNode, context);
    }
  };

这里根据传入applicationContext去创建一个RequestManager并返回，到这里整个with方法就结束了，我们再看看fragment对应的生命周期方法中做了什么：

@Override
  public void onDetach() {
    super.onDetach();
    unregisterFragmentWithRoot();
  }

  @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();
  }

这里可以看出，当activity触发生命周期的时候，当前无UI的fragment也会触发相应的生命周期方法，那么这里的lifecycle调用到了哪里呢，跟进去发现调用的是ActivityFragmentLifecycle实现的几个方法：

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();
    }
  }

这里的lifecycleListeners存储了前面添加的多个生命周期的监听，在这里全部触发，那么这里我们之前添加的
lifecycleListener 包括了RequestManager中的，我们在RequestManager创建的时候就已经添加了一个listener到lifecycleListeners中，所以这里的onStart、onStop、onDestroy会调用RequestManager里面的对应方法，RequestManager作为一个管理类，管理了两个重要的对象，一个是target，另一个是request，因此RequestManager通过监听生命周期方法，同时控制了target和request的加载情况，我们来看下代码：

  @Override
  public synchronized void onStart() {
    resumeRequests();
    targetTracker.onStart();
  }

  @Override
  public synchronized void onStop() {
    pauseRequests();
    targetTracker.onStop();
  }

  @Override
  public synchronized void onDestroy() {
    targetTracker.onDestroy();
    for (Target<?> target : targetTracker.getAll()) {
      clear(target);
    }
    targetTracker.clear();
    requestTracker.clearRequests();
    lifecycle.removeListener(this);
    lifecycle.removeListener(connectivityMonitor);
    mainHandler.removeCallbacks(addSelfToLifecycle);
    glide.unregisterRequestManager(this);
  }

可以看到，在对应的生命周期方法中控制了targetTracker和requestTracker，这两个对象则分别控制这target和request的生命周期。到这里我们的width方法源码流程就结束了。

RequestManager的load(url)方法

上面我们分析的是Glide.with(this).load(url).into(imageView)中的with方法，那么我们继续看load，width返回的是RequestManager，那么自然load方法在RequestManager中，我们看下源码：

  @Override
public RequestBuilder<Drawable> load(@Nullable Bitmap bitmap) {
    return asDrawable().load(bitmap);
  }

  @Override
  public RequestBuilder<Drawable> load(@Nullable Drawable drawable) {
    return asDrawable().load(drawable);
  }

  @Override
  public RequestBuilder<Drawable> load(@Nullable String string) {
    return asDrawable().load(string);
  }

  @Override
  public RequestBuilder<Drawable> load(@Nullable Uri uri) {
    return asDrawable().load(uri);
  }

  @Override
  public RequestBuilder<Drawable> load(@Nullable File file) {
    return asDrawable().load(file);
  }

  @Override
  public RequestBuilder<Drawable> load(@RawRes @DrawableRes @Nullable Integer resourceId) {
    return asDrawable().load(resourceId);
  }

  @Override
  public RequestBuilder<Drawable> load(@Nullable URL url) {
    return asDrawable().load(url);
  }

  @Override
  public RequestBuilder<Drawable> load(@Nullable byte[] model) {
    return asDrawable().load(model);
  }

  @Override
  public RequestBuilder<Drawable> load(@Nullable Object model) {
    return asDrawable().load(model);
  }

glide提供的load方法极多，涵盖了大多数的图片加载资源，例如字节码，URL，Drawable，文件，bitmap，字符串的图片地址等等，这里我们就以常用的字符串的图片地址为例看下代码：

  @Override
  public RequestBuilder<Drawable> load(@Nullable String string) {
    return asDrawable().load(string);
  }

  @NonNull
  public RequestBuilder<Drawable> asDrawable() {
    return as(Drawable.class);
  }

  @NonNull
  public <ResourceType> RequestBuilder<ResourceType> as(
      @NonNull Class<ResourceType> resourceClass) {
    return new RequestBuilder<>(glide, this, resourceClass, context);
  }

  @Override
  @CheckResult
  public RequestBuilder<TranscodeType> load(@Nullable String string) {
    return loadGeneric(string);
  }

  @NonNull
  private RequestBuilder<TranscodeType> loadGeneric(@Nullable Object model) {
    this.model = model;
    isModelSet = true;
    return this;
  }

我们先看asDrawable方法，其实就是设置了图片资源的类型，然后创建了一个RequestBuilder对象，然后传入一个String类型并且调用load方法，这里是将我们的String URL设置到了model 对象中，并没有开始请求，所以我们的重点任务就放在了into方法中，它包括了获取内存缓存，获取磁盘缓存，请求，写入内存和磁盘缓存等许多操作，那么我们下一节再继续分析最重要的一步into方法吧~

总结

首先通过width方法中的getRetriever方法，完成Glide的初始化并且获取到RequestManagerRetriever，RequestManagerRetriever主要用于管理和生成RequestManager，然后通过RequestManagerRetriever的get方法为activity创建一个无UI的fragment，并且绑定到当前activity，然后生成一个RequestManager并且与之关联生命周期，当activity的生命周期发生改变时，通知绑定的fragment，继而通知到RequestManager的监听方法，从而控制对target和request的加载、暂停和销毁。

下一节我们讲讲into(imageview)中的内存缓存：

Glide源码之into方法后续读取内存缓存

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 211,948评论 6赞 492
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 90,371评论 3赞 385
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 157,490评论 0赞 348
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 56,521评论 1赞 284
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 65,627评论 6赞 386
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 49,842评论 1赞 290
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 38,997评论 3赞 408
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 37,741评论 0赞 268
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 44,203评论 1赞 303
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,534评论 2赞 327
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,673评论 1赞 341
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 34,339评论 4赞 330
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 39,955评论 3赞 313
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,770评论 0赞 21
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,000评论 1赞 266
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 46,394评论 2赞 360
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 43,562评论 2赞 349