Okhttp request process sorting (super detailed version)

I've been looking at the source code of okhttp recently. I have to say that the source code design is very clever, from which I can learn a lot. In fact, there are many articles about okhttp on the Internet, and I have read a lot myself. But as the saying goes, a good memory is not as good as a bad pen. When you start, you will find many details you didn't notice when you read.

Okhttp version of this secondary analysis is 3.8.1, which is referenced in gradle as follows:

The reason why I chose to analyze 3.8.1 is that the latest version is written by kotlin. Because my kotlin strength does not allow, I can only analyze the Java version.

1. Initiate an asynchronous get request. The code is as follows:

2. Initiate a synchronous get request. The code is as follows:

It can be seen that the two requests are basically the same. The process is summarized as follows:

Through the example, we can briefly understand some objects in okhttp. Let's start combing the whole request logic. Start with okhttpclient.

When we initiate a request, we need to construct the okhttpclient object first. The code is as follows:

It can be found that the builder builder mode is used; Let's see what's inside

Realcall inherits from call and is the entity class that actually initiates the request. Realcall main methods:

Let's take a look at the specific contents:

It can be found that the client, the original request, and the request event callback listener are held inside. Let's look at the details of the requested callback listener:

You can see that okhttp callback is very detailed. There are all kinds of callback. Whether you want to use it or not, it helps you consider it. In this way, we can listen to specific callbacks and then do some operations.

The next step is to talk about the specific steps of asynchronous requests. Let's start with asynchronous requests, which are also the most commonly used.

You can see that the above code does several things:

Careful readers may find a problem, that is, enqueue here is clearly an asynccall encapsulated with responsecallback. How can it become joining the queue to execute the request? I will explain this below.

Dispatcher is the scheduler of okhttp, which is used to manage the queue of control requests. The internal thread pool ensures the orderly operation of the queue. Let's look at the details of enqueue method:

You can see that there are two queues inside, one is the running queue runningasynccalls, and the other is the readyasynccalls queue. If the current number of runs is less than the maximum number of runs, and the current requested host is less than the maximum number of requests, it will be directly added to the run queue and run. If it exceeds, it will join the preparation queue.

In fact, there is also a synchronization queue. There is no restriction on the synchronization queue. As soon as you join, you start executing requests.

After the request queue completes the request, it needs to be removed. See the code logic of finished:

As you can see, this is a generic type. You can remove it directly without worrying about the specific incoming queue. If promotecalls is true, it means that it is an asynchronous request queue. A queue must be taken from the readyasynccalls queue and added to the runningasynccalls queue to execute the request.

Through the above code, the function of the scheduler is basically clarified.

Asynccall is an internal class in realcall, which inherits from namedrunnable. It is a custom runnable and can set the name for the thread. The internal code is as follows:

It can be found that the execute method is called inside the run method, which is the real logic to initiate the request. Let's take a look at the specific contents of this method in asynccall:

The response data is finally obtained through getresponsewithinterceptorchain(). The response is then returned to the user through a callback.