Glide分析和总结

1. Glide概述

• Glide是一款图片处理的框架，从框架设计的角度出发，最基本要实现的就是 加载图片 和 展示。

1. 它把一个图片请求封装成一个Request对象，里面有开启、暂停、关闭、清除网络请求、以及载体生命周期的监听等操作。
2. 然后通过RequestBuilder来创建请求，通过它传入各种各样的参数，回调监听，加载失败后的设置等等。
3. 最终还要创建一个RequestManager进行统一的管理。（因为请求肯定不可能只有一个，比如开始、暂停、关闭、清除请求等操作。）
4. 完成某个请求后，再通过ImageViewTarget设置给图片控件。

2. Glide的用法

2.1 使用Glide

1. 导入依赖

implementation 'com.github.bumptech.glide:glide:4.15.1'

2. 加载网络地址资源

ImageView image1 = findViewById(R.id.image_1);

Glide.with(this)
        .load("https://pic.ntimg.cn/file/20200605/23605973_173021196899_2.jpg")
        .fitCenter()
        .into(image1);

3. 加载Drawable资源

Glide.with(this)
        .load(R.drawable.draw_shape1)
        .placeholder(R.drawable.draw_shape2)
        .error(R.drawable.draw_shape2)
        .into(image1);

4. 从Uri中加载资源

Uri uri = Uri.parse("android.resource://" + getPackageName() + "/" + R.drawable.ic_launcher);
tv_title3.setText("从 Uri 中加载");        
Glide.with(this)
    .load(uri)                
    .placeholder(R.drawable.ic_launcher)                
    .error(R.mipmap.ic_launcher_round)                
    .dontAnimate() //加载没有任何动画                
    .into(iv_3);

2.2 Glide相关方法

1. 占位符 placeholder()：在图片资源未加载完成时，占位符会在ImageView里面显示
2. 错误占位符 error()：在图片资源加载失败时，占位符会在Imageview里显示 还有一个就是错误占位符，error()接受的参数只能是已经初始化的 drawable 对象或者指明它的资源(R.drawable.)。
3. 图片淡入动画属性 crossFade()：动态图的添加
4. dontAnimate()：直接显示图片，没有淡入淡出的效果。
5. 缩放图像 centerCrop()：是一个裁剪技术，即缩放图像让它填充到 ImageView 界限内并且裁剪额外的部分。ImageView 可能会完全填充，但图像可能不会完整显示。
6. 缩放图像 fitCenter()：是裁剪技术，即缩放图像让图像都测量出来等于或小于 ImageView 的边界范围。该图像将会完全显示，但可能不会填满整个 ImageView。

• 也可以加载GIF图像，只需要load的是GIF图片的链接即可。

7. asBitmap()：如果GIF图片太大，导致OOM异常。那么通过asBitmap()可以转成常规图片

3. Glide图片加载流程

• Glide.get(context)方法中对Glide类上锁

Glide.with(this)
    .load(uri)                            
    .into(iv_3);

3.1 with()

• 主要进行一些Glide的初始化工作，以及将context生命周期注入Glide。

1. 会创建Bitmap池、内存缓存、磁盘缓存和Glide对象。
2. 最主要的任务是通过传入的参数类型来获取RequestManager对象。
   

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

3.2 load()

• 根据需要 加载资源，完成一些参数的配置。

1. 比如从url、uri、文件获取等等
2. 还会创建一个RequestBuilder对象，创建一个目标为Drawable的图片加载请求。

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

3.3 into()

• into()方法的作用就是从缓存或者网络上获取图片资源，并且将图片进行解析展示。

//RequestBuilder.into()
public ViewTarget<ImageView, TranscodeType> into(@NonNull ImageView view) {
     .....
        //返回ViewTarget对象
    return into(
            //glideContext为GlideContext类型
        glideContext.buildImageViewTarget(view, transcodeClass),
        targetListener = null,
        requestOptions,
        //含有绑定主线程Handler的线程池
        Executors.mainThreadExecutor());
}

• 准备过程

  1. 首先根据传入View的缩放类型 设置 一个裁剪策略，配置相应的requestOptions（存配置）
  2. requestOptions里面保存着所有RequestManager中的配置。（缓存策略、裁剪大小、动画效果、优先级…）
  3. 接着调用这些配置去创建一个Request对象
  4. 并将View包装成ViewTarget传入Request（将Request和ViewTarget绑定起来）

• 调用方法执行request

  • 开始加载之前，要先判断Glide对应的生命周期是否处于暂停？
  1. 如果没暂停。判断传入的URL是否为null。
  2. 如果为null则抛出异常，然后使用占位图显示在目标位置。
  3. 不为null，判断是否设置了宽高。没有设置则测量出宽高
  4. 最后调用Engine的load方法真正开始加载的逻辑。

• 加载的过程

  1. Engine的load方法会先创建出一个EngineKey
  • 先从内存缓存中寻找图片
  2. 查看弱引用HashMap中有没有，获取到则回调并将图片资源展示出来
  3. 没找到则去LruCache中获取，获取到则将它从LruCache中删除，放入到弱引用HashMap中并显示回调。
  • 都没有的话，则去磁盘缓存中寻找。
  4. 去磁盘缓存DiskLruCache中寻找。
  5. 如果还是拿不到，就发起网络请求获取图片资源。

• 资源的解析和图片显示过程

  1. 从网络请求获取到图片资源后，要生成一个对应的Bitmap
  2. 生成之前会先去Bitmap缓存池中查找是否有等大的Bitmap，如果有则直接复用。
  3. 没有的话就创建一个，然后将该Bitmap放到缓存池，以便下一次复用。
  4. 并且把数据 根据磁盘缓存策略 存储到 硬盘缓存DiskLruCache中
  5. 最后将数据存到弱引用HashMap中，并回调显示。

4. Glide缓存机制

• Glide的缓存都通过一个key来实现。（也就是EngineKey对象）
• EngineKey：通过请求的URL、View的宽高、屏幕的尺寸大小、请求的签名等等生成这个key。（获取缓存之前都会先创建这个EngineKey）
• EngineKey就是判定是否可以实现图片复用的依据。

4.1 Glide的缓存分类

• Glide的缓存分为内存缓存和磁盘缓存

1. 内存缓存：弱引用缓存HashMap 和 LruCache。（分为取缓存和存缓存两方面来说明）
2. 磁盘缓存：DiskLruCache

4.2 取缓存（加载图片的过程）

• 取缓存顺序：弱引用HashMap -> LruCache -> DiskLruCache -> 找不到通过HttpUrlConnection新建网络请求去获取图片。

1. 先去弱引用HashMap中获取
   • 成功，则将它的acquired引用计数+1。
   • 失败，则这个缓存可能被GC，从HashMap中将其移除。
2. 然后去LruCache中寻找
   • 成功，将缓存从LruCache中移除，并将其加入到弱引用缓存HashMap中，并将其acquired+1。
   • 失败，返回null
3. 去硬盘缓存DiskLruCache中寻找
   • 成功，先找转码后的图片，再找原图。
   • 失败，网络请求
4. 通过HttpUrlConnection新建网络请求去获取图片
   • 成功，将图片缓存到磁盘和内存中，以便后续复用。

4.3 存缓存

1. 关于弱引用HashMap
   • 获取到图片资源后，将其存到弱引用缓存中，回调到主线程显示图片资源。
   1. 如果弱引用缓存中某个缓存的acquire计数渐渐变为0，那么将它从HashMap弱引用中移除（唯一特殊的地方）
   2. 如果允许内存缓存的话，加入到LruCache中。
2. 关于LruCache
   • 如果从LruCache中获取成功的话，将缓存从LruCache中移除，并将其加入到弱引用缓存HashMap中，并将其acquired+1。
3. 关于硬盘缓存DiskLruCache
   • 在网络请求后如果有结果，则必然会存入到硬盘中。不过会判断是否允许缓存原始图片。
     1. 允许就缓存原图
     2. 不允许就缓存转码后的图

• Glide的磁盘缓存策略默认情况下会根据加载图片的来源类型采用最佳的缓存策略。
• diskCacheStrategy设置的缓存模式既影响读取，也影响存储。是在衡量所占磁盘空间大小和获取图片的成本两者所做的一个居中选择。如果加载的是远程图片，仅会存储原始图片，不存储转换过后的图片，因为下载远程图片相比调整磁盘上已经存在的数据要昂贵得多。如果加载的是本地图片，则仅会存储转换过后的图片，因为即使需要再次生成另一个尺寸或类型的图片，取回原始图片也很容易。

• Glide最终缓存到磁盘的图片类型：原始图片和将原始图片进行压缩裁剪变化等各种转换操作后得到的图片。
  

4.4 为什么使用弱引用缓存？

5. 内存清理机制

• Glide提供了缓存内存的自动清理机制。
• Glide初始化的时候会默认向Application注册一个监听器，用于接收系统下发的内存状态变化的事件通知，当接收到后，会自动触发对 memoryCache、bitmapPool 和 arrayPool 的清理工作。

6. 图片框架

6.1 设计一个图片请求框架

• 一款图片处理的框架，从框架设计的角度出发，最基本要实现的就是 加载图片 和 展示。

1. 把一个图片请求封装成一个Request对象，里面有开启、暂停、关闭、清除网络请求、以及载体生命周期的监听等操作。
2. 然后通过RequestBuilder来创建请求，通过它传入各种各样的参数，回调监听，加载失败后的设置等等。
3. 最终还要创建一个RequestManager进行统一的管理。（因为请求肯定不可能只有一个，比如开始、暂停、关闭、清除请求等操作。）
4. RequestManager除了统一管理Request以外，还要作为监听生命周期的载体。（根据生命周期对Request做出相应的操作）
5. 初始化完Request、Request和生命周期监听等，我们就可以执行具体的获取图片请求了，如果每次都从网络上获取，会导致网络资源的浪费，万一网络不好，还要加载很久 所以还需要设计一个缓存机制。
6. 比如内存缓存，磁盘缓存，Bitmap池缓存等。对于内存缓存，我们可以用现在比较成熟的LRUcache，把最新使用过的图片简单缓存，加载图片显示时先去内存缓存找，找不到再去磁盘缓存找，如果还是没有，再进行网络请求。获取到图片后，再更新到对应的缓存区
7. 获取到图片后，设计剪裁策略、动画效果等，如果有等大的Bitmap还可以复用Bitmap池里的，再设计一个ImageViewTarget模块 把图片设置到对应的控件上。

6.2 图片加载库

• Android目前主流的图片加载库包括Glide、Picasso和Fresco。

1. Glide：由 Google 开源的一个图片加载库，是一款快速高效的 Android 开源媒体管理和图像加载框架，它将媒体解码，内存和磁盘缓存以及资源池包装成简单易用的接口
   • 优点：
     • 支持多样化媒体加载。它支持 Gif、WebP、缩略图，甚至是 Video。生命周期集成，高效的缓存策略。
   • 缺点：
     • 使用方法复杂，实现方法较多。使用较 Fresco 简单，但性能（加载速度 & 缓存）却比不上 Fresco。
2. Fresco：由 Facebook 开源的用于管理图像及其使用内存的 Android 库
   • 优点：
     • 大大减少了 OOM 的发生，Facebook 在底层使用了 C++ 技术解决图片缓存问题
     • 几乎全部功能都能在 XML 文件中直接制定
   • 缺点：
     • 使用方法复杂
     • 依赖包大(2-3M)
3. Picasso：由 Square 公司开源的一个适用于 Android 的强大图像下载和缓存库
   • 优点：
     • 使用简单，代码简洁
     • 与 Square 公司的其他开源库如 Retrofit 或者 OkHttp 搭配使用兼容性会更好些
   • 缺点：
     • 功能较为单一
     • 自身无实现 本地缓存
     • 不支持 Gif

7. 相关问题

7.1 为什么使用Glide？

7.2 Glide的缓存机制是什么样的？

• 上文取缓存、存换存的过程。

7.3 Glide是如何管理生命周期的？

• 主要进行一些Glide的初始化工作，以及将context生命周期注入Glide。
  

那么，不管 ImageView 的载体是 Activity 还是 Fragment，我们都可以向其注入一个无 UI 界面的 SupportRequestManagerFragment，以此来监听载体在整个生命周期内活跃状态的变化

7.4 如果图片资源变了，url没有变怎么处理？

• Glide取缓存的key是基于请求的url的，请求的签名、Imageview的宽高等参数。如果这些都相同，那么下次获取图片的时候就先去缓存中找。这样有一个问题就是我们图片资源换了，但是没有换url，那么获取图片的时候是有可能获取到之前缓存中的旧图片，这样就出现了问题。