Glide源码分析-概述

基本概念

项目地址：https://github.com/bumptech/glide
基于Glide当前的稳定版本3.7.0

基本流程

glide_process

大的流程与其他的图片加载库没有本质区别，都是构建一个图片加载请求，然后通过Engine先从内存缓存中获取数据，如果命中缓存则直接回调主线程并对View层进行对应处理；如果未命中缓存，则调起一个DecodeJob请求原始数据，先请求磁盘缓存，未命中则进行网络请求，最终将结果回调主线程。

类设计图

glide_class

主要组件的概念

Glide 入口类

Glide

  • 向外暴露单例静态接口，通过传入的Context构建RequestManager
  • 持有一些内存变量BitmapPool，MemoryCache，便于外界调用清理缓存
  • 同时在构造方法里完成GenericLoaderFactory、TranscoderRegisty和DataLoaderRegisty对多种数据和资源类型的注册（这几个类的作用后面分析）

GlideBuilder

  • 构建Glide对象，配置默认的缓存策略和图片解码格式

RequestManager 请求管理类

RequestManager

  • 通过load系列方法，构建具体的请求
  • 通过持有的RequestTracker对象管理当前RequestManager下所有请求的生命周期

RequestTracker

  • 对具体请求的行为进行管理

RequestManagerRetriever

  • 单例，通过传入的Context或Fragment获取对应的RequestManager

Request 请求类

  • 持有一个具体请求的所有信息，包括所有主动行为和状态的回调，通过Engine进行具体的数据请求，同时将回调结果通知Target

Engine 引擎类

Engine

  • 请求数据并拿到回调结果
  • 请求数据分为三步：先请求内存缓存MemoryCache，未命中则继续请求activeResources（具体会在缓存部分分析），仍然未命中则会调起一个EngineRunnable，开启一个线程进行具体请求

EngineRunnable

  • 实现了Runnable接口，用DecodeJob进行数据请求并将回调传递给EngineJob

EngineJob

  • 管理对应Engine所有请求的ResourceCallback

DecodeJob 原始对象处理类

DecodeJob

  • 进行具体取数据和数据转换的操作，包括从磁盘缓存和通过网络请求拿到原始数据，并将原始数据通过ResourceDecoder、Transformation和ResourceTranscoder转换成最终Target需要的数据类型
  • 在通过网络请求拿到数据后也进行了写入磁盘缓存的操作

Cache缓存部分

MemoryCache内存缓存接口

  • 资源被释放时写入，在Engine类里从内存中获取数据时查询

DishCache磁盘缓存接口

  • DecodeJob从磁盘中获取数据时查询，请求网络拿到原始数据时写入

BitmapPool接口

  • 设计思路是根据尺寸和属性缓存理论上会被重复使用的Bitmap对象，在有新的加载过程要用到同样的Bitmap时避免重复创建Bitmap,在RecyclerView这种会有大量可复用的相同尺寸和属性Bitmap的场景下效果明显
  • 在Transformation中构建Bitmap时查询，在任意位置的Bitmap对象准备被释放时缓存

Engine中的activeResources

  • 这是一个弱引用的内存缓存，当MemoryCache中的缓存因为某些情况被remove掉时，会再在这个内存缓存里查询到，不会对使用中的Bitmap造成影响

可扩展接口

ModelLoader和对应的DataFetcher

  • 可以配置自己的网络请求和数据类型

Transformation接口

  • 可以配置自己的Bitmap或者其他类型数据的处理方案，默认的centerCrop()和fitCenter方法都是实现了具体的Transformation接口

Target接口

  • 可以配置更复杂的View或其他业务层组件，Glide负责管理请求、缓存和数据转换。

Glide主要的类和接口基本就是这些，通过这些接口的关系我们已经基本能知道Glide进行一次完成的图片数据请求以及加载到View的过程了。