「Glide」源码解析系列

• 「Glide」一切的开始
• 「Glide」目标的确定
• 「Glide」中的跟踪者
• 「Glide」请求的生成
• 「Glide」请求的开始
• 「Glide」中的Engine
• 「Glide」中的Job

承前启后

RequestBuilder

目标target确定了，也将request绑定其上了，且target和request都有各自的跟踪者管控着。

唉！关键的request怎么生成的？？

这节就来看看Request是从何而来的

此节涉及到的类有
SingleRequest
Pools
SimplePool
FactoryPools

Request的产生

RequestBuilder

若target之前绑定过request【非ListView、RecyclerView复用view的场景，通过into(View)方法进入的target都是new出来的；通过其他into方法进入的情况才会触发】，需要对比新旧request是否相同

• 蓝框的逻辑
  新旧request相同的情况下，且旧request有图片内存缓存配置但是没有加载完成，这时回收掉新request。旧request不空且未正在执行时（暂停状态），重新启动旧request

未绑定过则通过buildRequest构造者模式方法生成

RequestBuilder RequestBuilder

buildRequestRecursive方法生成了两个Request：mainRequest、errorRequest，errorRequest的生成使用了递归

只有在手动设置errorBuilder的情况下才会触发生成errorRequest的逻辑，当mainRequest加载失败时ErrorRequestCoordinator就会启动errorRequest执行。

因为没有手动设置errorBuilder我们进入下个方法buildThumbnailRequestRecursive

buildThumbnailRequestRecursive

跳过部分：【类似buildRequestRecursive方法，若设置了thumbnailBuilder、thumbSizeMultiplier参数，则会生成Coordinator对象控制request的请求】

直接返回obtainRequest

RequestBuilder

Request的复用

Request由SingleRequest的静态方法生成

SingleRequest

先去POOL中取，取不到则新建对象

SingleRequest

Pools

Pools

Pools是个final类，关键的接口是Pool，泛型T标识池内对象类型，acquire获取池内对象，release释放对象

Pools

SimplePool是接口Pool的实现类，内部采用数组存储对象，若数组内有对象则返回，减少了新建对象的开销

Pools

SynchronizedPool在SimplePool的基础上加了同步锁

FactoryPools

存放SingleRequest对象的池子为FactoryPools

SingleRequest FactoryPools FactoryPools FactoryPools

一步步下来，相比SimplePool多了两个参数

• factory 获取不到对象时，通过factory工厂产生
• resetter 释放对象时，通过resetter重置对象

FactoryPools

其内部存储对象的池子实际还是SimplePool

蓝色框部分则是标识此request是否被回收

无论是复用还是新建，到此Request对象就有了

SingleRequest

将RequestBuilder传入的参数，设置给Request，并返回

总结

request对象的类型为SingleRequest，其产生是通过SingleRequest的静态方法。

静态方法内是通过工具类FactoryPools来对多个request进行复用的，并设置StateVerifier来标识request的状态