Handler for Android source code analysis

According to the previous analysis, as Android doc said, Handler is mainly useful in two aspects:

1. delay executes an operation in the same thread, that is, schedule message and runnable will be executed at a certain time in the future;

2. Send message and runnable to another thread so that an operation can be executed in another thread. For example, if thread A can get thread B

Handler can use this handler to process these messages in thread B through post message and runnable in thread.

Communication between threads. AsyncTask sends messages to the UI thread by associating the handler of the UI thread in the background thread. To see

For more information, here is a typical example given at the beginning of logoff. java:

LooperThread =View Code

Here, other threads can communicate with it through LooperThread. mHandler.

Next, let's take a look at the source code:

(Msg. callback! = (MCallback! =View Code

Only one handleMessage method in this Callback interface returns a boolean value, which will be used by the Handler ctor later. Generally, it is null. This interface exists

There is no special meaning, just to enable you to process messages without using extends Handler (as described in the doc in this method), similar to the relationship between Thread and Runnable interfaces.

Next is the dispatchMessage method, which we mentioned in the previous analysis of the Message. If callback is set for the message

Call the callback. run () method directly. Otherwise, the Callback interface will become effective. If we pass the implementation of the Callback interface, that is, mCallback is not empty, call it for processing.

Message. If consumed is processed, it will be returned directly. Otherwise, the Handler's handleMessage method will be called. The default implementation is do nothing. If you

It is extends Handler, so you should provide your own implementation for handleMessage in your subclass.

Next, let's first look at the key fields of Handler. The source code is as follows:

  mAsynchronous;

MQueue comes from mloue. mloue either explicitly specified in the ctor or default to the current thread. All Handler's processing of Message and Runnable is delegate to mQueue; mCallback is the Callback implementation provided by the user. The default value is null. mAsynchronous indicates whether the Handler is asynchronous. The default value is synchronous.

Next we will look at the various Handler cins (constructors ):

(, (Callback, (loopback, (loopback, callback, Handler (Callback callback, Class <? Handler> klass = (klass. isAnonymousClass () | klass. isMemberClass () | klass. isLocalClass () & Modifier. STATIC) = 0 "The following Handler class shocould be static or leaks might occur:" + = (mlowing = "Can't create handler inside thread that has not called loled. prepare () "=== Handler (Looper looper, Callback callback, ====View Code

Let's take a look at the versions of the three parameters, namely logoff, Callback, and boolean. By default, logoff is associated with the current thread, callback is null, and async is false. Of course, you can also specify these three values. You do not need to repeat the ctor. It is easy to understand the doc and comment.

Next, there are a bunch of Handler obtainMessage functions. The implementation is to directly call the static function obtain of Message, but the target field of the corresponding message is automatically set to the current Handler object. Because the source code of the Message has been analyzed in the previous article, it is mentioned here.

GetPostMessage (Runnable r) is also very simple, that is, package runnable into a Message, and its callback field is set to runnable.

The next bunch of postxxx and sendxxx will eventually call the following method:

  enqueueMessage(MessageQueue queue, Message msg, = 

Here, the target of the message is set to the current Handler. If it is an asynchronous Handler, the message is set to asynchronous and then queued. uptimeMillis indicates the absolute timestamp. Here, we need to mention the xxxAtFrontOfQueue method. This method may cause other messages in the queue to fail to be processed because it inserts the subsequent message in front of the queue ), or cannot be processed in time, so it is not good to jump into the queue and use it with caution. As described in the method doc, in our work and study, I strongly recommend that you take a closer look at the doc of the related classes and methods. I know that people like us do not like to write doc, so since we can have doc, it is really necessary and important.

Next is the removeCallbacks related, source code:

      , r,       

Its implementation is also delegate to mQueue. One thing to note is that these methods remove all Runnable r, instead of the First Matching

(Note that s in the method name is the plural rather than the singular number). That is to say, a single remove call can remove the same runnable from the previous post many times,

If the post runnable is still in the queue.

RemoveMessages, hasMessages, and other methods are simple and easy to explain.

The Handler class is analyzed here... (I am welcome to criticize and correct my skills)