五大拦截器

0. 应用拦截器一定会被执行一次

1. RetryAndFollowUpInterceptor

重试重定向拦截器这个拦截器是一个while(true)的循环，只有请求成功或者重试超过最大次数，没有路由供重试时才会退出

请求抛出异常并满足重试条件时才重试，收到3xx，需要重定向时会重新构建请求

2. BridgeInterceptor

将http request加工，添加header 头字段（Connection:keep-alive,Accept-Encoding：Gzip），再将http response 加工去掉 header

3. CacheInterceptor

缓存拦截器

从DiskLruCache根据请求url获取缓存Response，然后根据一些http头约定的缓存策略决定是使用缓存响应还是发起新的请求。

只缓存 get 请求

缓存是空间换时间的方法，缓存需要页面置换算法（LRU,FIFO）

缓存减小服务器压力，客户端更快地显示数据，无网下显示数据

缓存分为强制缓存和对比缓存

客户端直接拿数据，若缓存未命中则请求网络并更新数据

客户端拿数据标识，总是查询网络判断数据是否有效

响应头中包含Cache-Control：max-age，表示缓存过期时间

响应头中有Last-Modified字段标识资源最后被修改时间，客户端下次发起请求时在请求头中会带上If-Modified-Since，服务器比对如果最后修改时间大于该值则返回200，否则304标识缓存有效。

除了用最后修改时间做判断，还可以用资源唯一标识来判断ETag/If-None-Match，响应头包含ETag，再次请求时带上If-None-Match，服务器比对标识是否相同，相同则304，否则200

缓存策略：先判断缓存是否过期，若未过期则直接使用，若过期则发起请求，请求头带唯一标识，服务器回200或304，如果没有唯一标识则请求头带上次修改时间，服务器200或304

在无网环境下即是缓存过期，依然使用缓存，要添加应用拦截器，重构request修改cache-control字段为FORCE_CACHE:

public class ForceCacheInterceptor implements Interceptor {
    @Override
    public Response intercept(Chain chain) throws IOException {
        Request.Builder builder = chain.request().newBuilder();
        if (!NetworkUtils.internetAvailable()) {
            builder.cacheControl(CacheControl.FORCE_CACHE);
        }
        return chain.proceed(builder.build());
    }
}
okHttpClient.addInterceptor(new ForceCacheInterceptor());

若服务器不支持header头缓存字段，则可以添加网络拦截器，在CacheInterceptor收到响应之前修改response的header

public class CacheInterceptor implements Interceptor {
    @Override
    public Response intercept(Chain chain) throws IOException {
        Request request = chain.request();
        Response response = chain.proceed(request);
        Response response1 = response.newBuilder()
                .removeHeader("Pragma")
                .removeHeader("Cache-Control")
                //cache for 30 days
                .header("Cache-Control", "max-age=" + 3600 * 24 * 30)
                .build();
        return response1;
    }
}

4. ConnectInterceptor

连接拦截器

建立连接及连接上的流

维护连接池，以复用连接

一个物理链接上有多个流（逻辑上的请求响应对），一个物理链接上的多个流是并发的，但有数量限制，一个流上有多个分配，分配是并发的

获取连接流程：

复用已分配的连接（重定向再次请求）

无已分配链接，则从链接池那一个新得链接，通过主机名和端口（并不是池中的链接就能复用，除了host之外的字段要都相等，比如dns，协议，代理）

尝试其他路由再从连接池中获取连接，若找到则进行dns查询

如果缓存池中没有链接，则新建链接（tcp+tls握手，sockect.connect+connectTls），这是耗时的，过程中可能有连接池可能有新的可用连接所以再次尝试从连接池获取连接，如果成功则释放刚建立的链接，否则把新建连接入池

连接复用

tcp连接建立需要三次握手和四次挥手

连接池实现链接缓存，实现同一地址的链接复用

连接池以队列方式存储链接ArrayDeque，链接池中同一个地址最多维护5个空闲链接，空闲链接最多存活5分钟

连接清理

五分钟定时任务，每五分钟遍历所有链接，并找到其中空闲时间最长的，如果空闲时间超过keep-alive（5分钟），或者空闲链接超过了阈值（5个）则清除这个链接

4.x NetworkInterceptor

网络拦截器

在连接建立完成和发送请求之间

可能不被调用，比如缓存命中，或者多次调用重定向

5. CallServerInterceptor

请求拦截器

将请求和响应分装成 http2 的帧，通过Http2ExchangeCodec（内部通过okio实现io）

1 写入请求头 - 2 写入请求体 - 3 读取响应头 - 4 读取响应体如果响应头中 Connection:close，则在当前链接上设置标志位，表示该链接不能再被复用

RealCall

如何检测重复请求：使用一个 AtomicBoolean 作为请求过的标志位，每次执行 execute之前就会检查

如何发起请求：

请求被封装成 RealCall 对象，异步请求会进一步会封装成一个 Runnable

同步请求直接将请求在拦截器责任链上传递（并加到同步请求队列汇总）

异步请求会缓存到一个准备请求队列中，并检查当前并发请求数（同一个域最多5个并发，不同域最多64个），若未超阈值，则将请求出队入线程池执行（将请求在责任链上传递）同一链接上的最大并发数据流是Int.max

请求如何在责任链上传递

责任链持有一组拦截器和当前拦截器索引，通过每次复制一条新责任链且索引+1，实现传递发起请求并获取响应就是在请求和响应在责任链上u型传递的过程

Glide

特点

会根据控件大小进行下采样，以解码出符合需求的大小，对内存更友好

内存缓存+磁盘缓存

感知生命周期，取消任务，防止内存泄漏

感知内存吃紧，进行回收

BitmapPool，防止内存抖动的进行bitmap变换

定义请求优先级

手写一个图片库注意事项

获取资源：异步并发下载图片，最大化利用cpu资源

资源解码：按实际需求异步解码，多线程并发是否能加快解码速度

资源变换：使用资源池，复用变换的资源，避免内存抖动

缓存：磁盘缓存原始图片，或变换的资源。内存缓存刚使用过的资源，使用lru策略控制大小

感知生命周期：避免内存泄漏

感知内存吃紧：清理缓存

Glide 数据加载流程

RequestBuilder 构建 Request和 Target，将请求委托给RequestManager，RequestManager触发Request.begin(),然后调用Engine.load()加载资源，若有内存缓存则返回，否则启动异步任务加载磁盘缓存，若无则从网络加载

DecodeJob 负责加载数据（可能从磁盘，或网络，onDataFetcherReady），再进行数据解码（onDataFetcherReady），再进行数据变换（Transformation），写ActiveResource，（将变换后的数据回调给Target），将变换后的资源写文件（ResourceEncoder）

预加载

preload，加载到一个PreloadTarget，等资源加载好了，就调用clear，将资源从ActiveResource移除存到Lrucache中

感知内存吃紧

注册ComponentCallbacks2，实现细粒度内存管理：

onLowMemory(){清除内存}

onTrimMemory(){修剪内存}

    memoryCache.trimMemory(level); // 内存缓存
    bitmapPool.trimMemory(level); // bitmap池
    arrayPool.trimMemory(level); // 字节数组池

可以设置在onTrimMemory时，取消所有正在进行的请求。

BitmapPool

BitmatPool 是 Glide 维护了一个图片复用池，LruBitmapPool 使用 Lru 算法保留最近使用的尺寸的 Bitmap。

api19 后使用bitmap的字节数和config作为key，而之前使用宽高和congif，所以19以后复用度更高

用类似LinkedHashMap存储，键值对中的值是一组Bitmap，相同字节数的Bitmap 存在一个List中（这样设计的目的是，将Lru策略运用在Bitmap大小上，而不是单个Bitmap上），控制BitmapPool大小通过删除数据组中最后一个Bitmap。

BitmapPool 大部分用于Bitmap变换和gif加载时

ArrayPool

是一个采用Lru策略的数组池，用于解码时候的字节数组的复用。

清理内存意味着清理MemoryCache，BitmapPool,ArrayPool

缓存

默认情况下，Glide 会在开始一个新的图片请求之前检查以下多级的缓存：

活动资源 (Active Resources) - 现在是否有另一个 View 正在展示这张图片？

内存缓存 (Memory cache) - 该图片是否最近被加载过并仍存在于内存中？

资源类型（Resource） - 该图片是否之前曾被解码、转换并写入过磁盘缓存？

数据来源 (Data) - 构建这个图片的资源是否之前曾被写入过文件缓存？

在 Glide v4 里，所有缓存键都包含至少两个元素活动资源，内存缓存，资源磁盘缓存的缓存键还包含一些其他数据，包括：必选：Model 可选：签名宽度和高度可选的变换（Transformation）额外添加的任何选项(Options) 请求的数据类型 (Bitmap, GIF, 或其他)

磁盘缓存策略

如果缓存策略是AUTOMATIC（默认），对于网络图片只缓存原始数据，加载本地资源是存储变换过的数据，如果加载不同尺寸的图片，则会获取原始缓存并在此基础上做变换。

如果缓存策略是ALL，会缓存原始图片以及每个尺寸的副本，

如果缓存策略是SOURCE,只会缓存变换过的资源，如果另一个界面换一个尺寸显示图片，则会重新拉取网络可通过自定义Key实现操控缓存命中策略（混入自己的值，比如修改时间）

内存缓存

内存缓存分为两级

活跃图片 ActiveResource

使用HashMap存储正在使用资源的弱引用

资源被包装成带引用计数的EngineResource，标记引用资源的次数（当引用数不为0时阻止被回收或降级，降级即是存储到LruCache中）

这一级缓存没有大小限制，所以使用了资源的弱引用

存：每当下载资源后会在onEngineJobComplete()中存入ActiveResource，或者LruCache命中后，将资源从中LruCache移除并存入ActiveResource。
取：每当资源释放时，会降级到LruCache中（请求对应的context onDestroy了或者被gc了）

开一个后台线程，监听ReferenceQueue，不停地从中获取被gc的资源，将其从ActiveResource中移除，并重新构建一个新资源将其降级为LruCache
ActiveResource是为了缓解LruCache中缓存造成压力，因为LruCache中没有命中的缓存只有等到容量超限时才会被清除，强引用即使内存吃紧也不会被gc，现在当LruCache命中后移到ActiveResource，弱引用持有，当内存吃紧时能被回收。

LruCache

使用 LinkedHashMap 存储从活跃图片降级的资源，使用Lru算法淘汰最近最少使用的

存：从活跃图片降级的资源（退出当前界面，或者ActiveResource资源被回收）

取：网络请求资源之前，从缓存中取，若命中则直接从LruCache中移除了。

内存缓存只会缓存经过转换后的图片

内存缓存键根据10多个参数生成，url，宽高

磁盘缓存

会将源数据或经过变换的数据存储在磁盘，在内存中用LinkedHashMap记录一组Entry，Entry内部包含一组文件，文件名即是key，并且有开启后台线程执行删除文件操作以控制磁盘缓存大小。

写磁盘缓存即是触发Writer将数据写入磁盘，并在内存构建对应的File缓存在LinkedHashMap中

根据缓存策略的不同，可能存储源数据和经过变换的数据。

感知生命周期

构造RequestManager时传入context，可以是app的，activity的，或者是view的
向界面添加无界面Fragment（SupportRequestManagerFragment），Fragment把生命周期传递给Lifecycle，Fragment持有RequestManager，RequestManager监听Lifecycle，RequestManager向RequestTracker传递生命周期以暂停加载，RequestTracker遍历所有正在进行的请求，并暂停他们（移除回调resourceReady回调）

当绑定context destroy时，RequestManager会将该事件传递给RequestTracker，然后触发该请求Resource的clear，再调用Engine.release，将resource降级到LruCache
通过HashMap结构保存无界面Fragment以避免重复创建

取消请求

通过移除回调，设置取消标志位实现：无法取消已经发出的请求，会在DecodeJob的异步任务的run()方法中判断，如果cancel，则返回。移除各种回调，会传递到DataFetcher，httpUrlConnection 读取数据后会判断是否cancel，如果是则返回null。并没有断开链接

感知网络变化

通过 ConnectivityManager 监听网络变化，当网络恢复时，遍历请求列表，将没有完成的任务继续开始

Transformation

所有的BitmapTransformation 都是从BitmapPool 拿到一个bitmap，然后将在原有bitmap基础上应用一个matrix再画到新bitmap上。

变换也是一个key，用以在缓存的时候做区别

RecycleView图片错乱

异步任务+视图复用导致

解决方案：设置占位图+回收表项时取消图片加载（或者新得加载开始时取消旧的加载）+imageview加tag判断是否是自己的图片如果不是则先调用clear

Glide 缓存失效

是因为 Key 发生变化，Url是生成key的依据，Url可能发生变化比如把token追加在后面

自定义生成key的方式，继承GlideUrl重写getCacheKey()

自定义加载

定义一个Model类用于包装需要加载的数据

定义一个Key的实现类，用于实现第一步的Model中的数据的签名用于区分缓存

定义一个DataFetcher的实现类，用于告诉Glide音频封面如何加载，并把加载结果回调出去

定义一个ModelLoader的实现类用于包装DataFetcher

定义一个ModelLoaderFactory的实现类用于生成ModelLoader实例

将自定义加载配置到AppGlideModule中

Glide线程池

磁盘缓存线程池，一个核心线程：用于io图片编码

加载资源线程池，最多不超过4个核心线程数，用于处理网络请求，图片解码转码

动画线程池，最多不超过2个线程

磁盘缓存清理线程池

ActiveResource 开启一个后台线程监听ReferenceQueue 所有线程池都默认采用优先级队列

加载Gif流程

读取流的前三个字节，若判断是gif，则会命中gif解码器-将资源解码成GifDrawable，它持有GifFrameLoader会将资源解码成一张张Bitmap并且传递给DelayTarget的对象，该对象每次资源加载完毕都会通过handler发送延迟消息回调 onFrameReady() 以触发GifDrawable.invalidataSelf()重绘。加载下一帧时会重新构建DelayTarget

请求优先级

通过给加载线程池配置优先级队列，加载任务DecodeJob 实现了 compareTo 方法，将priority相减

图片加载优化

服务器存多种尺寸的图片

自定义 AppGlideModule，按设备性能好坏设定MemoryCategory.HIGH,LOW,NORMAL，内存缓存和bitmapPool的大小系数，以及图片解码格式，ARGB_8888，RGB_565

RecyclerView 在onViewRecycled 中调用clear ，因为recyclerView会默认会缓存5个同类表项，如果类型很多，内存中会持有表项，如果这些表项都包含图片，Glide 的ActiveResource会膨胀。导致gc

如果 RecyclerView 包含一个很长的itemView，超过一屏，其中包含很多照片，最好把长itemView拆成多个itemView

使用thumbnail，加载一个缩略图，最好是一个独立的链接，如果是本地的也不差
使用preload，将资源提前加载到内存中。

大部分情况下 RESOURCE ，即缓存经过变换的图片上是最好选择，节约内存和磁盘。对于gif资源只缓存原始资源DATA，因为gif是多张图每次编码解码反而耗时
使用Glide实现变换，因为有BitmapPool供复用

裸辞-疫情-闭关-复习-大厂offer（二）（下）