Process (1) 1.6 asynchronous processing of dakers in Android-handler and handlerthread

I wonder if you have found that there is a constructor in handler that passes in the logoff object of a message loop. As mentioned in 1.2, 1.3,If a handler object cannot be created in a normal subthread, because it does not own a loose object, and the main thread itself carries this object, the handler object is taken out from the main thread.Therefore, for convenience, do not create a message loop by the developer. Therefore, an external handlerthread class is provided.

Handlerthread inherits from thread, so it is itself a thread. It is similar to creating a Thread class containing a logoff object, and logoff can be used to create a handler class. In this way, we don't have to instantiate the logoff object and call preare and loop, but directly call handlerthread. Compared with a normal thread, logoff objects are added.

The demo about handlerthread written by Mars is as follows:

Package COM. lilin. logoff; import android. app. activity; import android. OS. bundle; import android. OS. handler; import android. OS. handlerthread; import android. OS. logoff; import android. OS. message; public class handlerddemo extends activity {protected void oncreate (bundle savedinstancestate) {super. oncreate (savedinstancestate); setcontentview (R. layout. main); system. out. println ("ID of the current activity -->" + thread. currentthread (). GETID (); handlerthread = new handlerthread ("handler_thread"); // generates a handlerthread object to implement the function of using logoff to process message queues, handlerthread is provided by the Android Application Framework. start (); // before using the getlooper () method of handlerthread, you must call start () of this class; myhandler = new myhandler (handlerthread. getlooper (); // generates a message loop message MSG = myhandler. obtainmessage (); bundle B = new bundle (); B. putint ("Age", 20); B. putstring ("name", "Jhon"); MSG. setdata (B); // store the data to message MSG. sendtotarget (); // send MSG to the target object. The so-called target object is the handler object that generates the MSG object} class myhandler extends handler {public myhandler () {} public myhandler (low.logoff) {super (logoff) ;}@ overridepublic void handlemessage (Message MSG) {bundle B = MSG. getdata (); // get data int age = B from message. getint ("Age"); string name = B. getstring ("name"); system. out. println ("Age is" + age + ", name is" + name); system. out. println ("handler id -->" + thread. currentthread (). GETID ());}}}

From the above example, it is not difficult to find that handlerthread and hander are not the main thread, which is different from post runable in 1.3 (which is in the same thread ). However, I would like to remind you that this does not mean that the post runable or send message method is not asynchronous. In fact, it is also asynchronous, but the process of generating a message loop is handed over to the system, source code for the previous copy:

This is called by the system:

class LooperThread extends Thread {      public Handler mHandler;       public void run() {          Looper.prepare();           mHandler = new Handler() {          public void handleMessage(Message msg) {                // process incoming messages here             }        };        Looper.loop();}

The source code in handlerthread:

    public void run() {        mTid = Process.myTid();        Looper.prepare();        synchronized (this) {            mLooper = Looper.myLooper();            notifyAll();        }        Process.setThreadPriority(mPriority);        onLooperPrepared();        Looper.loop();        mTid = -1;    }

After comparing the two codes, we can see that lorule. Prepare (); is called here. As for the creation of a message loop, handler is generated in the constructor without parameters, while handlerthread is directly generated in the run method, and then passed in through the constructor of handler.