OkHttp拦截器的作用

 

目录

 

 

拦截器 

OkHttp中的拦截器 

失败重连以及重定向的拦截器：RetryAndFollowUpInterceptor

桥接拦截器BridgeInterceptor

缓存拦截器CacheInterceptor

连接拦截器 和 最后的请求服务器的拦截器

总结

 

 

 

自定义拦截器 

我们可以通过自定义拦截器做什么

1.重写请求

2.重写响应

 

 

如何使用自定义拦截器

Application interceptors

Network interceptors

选择使用Application或Network拦截器?

---

拦截器 

拦截器是OkHttp中提供一种强大机制，它可以实现网络监听、请求以及响应重写、请求失败重试等

功能。下面举一个简单打印日志的栗子，此拦截器可以打印出网络请求以及响应的信息。

有关拦截器的逻辑流程及原理，看OkHttp拦截器原理

 

OkHttp中的拦截器 

我们来看看OkHttp中各个拦截器的顺序

这些Interceptor中每一个的职责

失败重连以及重定向的拦截器：RetryAndFollowUpInterceptor

失败重连拦截器核心源码：
一个循环来不停的获取response。每循环一次都会获取下一个request，如果没有，则返回response，退出循环。而获取下一个request的逻辑，是根据上一个response返回的状态码，分别作处理。

桥接拦截器BridgeInterceptor

桥接拦截器的主要作用是将：

1. 请求从应用层数据类型类型转化为网络调用层的数据类型。

    

   

2. 将网络层返回的数据类型 转化为 应用层数据类型。

   1. 保存最新的cookie(默认没有cookie，需要应用程序自己创建，详见
                    [Cookie的API]
                    (https://square.github.io/okhttp/3.x/okhttp/okhttp3/CookieJar.html)
                    和
                    [Cookie的持久化]
                    (https://segmentfault.com/a/1190000004345545))；
        2. 如果request中使用了"gzip"压缩，则进行Gzip解压。解压完毕后移除Header中的"Content-Encoding"和"Content-Length"（因为Header中的长度对应的是压缩前数据的长度，解压后长度变了，所以Header中长度信息实效了）；
        3. 返回response。
   
   

补充：Keep－Alive 连接：
HTTP中的keepalive连接在网络性能优化中，对于延迟降低与速度提升的有非常重要的作用。
通常我们进行http连接时，首先进行tcp握手，然后传输数据，最后释放

http连接

这种方法的确简单，但是在复杂的网络内容中就不够用了，创建socket需要进行3次握手，而释放socket需要是4次。重复的连接与释放tcp连接就像每次仅仅挤1mm的牙膏就合上牙膏盖子接着再打开接着挤一样。而每次连接大概是TTL一次的时间(也就是ping一次)，在TLS环境下消耗的时间就更多了。很明显，当访问复杂网络时，延时（而不是带宽）将成为非常重要的因素。
当然，上面的问题早已经解决了，在http中有一种叫做keepalive connections的机制，它可以在传输数据后仍然保持连接，当客户端需要再次获取数据时，直接使用刚刚空闲下来的连接而不需要再次握手

Keep-Alive连接

在现代浏览器中，一般同时开启6～8个keepalive connections的socket连接，并保持一定的链路生命，当不需要时再关闭；而在服务器中，一般是由软件根据负载情况决定是否主动关闭。

缓存拦截器CacheInterceptor

缓存拦截器的主要作用是将请求 和 返回 关连得保存到缓存中。客户端与服务端根据一定的机制，在需要的时候使用缓存的数据作为网络请求的响应，节省了时间和带宽。

客户端与服务端之间的缓存机制：

• 作用：将HTPTP和HTTPS的网络返回数据缓存到文件系统中，以便在服务端数据没发生变化的情况下复用，节省时间和带宽；

• 工作原理：客户端发器网络请求，如果缓存文件中有一份与该请求匹配（URL相同）的完整的返回数据（比如上一次请求返回的结果），那么客户端就会发起一个带条件（例子，服务端第一次返回数据时，在response的Header中添加上次修改的时间信息：Last-Modified: Tue, 12 Jan 2016 09:31:27 GMT；客户端再次请求的时候，在request的Header中添加这个时间信息：If-Modified-Since: Tue, 12 Jan 2016 09:31:27 GMT）的获取资源的请求。此时服务端根据客户端请求的条件，来判断该请求对应的数据是否有更新。如果需要返回的数据没有变化，那么服务端直接返回 304 "not modified"。客户端如果收到响应码味304 的信息，则直接使用缓存数据。否则，服务端直接返回更新的数据。具体如下图所示：

   

  

  带缓存的网络请求流程

客户端缓存的实现：

OKHttp3的缓存类为Cache类，它实际上是一层缓存逻辑的包装类。内部有个专门负责缓存文件读写的类：DiskLruCache。于此同时，OKHttp3还定义了一个缓存接口：InternalCache。这个缓存接口类作为Cache的成员变量其所有的实现，都是调用了Cahce类的函数实现的。它们间具体的关系如下：

缓存的工作机制

InternalCache接口：

    public interface InternalCache {
      Response get(Request request) throws IOException;
    
      CacheRequest put(Response response) throws IOException;
    
      /**
       * 移除request相关的缓存数据
       */
      void remove(Request request) throws IOException;
    
      /**
       * 用网络返回的数据，更新缓存中数据
       */
      void update(Response cached, Response network);
    
      /** 统计网络请求的数据 */
      void trackConditionalCacheHit();
    
      /** 统计网络返回的数据 */
      void trackResponse(CacheStrategy cacheStrategy);
    }

Note:setInternalCache这个方法是不对应用程序开放的，应用程序只能使用cache(Cache cache)这个方法来设置缓存。并且，Cache内部的internalCache是final的，不能被修改。总结：internalCache这个接口虽然是public的，但实际上，应用程序是无法创建它，并附值到OkHttpClient中去的。

那么问题来了，为什么不用Cahce实现InternalCache这个接口，而是以组合的方式，在它的内部实现都调用了Cache的方法呢？
因为：

• 在Cache中，InternalCache接口的两个统计方法：trackConditionalCacheHit和trackResponse (之所以要统计，是为了查看缓存的效率。比如总的请求次数与缓存的命中次数。)需要用内置锁进行同步。
• Cache中，将trackConditionalCacheHit和trackResponse方法 从public变为为privite了。不允许子类重写，也不开放给应用程序。

Cache类：

• 将网络请求的文件读写操作委托给内部的DiskLruCache类来处理。

• 负责将url转换为对应的key。

• 负责数据统计：写成功计数，写中断计数，网络调用计数，请求数量计数，命中数量计数。

• 负责网络请求的数据对象Response 与 写入文件系统中的文本数据 之间的转换。使用内部类Entry来实现。具体如下：

    网络请求的文件流文本格式如下：
            {
                 http://google.com/foo
                 GET
                 2
                 Accept-Language: fr-CA
                 Accept-Charset: UTF-8
                 HTTP/1.1 200 OK
                 3
                 Content-Type: image/png
                 Content-Length: 100
                 Cache-Control: max-age=600
                 ...
              }     
    内存对象的Entry格式如下.
            private static final class Entry {
                private final String url;
                private final Headers varyHeaders;
                private final String requestMethod;
                private final Protocol protocol;
                private final int code;
                private final String message;
                ...
            ｝           
  

通过okio的读写API，实现它们之间灵活的切换。

DiskLruCache类：

简介：一个有限空间的文件缓存。

• 每个缓存数据都有一个string类型的key和一些固定数量的值。
• 缓存的数据保存在文件系统的一个目录下。这个目录必须是该缓存独占的：因为缓存运行时会删除和修改该目录下的文件，因而该缓存目录不能被其他线程使用。
• 缓存限制了总的文件大小。如果存储的大小超过了限制，会以LRU算法来移除一些数据。
• 可以通过edit,update方法来修改缓存数据。每次调用edit，都必须以commit或者abort结束。commit是原子操作。
• 客户端调用get方法来读取一个缓存文件的快照(存储了key,快照序列号，数据源和数据长度)。

缓存使用了日志文件(文件名为journal)来存储缓存的数据目录和操作记录。一个典型的日志文件的文本文档如下：

     //第一行为缓存的名字
     libcore.io.DiskLruCache                            
     1                                                    //缓存的版本
     100                                                 //应用版本
     2                                                   //值的数量          
     //缓存记录：操作 key 第一个数据的长度 第二个数据的长度    
     CLEAN 3400330d1dfc7f3f7f4b8d4d803dfcf6 832 21054    
     DIRTY 335c4c6028171cfddfbaae1a9c313c52
     CLEAN 335c4c6028171cfddfbaae1a9c313c52 3934 2342
     REMOVE 335c4c6028171cfddfbaae1a9c313c52
     DIRTY 1ab96a171faeeee38496d8b330771a7a
     CLEAN 1ab96a171faeeee38496d8b330771a7a 1600 234
     READ 335c4c6028171cfddfbaae1a9c313c52
     READ 3400330d1dfc7f3f7f4b8d4d803dfcf6

操作记录：状态＋key＋额外擦数

• CLEAN key param0 param1：该key的对应的数据为最新的有效数据，后续为额外的参数
• DIRTY key：该key对应的数据被创建或被修改。
• REMOVE key：该key对应的数据被删除。
• READ key：改key对应的数据被读取的记录。——用于LRU算法来统计哪些数据是最新的数据。

一些冗余的操作记录，比如DIRTY,REMOVE...比较多的时候(大于2000个，或者超过总数量)，会发器线程对该日志文件进行压缩(删除这些冗余的日志记录)。此时，会创建一个journal.tmp文件作为临时的文件，供缓存继续使用。同时还有个journal.bkp文件，用作journal文件的临时备份。
换文文件结构如下：

缓存的文件mu lu

工作原理：

• 每个缓存记录在内存中的对象封装为Entry类

     private final class Entry {         
       private final String key; //缓存对应的key
       
       private final long[] lengths; //文件的长度
       private final File[] cleanFiles; //有效的数据文件
       private final File[] dirtyFiles; //正在修改的数据文件
   
       private boolean readable;//是否可读
   
       private Editor currentEditor;//当前的编辑器。一个Entry一个时候只能被一个编辑器修改。
  
       private long sequenceNumber; //唯一序列号，相当于版本号，当内存中缓存数据发生变化时，该序列号会改变。
       
       ...    
       ｝
  

• 创建缓存快照对象，作为每次读取缓存时的一个内容快照对象：

     public final class Snapshot implements Closeable {
       private final String key;   //缓存的key
       private final long sequenceNumber; //创建快照的时候的缓存序列号
       private final Source[] sources;//数据源,okio的API，可以直接读取
       private final long[] lengths;//数据长度。
       ...
       ｝
  

  内容快照作为读去缓存的对象(而不是将Entry直接返回)的作用：
  (1). 内容快照的数据结构方式更便于数据的读取(将file转换为source)，并且隐藏了Entry的细节；
  (2). 内容快照在创建的时候记录了当时的Entry的序列号。因而可以用快照的序列号与缓存的序列号对比，如果序列号不相同，则说明缓存数据发生了修改，该条数据就是失效的。

• 缓存内容Entry的这种工作机制（单个editor，带有序列号的内容快照）以最小的代价，实现了单线程修改，多线程读写的数据对象（否则则需要使用复杂的锁机制）既添降低了逻辑的复杂性，又提高了性能（缺点就是高并发情况下，导致数据频繁失效，导致缓存的命中率降低）。
• 变化的序列号计数在很多涉及并发读取的机制都有使用。比如：SQlite的连接。

• DiskLruCache缓存文件工作流：

DiskLruCache缓存工作流

其返回的SnapShot数据快照，提供了Source接口(okio),供外部内类Cache直接转化为内存对象Cache.Entry。外部类进一步Canche.Entry转化外OKHttpClient使用的Response。

OkHttpClient从缓存中获取一个url对应的缓存数据的数据格式变化过程如下：

缓存数据格式变化过程

LRU的算法体现在：DiskLreCache的日志操作过程中，每一次读取缓存都产生一个READ的记录。由于缓存的初始化是按照日志文件的操作记录顺序来读取的，所以这相当于把这条缓存数据放置到了缓存队列的顶端，也就完成了LRU算法：last recent used，最近使用到的数据最新。

连接拦截器 和 最后的请求服务器的拦截器

这两个连接器基本上完成了最后发起网络请求的工作。追所以划分为两个拦截器，除了解耦之外，更重要的是在这两个流程之间还可以插入一个专门为WebSocket服务的拦截器( WebSocket一种在单个 TCP 连接上进行全双工通讯的协议,本文不做详解)。

总结

1.失败重连拦截器：
一个循环来不停的获取response。每循环一次都会获取下一个request，如果没有，则返回response，退出循环。而获取下一个request的逻辑，是根据上一个response返回的状态码，分别作处理。

2.桥接拦截器：

请求从应用层数据类型类型转化为网络调用层的数据类型。将网络层返回的数据类型 转化为 应用层数据类型。

3.缓存拦截器：

CacheInterceptor主要作用是将请求 和 返回 关连得保存到缓存中。客户端与服务端根据一定的机制，在需要的时候使用缓存的数据作为网络请求的响应，节省了时间和带宽。

4.连接拦截器   5.请求服务器的拦截器：

这两个连接器基本上完成了最后发起网络请求的工作。追所以划分为两个拦截器，除了解耦之外，更重要的是在这两个流程之间还可以插入一个专门为WebSocket服务的拦截器( WebSocket一种在单个 TCP 连接上进行全双工通讯的协议,本文不做详解)。

 

 

 

自定义拦截器 

我们可以通过自定义拦截器做什么

1.重写请求

拦截器可以添加、移除或者替换请求头。甚至在有请求主体时候，可以改变请求主体。举个栗子，你可以使用application interceptor添加经过压缩之后的请求主体，当然，这需要你将要连接的服务端支持处理压缩数据。

/** This interceptor compresses the HTTP request body. Many webservers can't handle this! */
final class GzipRequestInterceptor implements Interceptor {
  @Override public Response intercept(Interceptor.Chain chain) throws IOException {
    Request originalRequest = chain.request();
    if (originalRequest.body() == null || originalRequest.header("Content-Encoding") != null) {
      return chain.proceed(originalRequest);
    }

    Request compressedRequest = originalRequest.newBuilder()
        .header("Content-Encoding", "gzip")
        .method(originalRequest.method(), gzip(originalRequest.body()))
        .build();
    return chain.proceed(compressedRequest);
  }

  private RequestBody gzip(final RequestBody body) {
    return new RequestBody() {
      @Override public MediaType contentType() {
        return body.contentType();
      }

      @Override public long contentLength() {
        return -1; // We don't know the compressed length in advance!
      }

      @Override public void writeTo(BufferedSink sink) throws IOException {
        BufferedSink gzipSink = Okio.buffer(new GzipSink(sink));
        body.writeTo(gzipSink);
        gzipSink.close();
      }
    };
  }
}

2.重写响应

和重写请求相似，拦截器可以重写响应头并且可以改变它的响应主体。相对于重写请求而言，重写响应通常是比较危险的一种做法，因为这种操作可能会改变服务端所要传递的响应内容的意图。
当然，如果你 比较奸诈 在不得已的情况下，比如不处理的话的客户端程序接受到此响应的话会Crash等，以及你还可以保证解决重写响应后可能出现的问题时，重新响应头是一种非常有效的方式去解决这些导致项目Crash的问题。举个栗子，你可以修改服务器返回的错误的响应头Cache-Control信息，去更好地自定义配置响应缓存保存时间。

/** Dangerous interceptor that rewrites the server's cache-control header. */
private static final Interceptor REWRITE_CACHE_CONTROL_INTERCEPTOR = new Interceptor() {
  @Override public Response intercept(Interceptor.Chain chain) throws IOException {
    Response originalResponse = chain.proceed(chain.request());
    return originalResponse.newBuilder()
        .header("Cache-Control", "max-age=60")
        .build();
  }
};

 

OkHttp是由Square发布的一个HTTP client，它支持高速缓存服务器响应.

缓存：

如果服务器支持缓存，请求返回的Response会带有这样的Header:Cache-Control, max-age=xxx,这种情况下我们只需要手动给okhttp设置缓存就可以让okhttp自动帮你缓存了。这里的max-age的值代表了缓存在你本地存放的时间。
 

OkHttpClient okHttpClient = new OkHttpClient();
OkHttpClient newClient = okHttpClient.newBuilder()
               .cache(new Cache(mContext.getCacheDir(), 10240*1024))
               .connectTimeout(20, TimeUnit.SECONDS)
               .readTimeout(20, TimeUnit.SECONDS)
               .build();

如果服务器不支持缓存就可能没有指定这个头部，这种情况下我们就需要使用Interceptor来重写Respose的头部信息，从而让okhttp支持缓存。

Interceptor interceptor = new Interceptor() {
        @Override
        public Response intercept(Chain chain) throws IOException {
            Request request = chain.request();
            Response response = chain.proceed(request);
 
            String cacheControl = request.cacheControl().toString();
            if (TextUtils.isEmpty(cacheControl)) {
                cacheControl = "public, max-age=60";
            }
            return response.newBuilder()
                    .header("Cache-Control", cacheControl)
                    .removeHeader("Pragma")
                    .build();
        }
    };

 

如何使用自定义拦截器

class LoggingInterceptor implements Interceptor {
  @Override public Response intercept(Interceptor.Chain chain) throws IOException {
    Request request = chain.request();

    long t1 = System.nanoTime();
    logger.info(String.format("Sending request %s on %s%n%s",
        request.url(), chain.connection(), request.headers()));

    Response response = chain.proceed(request);

    long t2 = System.nanoTime();
    logger.info(String.format("Received response for %s in %.1fms%n%s",
        response.request().url(), (t2 - t1) / 1e6d, response.headers()));

    return response;
  }
}

上面自定义了一个拦截器

那么如何添加拦截器呢？首先，我们要知道，拦截器分两种：Application和Network拦截器

拦截器可以以application或者network两种方式注册，分别调用addInterceptor()以及addNetworkInterceptor方法进行注册。我们使用上文中日志拦截器的使用来体现出两种注册方式的不同点。

Application interceptors

首先通过调用addInterceptor()在OkHttpClient.Builder链式代码中注册一个application拦截器：

OkHttpClient client = new OkHttpClient.Builder()
    .addInterceptor(new LoggingInterceptor())
    .build();

Request request = new Request.Builder()
    .url("http://www.publicobject.com/helloworld.txt")
    .header("User-Agent", "OkHttp Example")
    .build();

Response response = client.newCall(request).execute();
response.body().close();

请求的URLhttp://www.publicobject.com/helloworld.txt被重定向成https://publicobject.com/helloworld.txt,OkHttp支持自动重定向。注意，我们的application拦截器只会被调用一次，并且调用chain.proceed()之后获得到的是重定向之后的最终的响应信息，并不会获得中间过程的响应信息：

INFO: Sending request http://www.publicobject.com/helloworld.txt on null
User-Agent: OkHttp Example

INFO: Received response for https://publicobject.com/helloworld.txt in 1179.7ms
Server: nginx/1.4.6 (Ubuntu)
Content-Type: text/plain
Content-Length: 1759
Connection: keep-alive

我们可以看到请求的URL被重定向了，因为response.request().url()和request.url()是不一样的。日志打印出来的信息显示两个不同的URL。客户端第一次请求执行的url为http://www.publicobject.com/helloworld.txt，而响应数据的url为https://publicobject.com/helloworld.txt。

Network interceptors

注册一个Network拦截器和注册Application拦截器方法是非常相似的。注册Application拦截器调用的是addInterceptor()，而注册Network拦截器调用的是addNetworkInterceptor()。

OkHttpClient client = new OkHttpClient.Builder()
    .addNetworkInterceptor(new LoggingInterceptor())
    .build();

Request request = new Request.Builder()
    .url("http://www.publicobject.com/helloworld.txt")
    .header("User-Agent", "OkHttp Example")
    .build();

Response response = client.newCall(request).execute();
response.body().close();

我们运行这段代码，发现这个拦截被执行了两次。一次是初始化也就是客户端第一次向URL为http://www.publicobject.com/helloworld.txt发出请求，另外一次则是URL被重定向之后客户端再次向https://publicobject.com/helloworld.txt发出请求。

INFO: Sending request http://www.publicobject.com/helloworld.txt on Connection{www.publicobject.com:80, proxy=DIRECT hostAddress=54.187.32.157 cipherSuite=none protocol=http/1.1}
User-Agent: OkHttp Example
Host: www.publicobject.com
Connection: Keep-Alive
Accept-Encoding: gzip

INFO: Received response for http://www.publicobject.com/helloworld.txt in 115.6ms
Server: nginx/1.4.6 (Ubuntu)
Content-Type: text/html
Content-Length: 193
Connection: keep-alive
Location: https://publicobject.com/helloworld.txt

INFO: Sending request https://publicobject.com/helloworld.txt on Connection{publicobject.com:443, proxy=DIRECT hostAddress=54.187.32.157 cipherSuite=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA protocol=http/1.1}
User-Agent: OkHttp Example
Host: publicobject.com
Connection: Keep-Alive
Accept-Encoding: gzip

INFO: Received response for https://publicobject.com/helloworld.txt in 80.9ms
Server: nginx/1.4.6 (Ubuntu)
Content-Type: text/plain
Content-Length: 1759
Connection: keep-alive

NetWork请求包含了更多信息，比如OkHttp为了减少数据的传输时间以及传输流量而自动添加的请求头Accept-Encoding: gzip希望服务器能返回经过压缩过的响应数据。Network 拦截器调用Chain方法后会返回一个非空的Connection对象，它可以用来查询客户端所连接的服务器的IP地址以及TLS配置信息。

选择使用Application或Network拦截器?

每一个拦截器都有它的优点。

Application interceptors

• 无法操作中间的响应结果，比如当URL重定向发生以及请求重试等，只能操作客户端主动第一次请求以及最终的响应结果。
• 在任何情况下只会调用一次，即使这个响应来自于缓存。
• 可以监听观察这个请求的最原始未经改变的意图（请求头，请求体等），无法操作OkHttp为我们自动添加的额外的请求头，比如If-None-Match。
• 允许short-circuit (短路)并且允许不去调用Chain.proceed()。（编者注：这句话的意思是Chain.proceed()不需要一定要调用去服务器请求，但是必须还是需要返回Respond实例。那么实例从哪里来？答案是缓存。如果本地有缓存，可以从本地缓存中获取响应实例返回给客户端。这就是short-circuit (短路)的意思。。囧）
• 允许请求失败重试以及多次调用Chain.proceed()。

Network Interceptors

• 允许操作中间响应，比如当请求操作发生重定向或者重试等。
• 不允许调用缓存来short-circuit (短路)这个请求。（编者注：意思就是说不能从缓存池中获取缓存对象返回给客户端，必须通过请求服务的方式获取响应，也就是Chain.proceed()）
• 可以监听数据的传输
• 允许Connection对象装载这个请求对象。（编者注：Connection是通过Chain.proceed()获取的非空对象）