前言

之前我们结合设计模式简单说了下OkHttp的大体流程，今天就继续说说它的核心部分——拦截器。

因为拦截器组成的链其实是完成了网络通信的整个流程，所以我们今天就从这个角度说说各拦截器的功能。

首先，做一下简单回顾，从getResponseWithInterceptorChain方法开始。

简单回顾（getResponseWithInterceptorChain）

internal fun getResponseWithInterceptorChain(): Response {
    // Build a full stack of interceptors.
    val interceptors = mutableListOf<Interceptor>()
    interceptors += client.interceptors
    interceptors += RetryAndFollowUpInterceptor(client)
    interceptors += BridgeInterceptor(client.cookieJar)
    interceptors += CacheInterceptor(client.cache)
    interceptors += ConnectInterceptor
    if (!forWebSocket) {
      interceptors += client.networkInterceptors
    }
    interceptors += CallServerInterceptor(forWebSocket)
    val chain = RealInterceptorChain(
        interceptors = interceptors
        //...
    )
    val response = chain.proceed(originalRequest)
  }

这些拦截器会形成一条链，组织了请求接口的所有工作。

以上为上节内容，不了解的朋友可以返回上一篇文章看看。

假如我来设计拦截器

先抛开拦截器的这些概念不谈，我们回顾下网络通信过程，看看实现一个网络框架至少要有哪些功能。

• 请求过程：封装请求报文、建立TCP连接、向连接中发送数据
• 响应过程：从连接中读取数据、处理解析响应报文

而之前说过拦截器的基本代码格式是这样：

  override fun intercept(chain: Interceptor.Chain): Response {
    //做事情A
    response = realChain.proceed(request)
    //做事情B
  }

也就是分为 请求前工作，请求传递，获取响应后工作 三部分。

那我们试试能不能把上面的功能分一分，设计出几个拦截器？

• 拦截器1: 处理请求前的 请求报文封装，处理响应后的 响应报文分析

诶，不错吧，拦截器1就用来处理 请求报文和响应报文的一些封装和解析工作。就叫它封装拦截器吧。

• 拦截器2: 处理请求前的 建立TCP连接

肯定需要一个拦截器用来建立TCP连接，但是响应后好像没什么需要做连接方面的工作了？那就先这样，叫它连接拦截器吧。

• 拦截器3:处理请求前的 数据请求(写到数据流中) 处理响应后的 数据获取（从数据流拿数据）

这个拦截器就负责TCP连接后的 I/O操作，也就是从流中读取和获取数据。就叫它 数据IO拦截器 吧。

好了，三个拦截器好像足够了，我得意满满的偷看了一眼okhttp拦截器代码，7个？？？我去。。

那再思考思考