Network framework analysis – all tricks

Preface

I took some time to read the source code of Volley and Picasso these days, and gained a lot, so I would like to share it with you here.

For a network request framework or image loading framework, our ideal model should be like this:

• Simple: The emergence of the framework is of course to improve our development efficiency and make our development simple, so simplicity comes first while ensuring quality.
• Configurable: There are no two leaves or projects that are exactly the same, so some differences should be configurable, such as cache location, cache size, cache strategy, etc.
• Easy to expand: The framework should be designed with changes in mind and encapsulated. For example, if we have a better HTTP client, we should be able to modify it easily without causing too much impact on our previous code.

But no matter how things change, the skeletons of these frameworks are basically the same. Today we will discuss the routines in these frameworks.

Basic Modules

Since we said that the structures of these frameworks are basically the same, let's first look at the similar module structures between them.

The overall process is probably like this:

Client request->Generate framework-encapsulated request type->Scheduler starts processing tasks->Call data acquisition module->Process acquired data->Call back to client

Producer Consumer Model

The request management and task scheduling modules in the framework generally use the producer-consumer model.

Why is there a producer consumer model?

In the thread world, producers are threads that produce data, and consumers are threads that consume data. In multi-threaded development, if the producer processes very quickly and the consumer processes very slowly, then the producer must wait for the consumer to finish processing before continuing to produce data. Similarly, if the consumer's processing power is greater than the producer, then the consumer must wait for the producer. To solve this problem, the producer and consumer model was introduced.

What is the producer consumer model?

The producer-consumer model uses a container to solve the problem of strong coupling between producers and consumers. Producers and consumers do not communicate directly with each other, but communicate through blocking queues. Therefore, after the producer produces data, it does not need to wait for the consumer to process it, but directly throws it to the blocking queue. The consumer does not ask the producer for data, but directly takes it from the blocking queue. The blocking queue is equivalent to a buffer, which balances the processing capabilities of producers and consumers.

Usage scenarios of the producer consumer model

The thread pool class in Java is actually a way to implement the producer and consumer model, but the implementation method is more sophisticated. The producer throws the task to the thread pool, the thread pool creates threads and processes the task, if the number of tasks to be run is greater than the basic number of threads in the thread pool, the task is thrown into the blocking queue. This approach is obviously much smarter than using only one blocking queue to implement the producer and consumer model, because the consumer can handle it directly, which is faster, while the producer first stores and the consumer then retrieves it, which is obviously slower.

Applications in the framework

For the above usage scenarios, we can find the implementation in the framework respectively.

The implementation method in Volley source code is to use a priority blocking queue to implement the producer-consumer model. The producer is the thread that adds data to the queue, and the consumer is a thread array with a default of 4 elements (excluding the thread that processes the cache) to continuously retrieve messages for processing.

Picssso is a typical producer-consumer model implemented by a thread pool, so I won't introduce it in detail here.

The data structure used by these two frameworks is PriorityBlockingQueue (priority blocking queue), the purpose of which is to sort and ensure that high-priority requests are processed first.

By the way, Android's message processing mechanism is actually a producer-consumer model.

A small problem

Here the blogger thought of a small question: what is the order of waking up consumers?

This involves a concept called fair access queue, which means that all blocked producer threads or consumer threads can access the queue in the order of blocking when the queue is available, that is, the producer thread that blocked first can insert elements into the queue first, and the consumer thread that blocked first can get elements from the queue first. Usually, throughput will be reduced to ensure fairness.

cache

Android cache is divided into memory cache and file cache (disk cache).

Generally, network frameworks do not need to deal with memory cache, but image loading frameworks do. After Android 3.1, Android launched the memory cache class LruCache, and objects in LruCache are strongly referenced. Picasso's memory cache is implemented using LruCache. For disk cache, one solution provided by Google is to use DiskLruCache (DiskLruCache is not integrated into the Android source code, but is explained in the examples in Android Doc). Picasso's disk cache is based on okhttp and uses DiskLruCache. Volley's disk cache is implemented in DiskBasedCache, which is also based on the Lru algorithm.

As for other cache algorithms, cache hit rates and other concepts, I will not go into detail here.

Asynchronous processing

We know that Android is a single-threaded model, and we should avoid time-consuming operations in the UI thread. Network requests are a typical time-consuming operation, so network-related frameworks will encapsulate asynchronous operations.

In fact, there is nothing complicated here. It is nothing more than using Handler to communicate between threads, and then cooperating with the callback mechanism to return the result to the main thread. You can refer to my previous articles "Android Handler Message Mechanism (Questions and Answers)" and "When the Observer Pattern and Callback Mechanism Meet Android Source Code".

Let's take Volley as an example. The ExecutorDelivery class is responsible for distributing responses or error messages generated by child threads. Initialization is in the RequestQueue class.

 public RequestQueue(Cache cache, Network network, int threadPoolSize) {
        this(cache, network, threadPoolSize,
                new ExecutorDelivery(new Handler(Looper.getMainLooper())));
 }

The Handler object of the main thread is passed in here, and this ExecutorDelivery object will be passed to NetworkDispatcher and CacheDispatcher, which are inherited from Thread and are responsible for processing requests in the queue. Therefore, the operation of processing requests occurs in the child thread.

Then let's look at the construction method of the ExecutorDelivery class

 public ExecutorDelivery(final Handler handler) {
        // Make an Executor that just wraps the handler.
        mResponsePoster = new Executor() {
 @Override
 public void execute (Runnable command) {
                handler.post(command);
 }
 };
 }

Here, Executor is used to wrap Handler. The responses data or error information in Volley will be sent through Executor, so that the message reaches the main thread.

Picasso is a little more complicated than Volley. Picasso will transform the image, which is a time-consuming operation. Therefore, the request distribution and result processing in Picasso are placed in a separate thread. This thread is a thread with a message queue, which is used to perform cyclic tasks, that is, to process the acquired data. After it completes the result processing, it will send the result back to the main thread through the main thread's Handler for display and other operations.

Design Patterns

Excellent frameworks will make reasonable use of design patterns to make the code easy to expand and maintain later. Here are some design patterns that appear more frequently.

• Static factory method: A factory object determines which product class instance to create
• Singleton pattern: ensure that only one object is created
• Builder pattern: Separates the construction of a complex object from its representation, so that the same construction process can create different representations
• Facade pattern: simplifying the interface of a group of classes
• Command pattern: encapsulate requests into objects
• Strategy pattern: encapsulates mutually selectable behaviors and uses delegation to decide which one to use

Framework entry

In order to keep the call simple, the general framework will not allow the client to directly instantiate an entry object through new. This is where the creational pattern comes into play.

The entry of Volley uses a static factory method, which is similar to the instantiation of Bitmap in the Android source code. For details, please refer to "Static Factory Method in Android Source Code"

 /**
  * Creates a default instance of the worker pool and calls {@link RequestQueue#start()} on it.
 *
  * @param context A {@link Context} to use for creating the cache dir.
  * @ return A started {@link RequestQueue} instance.
 */
 public   static RequestQueue newRequestQueue(Context context) {
 return newRequestQueue(context, null );
 }

Picasso's entry method uses a double-locked singleton pattern

 static volatile Picasso singleton = null ;
 public   static Picasso with (Context context) {
 if (singleton == null ) {
      synchronized (Picasso.class) {
        if (singleton == null ) {
          singleton = new Builder(context).build();
 }
 }
 }
 return singleton;
 }

At the same time, because there are too many configurable items, Picasso also uses the Builder mode.

At the same time, in order to provide a concise API to the client, some frameworks use the facade pattern to define a high-level interface, making each module in the framework easier to use. The facade pattern is a structural pattern.

For the appearance mode, please refer to "Appearance Mode in Android Source Code"

Command Mode

The definition of the command pattern is to encapsulate a request into an object, so that you can parameterize clients with different requests, queue or log requests, and support revocable operations. In the network request framework, requests are encapsulated into objects for easy transmission and use, such as Request in Volley, Request and Action in Picasso.

The command mode can refer to "Command Mode in Android Source Code"

Strategy Pattern

The strategy pattern is also a pattern used by most frameworks. Its function is to encapsulate mutually selectable behaviors and use delegation to decide which one to use.

Volley makes extensive use of interface-oriented programming ideas. Here we look at Volley's entry method

 public   static RequestQueue newRequestQueue(Context context, HttpStack stack, int maxDiskCacheBytes) {
 //~Omit some irrelevant code~
 if (stack == null ) {
    if (Build.VERSION.SDK_INT >= 9) {
      stack = new HurlStack();
 } else {
 // Prior   to Gingerbread, HttpUrlConnection was unreliable.
      // See: http://android-developers.blogspot.com/2011/09/androids-http-clients.html
      stack = new HttpClientStack(AndroidHttpClient.newInstance(userAgent));
 }
 } 
  
  Network network = new BasicNetwork(stack);
 //~Omit some irrelevant code~
 }

Different Http clients will be selected according to the API version, and they implement a common interface

 /**
 * An HTTP stack abstraction.
 */
 public interface HttpStack {
 /**
     * Performs an HTTP request with the given parameters.
 *
     * <p>A GET request is sent if request.getPostBody() == null . A POST request is sent otherwise,
     * and the Content-Type header is   set   to request.getPostBodyContentType().</p>
 *
     * @param request the request to perform
     * @param additionalHeaders additional headers to be sent together with  
     * {@link Request#getHeaders()}
     * @ return the HTTP response
 */
 public HttpResponse performRequest(Request<?> request, Map<String, String> additionalHeaders)
    throws IOException, AuthFailureError; 
  
 }

Of course, we can also implement this interface ourselves and replace the Http client with okhttp.

postscript

That's basically all the network-related framework routines. You can check the relevant source code for details. If there is anything imperfect or wrong, please give me your advice.