Glide源码解析(一)

Glide源码解析系列文章基于Glide4.5.0,源码看了很多遍,慢慢理清,文章链接如下:
Glide源码解析(一)
Glide源码解析(二)
Glide源码解析(三)
Glide最基本的使用如下:

Glide.with(this)
        .load(R.raw.large_giphy_logo)
        .into(giphyLogoView);

1、with()返回RequestManager对象
2、load()返回RequestBuilder对象
3、into()返回Target对象
很简单,本篇主要讲解Glide.with(this),with方法如下:

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

接着接入getRetriever方法:

private static RequestManagerRetriever getRetriever(@Nullable Context context) {
   ...
    return Glide.get(context).getRequestManagerRetriever();
  }

我们来看get方法中都做了什么:

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

从上面可以看到在get方法中采用双重检验锁(DCL)的方式生成单例,glide变量用volatile关键字修饰。接下来看checkAndInitializeGlide()方法:

private static void checkAndInitializeGlide(@NonNull Context context) {
 if (isInitializing) {
    throw new IllegalStateException("You cannot call Glide.get() in registerComponents(),"
        + " use the provided Glide instance instead");
  }
  isInitializing = true;
  initializeGlide(context);
  isInitializing = false;
}

isInitializing 同样是volatile的,若是没有被初始化,则调用initializeGlide(context);

private static void initializeGlide(@NonNull Context context) {
  initializeGlide(context, new GlideBuilder());
}

在initializeGlide()中,创建了GlideBuilder对象作为参数,调用

@SuppressWarnings("deprecation")
private static void initializeGlide(@NonNull Context context, @NonNull GlideBuilder builder) {
...
 GeneratedAppGlideModule annotationGeneratedModule = getAnnotationGeneratedGlideModules();
    List<com.bumptech.glide.module.GlideModule> manifestModules = Collections.emptyList();
    if (annotationGeneratedModule == null || annotationGeneratedModule.isManifestParsingEnabled()) {
      manifestModules = new ManifestParser(applicationContext).parse();
    }
    ...
    //移除相同的GlideModule
    ...
    RequestManagerRetriever.RequestManagerFactory factory =
        annotationGeneratedModule != null
            ? annotationGeneratedModule.getRequestManagerFactory() : null;
   ...
   //设置GlideBuilder
   ...
   ;
    ...
   //注册组件
    ...
   //注册内存优化的系统回调
    applicationContext.registerComponentCallbacks(glide);
    Glide.glide = glide;
}

这个方法被标记为deprecation,表示这个方法以后可能会被弃用.在getAnnotationGeneratedGlideModules中:

private static GeneratedAppGlideModule getAnnotationGeneratedGlideModules() {
   ...
    Class.forName("com.bumptech.glide.GeneratedAppGlideModuleImpl");
      result = clazz.getDeclaredConstructor().newInstance();
   ...
    return result;
  }

我们看到GeneratedAppGlideModuleImpl这样一个类,这个类集成自一个叫GeneratedAppGlideModule的虚类,GeneratedAppGlideModule继承自AppGlideModule。在GeneratedAppGlideModuleImpl中,注入了我们自己定义的一个AppGlideModule,所以这个类其实是相当于一个代理。每个应用程序中只能有一个AppGlideModules,可以存在多个LibraryGlideModules在AppGlideModule中,有以下几个方法:

  1. isManifestParsingEnabled()
    表示是否检测AndroidManifest里面的GlideModule 该方法,默认返回true。 如果我们通过注解和继承AppGlideModule生成自己的module时,官方要求我们实现并返回false,避免AndroidManifest加载两次。

  2. applyOptions()
    在Glide被创建之前,对GlideBuilder进行设置

  3. registerComponents()
    当使用Glide的注释处理器时,在应用程序中初始化Glide时注册使用的一组组件。
    接着我们看initializeGlide方法中glide的生成:
    Glide glide = builder.build(applicationContext);
    进入Glidebuilder的build方法:
 public Glide build(@NonNull Context context) {
    //用来执行Glide的加载,解码和转换业务(请求图片的线程池),是一个依赖于优先级的线程池,线程数量取决于当前唤醒的CPU数量,而不是CPU总数,但虽多不超过4
    if (sourceExecutor == null) {
      sourceExecutor = GlideExecutor.newSourceExecutor();
    }
    //用来执行Glide的加载,解码和转换业务,依赖于优先级的线程池(硬盘缓存线程池),线程数为1
    if (diskCacheExecutor == null) {
      diskCacheExecutor = GlideExecutor.newDiskCacheExecutor();
    }
    //用来加载动画帧,线程数由可用CPU数决定,若可用CPU数不小于4,则加载的线程数为2,否则为1。
    if (animationExecutor == null) {
      animationExecutor = GlideExecutor.newAnimationExecutor();
    }
    //用来计算缓存图片的大小以及各种烦缓存pool的size,依据主要是屏幕密度和尺寸,
    if (memorySizeCalculator == null) {
      memorySizeCalculator = new MemorySizeCalculator.Builder(context).build();
    }
    //网络活动监视器,用来检测网络状态
    if (connectivityMonitorFactory == null) {
      connectivityMonitorFactory = new DefaultConnectivityMonitorFactory();
    }
    //bitmap池,用来存储bitmap对象,提升内存复用,size为所运行设备的建议bitmap池大小
    if (bitmapPool == null) {
      int size = memorySizeCalculator.getBitmapPoolSize();
      if (size > 0) 
      {
      //从bitmap池中拿取,没有拿到才新建位图
        bitmapPool = new LruBitmapPool(size);
      } else {
      //永远是返回新建位图
        bitmapPool = new BitmapPoolAdapter();
      }
    }
    //byte数组缓存池
    if (arrayPool == null) {
      arrayPool = new LruArrayPool(memorySizeCalculator.getArrayPoolSizeInBytes());
    }
    //内存缓存,使用了LRU的方式
    if (memoryCache == null) {
      memoryCache = new LruResourceCache(memorySizeCalculator.getMemoryCacheSize());
    }
    //硬盘缓存,使用了DiskLruCache
    if (diskCacheFactory == null) {
      diskCacheFactory = new InternalCacheDiskCacheFactory(context);
    }
    //负责开启,加载任务以及管理活跃的或者缓存的图片资源
    if (engine == null) {
      engine =
          new Engine(
              memoryCache,
              diskCacheFactory,
              diskCacheExecutor,
              sourceExecutor,
              GlideExecutor.newUnlimitedSourceExecutor(),
              GlideExecutor.newAnimationExecutor(),
              isActiveResourceRetentionAllowed);
    }
    //用于创建新的RequestManager或从Activity或Fragment中检索现有的RequestManager,RequestManager后面再说
    RequestManagerRetriever requestManagerRetriever =
        new RequestManagerRetriever(requestManagerFactory);
    return new Glide(
        context,
        engine,
        memoryCache,
        bitmapPool,
        arrayPool,
        requestManagerRetriever,
        connectivityMonitorFactory,
        logLevel,
        defaultRequestOptions.lock(),
        defaultTransitionOptions);
  }

从上面可以看到初始化的requestManagerRetriever ,接着我们返回最初的with方法,bingo,拿到之后看RequestManagerRetriever 的get方法:

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

从上面的额代码我们看到,根据你Context 实际的类型,走不同的分支。若是不在主线程或者传入的是Application,那么返回的是getApplicationManager,Application对象的生命周期即应用程序的生命周期,因此这个情况下,它自动就是和应用程序的生命周期是同步的,如果应用程序关闭的话,Glide的加载也会同时终止。否则,其他情况下get方法如下:

public RequestManager get(@NonNull FragmentActivity activity) {
    if (Util.isOnBackgroundThread()) {
      return get(activity.getApplicationContext());
    } else {
      assertNotDestroyed(activity);
      FragmentManager fm = activity.getSupportFragmentManager();
      return supportFragmentGet(activity, fm, null /*parentHint*/);
    }
  }

  @NonNull
  public RequestManager get(@NonNull Fragment fragment) {
    Preconditions.checkNotNull(fragment.getActivity(),
          "You cannot start a load on a fragment before it is attached or after it is destroyed");
    if (Util.isOnBackgroundThread()) {
      return get(fragment.getActivity().getApplicationContext());
    } else {
      FragmentManager fm = fragment.getChildFragmentManager();
      return supportFragmentGet(fragment.getActivity(), fm, fragment);
    }
  }

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

可以看出,如果在子线程,默认当application处理!通过上图我们会发现不论传入Activity、FragmentActivity、Fragment最终都会调用fragmentGet方法,而这个方法最终就是那就是会向当前的Activity当中添加一个隐藏的Fragment (若with中传入的是Fragment,那么get会向当前fragment中添加一个无界面的子fragment)。
为什么要这样做呢?假想一下,若你在某个Activity上正在加载一张图片,图片还没加载出来,Activity被用户关掉了,那么图片就应该取消加载,可是Glide并不知道Activity的生命周期,怎么办呢? 于是Glide就使用了添加隐藏Fragment的这种小技巧,因为Fragment的生命周期和Activity是同步的,如果Activity被销毁了,Fragment是可以监听到的,这样Glide就可以捕获这个事件并停止加载图片。

最后插播一段,Glide类实现了ComponentCallbacks2接口,这是一个细粒度的内存回收管理回调,Application、Activity、Service、ContentProvide等均实现了ComponentCallback2接口,接口中有一个方法:onTrimMemory(),响应onTrimMemory回调,app会直接受益,有利于用户体验,系统更有可能让app存活的更持久。不响应onTrimMemory回调,系统更有可能kill 进程。在Glide中,方法实现为:

public void trimMemory(int level) {
    Util.assertMainThread();
    memoryCache.trimMemory(level);
    bitmapPool.trimMemory(level);
    arrayPool.trimMemory(level);
  }

可以看到裁剪工作是在主线程中进行,分别是对内存缓存,bitmap池和byte数据进行裁剪。

我感觉我把自己的瞌睡都要将来了,嗯,我是一个没有幽默感的程序员,有错误欢迎纠正~~~

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值