Glide图片加载库

Glide是一个在Android平台上广受欢迎的图片加载库，它专心于快速高效地加载图片，并供给了许多强大的功用和特性。Glide被设计用于处理图片加载过程中的复杂性，包含异步加载、缓存办理、图片变换和资源重用等问题。

首要特点和功用包含：

总体而言，Glide是一个功用强大且易于运用的图片加载库，为Android开发者供给了简化图片加载流程的解决方案，一起经过优化资源办理和加载功用，供给更好的用户体会。

本篇文章首要讨论Glide的生命周期感知功用，首要咱们要了解生命周期感知功用的重要性。

生命周期感知

什么是生命周期感知

在Android开发中，”生命周期感知”是指运用或组件能够发觉和响应其所属的Activity、Fragment或其他组件的生命周期状况改变。这意味着当一个组件（如Activity或Fragment）进入不同的生命周期阶段（例如创立、发动、中止、毁掉等），其相关的其他组件能够感知这些改变并做出相应的操作。

生命周期感知的首要意图是优化资源办理和提高用户体会。经过对组件的生命周期进行感知，运用能够在恰当的机遇开释资源、中止后台使命、撤销网络恳求等，然后防止内存走漏、节约设备电量、进步运用响应速度，以及改进用户对运用的全体满意度。

在Android中，Activity和Fragment是最常见的具有生命周期的组件。它们的生命周期包含以下阶段：

1. 创立（ Created ） ：组件被创立但没有可见，此刻能够进行一些初始化工作。

2. 发动（ Started ） ：组件已经可见，但没有获取焦点，能够开端加载数据或预备展现界面。

3. 康复（ Resumed ） ：组件可见且获取焦点，用户能够与其进行交互，这是最活跃的状况。

4. 中止（ Stopped ） ：组件不行见但依然存在，此刻能够开释一些不必要的资源。

5. 毁掉（ Destroyed ） ：组件被毁掉，应该开释一切的资源和撤销一切的操作。

经过完结生命周期感知，开发者能够注册监听器或回调来获取组件生命周期改变的告诉，并在合适的机遇履行相关的操作。Glide图片加载库便是一个很好的例子，它经过监听Activity或Fragment的生命周期，主动中止图片加载和开释资源，保证在资源不再需求时能够及时回收，防止内存走漏和资源糟蹋。

生命周期感知功用的重要性以及在图片加载中的效果

生命周期感知功用在Android开发中扮演着至关重要的人物，尤其在涉及资源办理和用户体会方面。以下是生命周期感知功用的重要性：

• 防止内存走漏：最重要的一点，在Android运用中，资源未被正确开释可能导致内存走漏。生命周期感知功用答应在恰当的机遇开释资源，例如在Activity或Fragment毁掉时中止后台使命、撤销网络恳求、开释Bitmap等，然后防止因资源未被及时回收而产生内存走漏。图片加载涉及到很多的内存操作，例如解码图片、缓存图片等。假如在加载图片时没有进行恰当的生命周期办理，可能会导致内存走漏。经过生命周期感知，图片加载库能够在Activity或Fragment被毁掉时主动中止图片加载并开释相关资源，防止了因未开释资源而产生的内存走漏问题。

• 优化资源办理：Android设备的资源（如内存和CPU）是有限的，特别是在较旧或低端的设备上。生命周期感知功用使得运用能够依据当时活动组件（如Activity或Fragment）的生命周期状况，有针对性地办理和开释资源，保证运用在资源运用方面更加高效。

• 防止不必要的核算和网络恳求：生命周期感知功用能够在用户不再需求某些数据时主动撤销相关的核算和网络恳求。这样能够减少后台资源的糟蹋，进步运用全体的功率。图片加载一般需求进行网络恳求或许本地IO操作，这些是耗时的使命。经过生命周期感知，图片加载库能够在后台履行图片加载使命，但在合适的机遇及时撤销使命，保证在页面毁掉时不会加载无用的图片，进步运用的功用和功率。

• 优化页面回退和导航：对于涉及页面回退和导航的运用场景，生命周期感知功用能够保证在页面不再可见或处于后台时，及时开释相关页面的资源，以防止资源冗余和糟蹋。

Glide如何完结生命周期感知

在Glide图片加载库中，经过将RequestManager与Activity或Fragment的生命周期相关起来，能够完结生命周期感知的图片加载操作。这种相关保证在Activity或Fragment的生命周期状况改变时，主动中止图片加载并开释相关资源，然后防止内存走漏和不必要的资源耗费。

要完结RequestManager与Activity或Fragment的生命周期相关，能够选用如下办法：

1. 与Activity相关：

在Activity中运用Glide时，一般在onCreate()办法中创立一个RequestManager目标，并将其与Activity进行相关。这样，在Activity生命周期的不同阶段，Glide会主动暂停或康复图片加载操作。

class MyActivity : AppCompatActivity() {
    private lateinit var glide: RequestManager
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // 创立Glide的RequestManager并与Activity相关
        glide = Glide.with(this)
        setContentView(R.layout.activity_my)
        // 加载图片等操作能够运用glide目标
        glide.load("").into(imageView)
    }
    // 其他Activity生命周期办法
    // ...
}

2. 与Fragment相关：

在Fragment中运用Glide时，一般在onCreateView()办法中创立一个RequestManager目标，并将其与Fragment相关。与Activity类似，这样Glide会依据Fragment的生命周期主动办理图片加载操作。

class MyFragment : Fragment() {
    private lateinit var glide: RequestManager
    override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? {
        val view = inflater.inflate(R.layout.fragment_my, container, false)
        // 创立Glide的RequestManager并与Fragment相关
        glide = Glide.with(this)
        // 加载图片等操作能够运用glide目标
        glide.load("").into(imageView)
        return view
    }
    // 其他Fragment生命周期办法
    // ...
}

经过以上的办法，Glide会在Activity或Fragment的生命周期中智能地暂停或康复图片加载操作，然后有效地办理资源，防止不必要的资源糟蹋和内存走漏。这种生命周期感知的图片加载办法是优化图片加载的重要手法，特别适用于需求加载很多图片或频频切换页面的场景。

了解RequestManager的概念

了解RequestManager的概念对于运用Glide图片加载库至关重要。在Glide中，RequestManager是一个担任办理图片加载恳求的关键组件。它充当了图片加载恳求的调度者和办理者，担任创立、处理和中止图片加载恳求，并与Activity或Fragment的生命周期进行相关，然后完结生命周期感知的图片加载。

要了解RequestManager的概念，能够将其比作一个加载图片恳求的”控制中心”，类似于一个办理者，能够向下托付详细的图片加载使命，向上感知和响应Activity或Fragment的生命周期改变。

首要特点和功用：

1. 创立和初始化： 在运用Glide加载图片之前，需求先创立一个RequestManager目标。能够经过Glide.with()办法传入Context、Activity或Fragment来获取相应的RequestManager实例。

2. 加载图片： 经过RequestManager目标，能够调用load()办法加载指定的图片资源。load()办法支撑各种类型的资源加载，包含网络图片、本地图片、资源文件、Uri等。

3. 图片变换和加载设置： RequestManager还供给了一系列办法，用于设置图片加载时的各种参数和选项，如图片变换、占位符、错误图片、缩略图、优先级等。

4. 生命周期感知： RequestManager与Activity或Fragment的生命周期相关，能够依据它们的生命周期状况主动中止或康复图片加载恳求，以优化资源办理和提高用户体会。

5. 清除资源： 在合适的机遇，能够调用clear()办法清除RequestManager中的一切图片加载恳求和资源，开释相关资源。

总的来说，RequestManager是Glide图片加载库中的一个关键组件，它在整个图片加载过程中起着重要的调度和办理效果。经过与Activity或Fragment的生命周期相关，RequestManager完结了生命周期感知的图片加载功用，保证在恰当的机遇中止加载和开释资源，然后优化图片加载的功用和资源办理。

RequestManager的创立

在Glide中，RequestManager是一个担任办理图片加载恳求的关键组件。它充当了图片加载恳求的调度者和办理者，担任创立、处理和中止图片加载恳求，并与Activity或Fragment的生命周期进行相关，然后完结生命周期感知的图片加载。

一般咱们在Activity或许Fragment中调用，Glide.with(this)，即可完结Glide的初始化，而咱们的RequestManager 也是在这个过程中完结创立，因而，咱们来看看with函数中做了什么：

@NonNull
public static RequestManager with(@NonNull FragmentActivity activity) {
  return getRetriever(activity).get(activity);
}
@NonNull
public static RequestManager with(@NonNull Fragment fragment) {
  return getRetriever(fragment.getContext()).get(fragment);
}
@NonNull
public static RequestManager with(@NonNull Context context) {
  return getRetriever(context).get(context);
}

Glide供给了多个静态办法with，实际上，区别只在于入参的不同，而返回值都是RequestManager实例，常用的首要是上面的第一和第二个，入参分别对应FragmentActivity activity / Fragment fragment，

不论是哪个静态办法，完结上基本一致，都是经过调用getRetriever办法获取到指定的RequestManagerRetriever，在经过RequestManagerRetriever获取到RequestManager，所以，这儿的RequestManagerRetriever 是什么呢？

简单来说 ，RequestManagerRetriever是RequestManager的创立和办理类。它内部保护了一个RequestManager缓存，依据传入的Context、Activity或Fragment，以及恳求类型（一般为Activity或Fragment）来查找或创立相应的RequestManager实例。每个运用一般只有一个大局的RequestManagerRetriever目标，用于办理一切的RequestManager实例

在获取到RequestManagerRetriever后，调用RequestManagerRetriever.get办法，获取指定的RequestManager （下文以Fragment为例）

@NonNull
public RequestManager get(@NonNull Fragment fragment) {
  Preconditions.checkNotNull(
      fragment.getContext(),
      "You cannot start a load on a fragment before it is attached or after it is destroyed");
  if (Util.isOnBackgroundThread()) {
    return get(fragment.getContext().getApplicationContext());
  }
  // In some unusual cases, it's possible to have a Fragment not hosted by an activity. There's
  // not all that much we can do here. Most apps will be started with a standard activity. If
  // we manage not to register the first frame waiter for a while, the consequences are not
  // catastrophic, we'll just use some extra memory.
  if (fragment.getActivity() != null) {
    frameWaiter.registerSelf(fragment.getActivity());
  }
  FragmentManager fm = fragment.getChildFragmentManager();
  Context context = fragment.getContext();
  Glide glide = Glide.get(context.getApplicationContext());
  return lifecycleRequestManagerRetriever.getOrCreate(
      context, glide, fragment.getLifecycle(), fm, fragment.isVisible());
}

get办法完结了以下几件事：

1. 检查当时的Fragment是否已经attach，或许是否处于destroyed状况；

2. 判断当时线程是否是后台线程，假如是的话，则获取applicationContext对应的RequestManager，这样做的原因是：在后台线程调用get()办法时，运用fragment.getContext()获取Context是不安全的，由于在**后台线程拜访****Context**可能会导致内存走漏或其他异常。

3. 调用frameWaiter.registerSelf(fragment.getActivity())，此处没了解它的效果；

4. 获取当时Fragment的childFragmentManager/ fragment地点context（也便是activity)/ 单例的Glide实例

5. 调用lifecycleRequestManagerRetriever.getOrCreate 完结RequestManager的获取。

lifecycleRequestManagerRetriever.getOrCreate

RequestManager getOrCreate(
    Context context,
    Glide glide,
    final Lifecycle lifecycle,
    FragmentManager childFragmentManager,
    boolean isParentVisible) {
  Util.assertMainThread();
  RequestManager result = getOnly(lifecycle);
  if (result == null) {
    LifecycleLifecycle glideLifecycle = new LifecycleLifecycle(lifecycle);
    result =
        factory.build(
            glide,
            glideLifecycle,
            new SupportRequestManagerTreeNode(childFragmentManager),
            context);
    lifecycleToRequestManager.put(lifecycle, result);
    glideLifecycle.addListener(
        new LifecycleListener() {
          @Override
          public void onStart() {}
          @Override
          public void onStop() {}
          @Override
          public void onDestroy() {
            lifecycleToRequestManager.remove(lifecycle);
          }
        });
    // This is a bit of hack, we're going to start the RequestManager, but not the
    // corresponding Lifecycle. It's safe to start the RequestManager, but starting the
    // Lifecycle might trigger memory leaks. See b/154405040
    if (isParentVisible) {
      result.onStart();
    }
  }
  return result;
}

getOrCreate办法中干了哪些事呢？

1. 假如依据fragment的lifecycle获取不到RequestManager实例，则需求新建RequestManager实例，这儿也阐明RequestManager存在简单的缓存机制；
2. 当缓存中不存在相应的RequestManager时，新建LifecycleLifecycle目标glideLifeCycle，该目标完结了Lifecycle 接口的相关办法，接着运用工厂模式，经过RequestManagerFactory新建一个RequestManager；

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

3. 在新建RequestManager 实例完结后，将fragment.getLifeCycle作为key， 新建的RequestManager 实例为value放入Map缓存；
4. 为glideLifeCycle添加生命周期监听，在onDestroy的时侯，将Map中的缓存移除；
5. 当Fragment可见时，调用RequestManager的onStart办法，在onStart()办法中，首要会调用requestTracker.resumeRequests()办法，该办法会发动图片加载恳求，另外调用targetTracker.onStart()，告诉targetTracker，当时组件的生命周期已经变为STARTED，因而能够对之前暂停的Target进行康复加载操作。

targetTracker是RequestManager内部的一个TargetTracker目标，担任办理当时RequestManager中一切图片加载的Target（一般是ImageView或自定义的Target完结）

RequestManager类的扼要剖析

结构函数

首要让咱们剖析一下RequestManager的结构函数：

public RequestManager(
      @NonNull Glide glide,
      @NonNull Lifecycle lifecycle,
      @NonNull RequestManagerTreeNode treeNode,
      @NonNull Context context) {
    this(
        glide,
        lifecycle,
        treeNode,
        new RequestTracker(),
        glide.getConnectivityMonitorFactory(),
        context);
  }

该结构函数接受以下参数：

1. glide：Glide的实例，是大局的Glide单例，用于办理图片加载恳求和资源等。

2. lifecycle：表明组件（一般是Activity或Fragment）的生命周期状况，用于完结生命周期感知的图片加载。

3. treeNode：表明一个可选的RequestManager树结构节点，用于安排和办理RequestManager之间的联系。

4. context：组件的Context，一般是Activity或Fragment的Context。

在结构函数中，它会调用另一个私有的结构函数来完结RequestManager的初始化。

private 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;
    connectivityMonitor =
        factory.build(
            context.getApplicationContext(),
            new RequestManagerConnectivityListener(requestTracker));
    // 监听组件的生命周期，依据生命周期状况主动处理图片加载恳求
    lifecycle.addListener(this);
  }

在私有结构函数中，它完结了以下操作：

1. 将传入的参数赋值给类的成员变量。
2. 经过ConnectivityMonitorFactory创立一个connectivityMonitor，用于监听网络连接状况，以便在恰当的时分暂停或康复图片加载恳求。
3. 经过lifecycle.addListener(this)将当时RequestManager实例注册为生命周期监听器，以便在组件的生命周期改变时触发相应的回调办法。

经过调用lifecycle.addListener(this)，RequestManager完结了生命周期感知，并能够依据组件的生命周期状况主动办理图片加载恳求，然后优化资源办理和图片加载的功用。

总结：RequestManager的结构函数用于创立RequestManager实例并初始化其成员变量。经过传入Glide实例、生命周期目标和Context等参数，RequestManager能够与Glide和组件的生命周期相关起来，完结生命周期感知的图片加载和资源办理。

成员变量

在Glide的RequestManager类中，有多个成员变量，这些成员变量在图片加载的整个过程中起到重要效果。它们与Glide、组件的生命周期、图片加载恳求跟踪和网络连接状况监视器等相互配合，完结了生命周期感知的图片加载和资源办理，以优化图片加载的功用和用户体会。

RequestManager在不同生命周期的处理

RequestManager在不同生命周期状况下会依据组件的生命周期改变履行不同的操作。它能够依据组件的生命周期状况来办理图片加载恳求和资源，优化图片加载的功用和资源办理。经过生命周期感知的机制，Glide能够在恰当的机遇主动处理图片加载恳求，防止不必要的资源糟蹋和内存走漏。

RequestManager在不同生命周期状况下会依据组件（一般是Activity或Fragment）的生命周期改变履行不同的操作。下面是RequestManager在不同生命周期状况下可能会履行的一些操作：

1. onStart() ：

   1. 发动网络连接监听：在onStart()办法中，RequestManager会发动网络连接监听器（假如已注册）。这样，当网络连接康复时，Glide能够主动康复之前因网络断开而暂停的图片加载恳求，进步图片加载的功率。

   2. 康复图片加载恳求：RequestManager会调用requestTracker.resumeRequests()办法，康复之前因暂停而被中止的图片加载恳求。当组件的生命周期状况从STOPPED切换到STARTED时，会触发onStart()办法，然后完结对之前暂停的图片加载恳求的康复。

2. onStop() ：

   1. 中止图片加载恳求：在onStop()办法中，RequestManager会调用requestTracker.pauseRequests()办法，暂停一切图片加载恳求。当组件的生命周期状况变为STOPPED时，RequestManager会暂停一切图片加载恳求，防止在组件不行见时继续加载图片，节约资源和带宽。

3. onDestroy() ：

   1. 撤销图片加载恳求：在onDestroy()办法中，RequestManager会调用requestTracker.clearRequests()办法，撤销一切未完结的图片加载恳求。这样，能够防止在组件被毁掉时依然加载图片，防止资源糟蹋和内存走漏。

总结

• Glide是一个强大的图片加载库，其中重要的一方面便是完结了页面生命周期的监听，然后完结了生命周期感知的图片加载和资源办理，优化图片加载的功用和用户体会
• 生命周期感知的重要效果首要包含防止内存走漏/优化资源办理/防止不必要的核算和网络恳求等；
• Glide中首要经过RequestManager完结与Fragment/Activity等的相关，监听其页面的生命周期，并经过RequestManagerRetriever 进行RequestManager实例的办理