Glide源码解析（一）初始化和生命周期监听

回忆一下我们平时的用法

 Glide.with(context)
      .load(url)
      .into(imageView);

第一步是with(context),这个方法有许多重载，包括activity,fragment,view。这里会涉及两个重要的类，返回值RequestManager和RequestManagerRetriever，要生成RequestManagerRetriever的前提步骤是初始化glide。

private static RequestManagerRetriever getRetriever(@Nullable Context context) {
    
    //Glide.get(context)初始化了glide
    return Glide.get(context).getRequestManagerRetriever();
  }

初始化  

glide里面维护的是一个单例，所以只会初始化一次。顺着glide.get(context),发现最终调用到

private static void initializeGlide(@NonNull Context context, @NonNull GlideBuilder builder) {
    Context applicationContext = context.getApplicationContext();
    //1.通过反射获取全局的动态生成的配置类
    GeneratedAppGlideModule annotationGeneratedModule = getAnnotationGeneratedGlideModules();
    //2.获取manifest的配置类
    List<com.bumptech.glide.module.GlideModule> manifestModules = Collections.emptyList();
    if (annotationGeneratedModule == null || annotationGeneratedModule.isManifestParsingEnabled()) {
      manifestModules = new ManifestParser(applicationContext).parse();
    }
    ...

    //3.将开发者设置的配置提交到builder
    for (com.bumptech.glide.module.GlideModule module : manifestModules) {
      module.applyOptions(applicationContext, builder);
    }
    if (annotationGeneratedModule != null) {
      annotationGeneratedModule.applyOptions(applicationContext, builder);
    }
    //4.将开发者设置的配置提交到registry注册表
    Glide glide = builder.build(applicationContext);
    for (com.bumptech.glide.module.GlideModule module : manifestModules) {
      module.registerComponents(applicationContext, glide, glide.registry);
    }
    ...
    Glide.glide = glide;
  }

1. glide提供两种途径给开发者配置全局设置，分别是继承AppGlideModule注解动态生成固定类，getAnnotationGeneratedGlideModules()里面就是根据这个固定的类名反射初始化
2. 另外一种是写在Manifest的配置里，不过这种已经标记为过时，已经不推荐使用
3. 获取配置类后，下一步是调用配置类的applyOptions方法，这里传递了builder进去，目的就是让开发者设置builder的参数
4. registry是一个注册表，这个我们后续再详细分析

RequestManagerRetriever

大家应该知道glide可以感应activity生命周期,onDestory时自动帮我们取消请求。其原理是在请求的页面添加一个没有视图的frament。而创建这个framgnt的逻辑就在RequestManagerRetriever。

• 如果传递的context是application,就不会创建framgnt监听，所以页面结束还会继续请求
• 传递view的请求会尝试获取对应的activity对象，然后走activity的分支

@NonNull
  private RequestManager supportFragmentGet(
      @NonNull Context context,
      @NonNull FragmentManager fm,
      @Nullable Fragment parentHint,
      boolean isParentVisible) {
    //创建fragmnet
    SupportRequestManagerFragment current =
        getSupportRequestManagerFragment(fm, parentHint, isParentVisible);
    RequestManager requestManager = current.getRequestManager();
    if (requestManager == null) {
      // 创建requestManager 
      Glide glide = Glide.get(context);
      requestManager =
          factory.build(
              glide, current.getGlideLifecycle(), current.getRequestManagerTreeNode(), context);
      current.setRequestManager(requestManager);
    }
    return requestManager;
  }

可以看见我们最终要获取的requestManager 就是在这里创建。requestManager 的创建是用工厂模式，这个在上面glide初始化initializeGlide方法里面时是有默认设置的

RequestManagerRetriever.RequestManagerFactory factory =
        annotationGeneratedModule != null
            ? annotationGeneratedModule.getRequestManagerFactory() : null;



//自动生成类里面的实现
  GeneratedRequestManagerFactory getRequestManagerFactory() {
    return new GeneratedRequestManagerFactory();
  }


final class GeneratedRequestManagerFactory implements RequestManagerRetriever.RequestManagerFactory {
  @Override
  @NonNull
  public RequestManager build(@NonNull Glide glide, @NonNull Lifecycle lifecycle,
      @NonNull RequestManagerTreeNode treeNode, @NonNull Context context) {
    return new GlideRequests(glide, lifecycle, treeNode, context);
  }
}

public class GlideRequests extends RequestManager {
  public GlideRequests(@NonNull Glide glide, @NonNull Lifecycle lifecycle,
      @NonNull RequestManagerTreeNode treeNode, @NonNull Context context) {
    super(glide, lifecycle, treeNode, context);
  }
}

默认使用自动生成类的工厂，工厂创建出来的是继承RequestManager 的子类。这就是为什么我们用GlidApp时可以调用一些扩展的api,另外我们还可以用GlideExtension注解自定义一些api。不得不说，glide的设计十分巧妙