Source code analysis

Serves requests from the cache and writes responses to the cache

Serves requests from the cache and writes the response to the cache

We can see that there is a get method before the proceed method and a put method after the proceed method. In our previous article (juejin.cn/post/700509… The interceptor uses the chain of responsibility design pattern. The request is processed before the proceed method, and the response is processed after the proceed method. The logic here is to use the get method to see if there is a cache. You get the response and you cache it with put.

First to see the put method, first response to this request method to compare if it is post | | patch | | put | | delete | | move one, is to remove the cache, and return. If it’s not a GET request, return it.

// Do not cache non-GET responses. We technically allow caching of HEAD // POST requests, but the complexity of doing so is high and the benefit low.Copy the code

Next comes the hasVaryAll method, which returns true if the Vary header contains an asterisk. Such responses cannot be cached.

The next step is to implement the caching method, using the DiskLruCache method cache (the caching method is disk cache, and the caching algorithm is LruCache), key is the URL of the request md5(),hex() calculation.

After looking at the PUT method, it is clear that the get method is only present in the cache pool for GET requests.

Now looking at the code after GET, this Factory passes in the current time, requests to fetch the cache.

Take a look at the acheStrategy builder. The three comments are:

1. Given a request and cached response, it determines whether to use network, cache, or both. Choosing a caching policy may add conditions to the request (such as the “if-Modified-since” header of a conditional GET) or warnings to the cached response if the cached data may be out of date.

2. The request sent over the network is null if the call does not use the network.

3. Cached response to be returned or validated; Null if the call does not use caching.

If the networkRequest object is not null, it needs to request the network once. If it is null, it does not need to request the network once. If the cacheResponse object is not empty, then the cache is reusable. If it is empty, it cannot be reused

Take some Response headers from the cached Response, all of which have the same function, to determine whether the cached Response is in the reusable state.

Looking at the compute method, cacheResponse returns the policy that satisfies the request.

See the computeCandidate method

If the cached response lacks the required handshake, it is deleted.

If this is an Https request, authentication is required to use the cache

If the server does not explicitly disable the cache and the cache has not expired, the cached Response object is simply reused

// Find a condition to add to the request. If the condition is met, the response body will not be transmitted. The client has cache but has expired, so at this time, we need to take out the Response resource identifier that we have cached before, add this identifier into the request header, and then request the server again, and let the background decide whether to reuse the expired cache.

Now that we’re done with caching, let’s go back to the cache interceptor.

If we are prohibited from using the network and the cache is insufficient, fail.

If there is no need to request the network to determine whether the cache is available, then the cached Response object is returned directly, otherwise the data on the network is retrieved

If we also have cached responses, we are doing conditional get.

If the local cache expires, we will ask the network to ask the server whether to reuse the cache. If the server returns a Response code of 304, then the server allows it, but the server will return us a Response object with an empty Body. So we need to replace the Body in networkResponse with the Body in cacheResponse, flush the cache for this request, and finally return the result.

So let’s look at what OkHttp does when there is no local cache. As usual, if the Response header has a Body and meets the caching criteria, it is cached, but if the request does not meet the caching criteria, it is removed from the cache and the Response object is returned

Source summary

I hope you have a look at the references, this part of the understanding is not deep enough, basically copied wheel brother, please forgive me.

This interceptor main effect is to handle the request cache, will first according to the url to the corresponding read from the disk cache, it is also need to note that the current OkHttp does not support read the Post request cache, if read from the cache, will determine whether the cache is available, only if the client and the server cannot disable caching, If the cache expires, OkHttp needs to make another request to see if the cache can be reused. If the server returns 304, the cache is available, but the Body is empty. It is necessary to combine the current Response object and the cached Response object into a new Response object, and then update the new Response object into the cache. If there is no cache before this, it is necessary to determine whether the conditions of the cache are met. If it does, it writes directly to the cache.

Refer to the blog

www.jianshu.com/p/44fad764c…