从网络请求过程看OkHttp拦截器

前言

之前我们结合设计模式简单说了下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)
  }

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

从网络请求过程看OkHttp拦截器

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

假如我来设计拦截器

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

  • 请求过程:封装请求报文、建立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个???我去。。

那再思考思考

上一篇:android-如何为Dagger2提供上下文


下一篇:如何在okhttp中自动将Charset自动添加到Content-Type中