Android Object pool Message

Android Object pool Message

In the android system, messages are often used in information exchange between multiple threads. Handler is used to transmit messages between threads. Today we are discussing the message feature in android: Object pool.

In android, google provides an English description of message:

*

While the constructor of Message is public, the best way to get
* One of these is to call {@ link # obtain Message. obtain ()} or one of
* {@ Link Handler # obtainMessage Handler. obtainMessage ()} methods, which will pull
* Them from a pool of recycled objects.

Although the message construction method is public, it is best to use this method obtainMessage () to obtain a message (), this method can obtain the required message from a reusable Object pool.

As mentioned above, we can know that an object pool is actually maintained in the original message. When we use a message, this message may be saved in this object pool, in other words, there is an object pool in the message to save the message we used. in fact, through code, we can know that when there is no message in the object pool we need, a new message will be automatically generated. so you don't have to worry that obtainMessage () cannot get the message.

Now let's take a look at how to design the android message object pool. In fact, the object pool in the message is actually implemented by maintaining a single linked list! Let's take a look.

The message contains the following variables and definitions:

    /*package*/ Message next;    private static final Object sPoolSync = new Object();    private static Message sPool;    private static int sPoolSize = 0;    private static final int MAX_POOL_SIZE = 50;

Next points to the next available message;

SPoolSync is mainly used for synchronization to ensure the security of multiple threads;

Message sPool; here, sPool is used to indicate an available message. Note that this is a static modified message,

SPoolSize is used to record the number of messagel in the current message object pool.

Finally, Let's explain: the message contains real-time maintenance. A single necklace table structure is used to save the message object! Next always points to the next message object. The sPool here is obviously the header of the linked list. In this way, you can traverse the message in the entire object pool in sequence through the header.

As I mentioned above, when obtainMessage () is used to obtain a message, it will go to the object pool for retrieval (here we will go to this one-way linked list for retrieval ), if there is no message in the object pool, a new message will be generated. let's take a look at the code to prove what I said.

    public static Message obtain() {        synchronized (sPoolSync) {            if (sPool != null) {                Message m = sPool;                sPool = m.next;                m.next = null;                sPoolSize--;                return m;            }        }        return new Message();    }

The code above shows that if the linked list is not null, the message of the linked list header is taken, and the head of the linked list is moved down. If it is not found, the new Message () is returned ().

Finally, how does one add a message to the linked list after it is used up? Through the Message. java file, you will find that a public method is also defined in the Message:

    public void recycle() {        clearForRecycle();        synchronized (sPoolSync) {            if (sPoolSize < MAX_POOL_SIZE) {                next = sPool;                sPool = this;                sPoolSize++;            }        }    }

Through the code above, we can know that the recycle method is actually adding this message to the linked list (to the header). So when will this method be called?

In fact, when a message is sent through Handler, the message is actually determined based on its delay and added to the MessageQueue in a queue, the MessageQueue operation is not only the Handler, but also the Logoff of the Handler.

In fact, every Handler requires a logoff. When we create a Handler, we do not specify its logoff, however, he will automatically obtain the Logoff of the thread that creates the Handler as his own logoff. Therefore, in android, The logoff of the Handler is often not specified, in fact, it is logoff with the main thread (the ui thread we often call.

As we said just now, Handler's logoff actually also operates MessageQueue. In fact, a logoff actually requires a MessageQueue. My personal understanding is: logoff aims to operate MessageQueue, handler controls logoff and MessageQueue.

In real time, the Handler adds the message to be processed to the MessageQueue, while the logoff extracts the message to be processed from the MessageQueue to start the processing process.

In logoff, the call method loop () is used to retrieve and process the message to be processed. After processing, the recycle () of the message will be called (), add the processed message to the object pool!