Handlers, MessageQueue, Looper, do they all run on the UI thread?

Question

I'm trying to wrap my head around threading, and I know that I may use a Handler to post messages/runnables to the MessageQueue, which in turn gets picked up by the Looper and sent back to the Handler for processing.

If I post to a Handler in my activity, is the Activity, Handler, MessageQueue and Looper all running on the UI thread? If not, could someone please explain how this all comes together? :)

Glantz

Answer 1

Short answer: they all run on the same thread. If instantiated from an Activity lifecycle callback, they all run on the main UI thread.

Long answer:

A thread may have a Looper, which contains a MessageQueue. In order to use this facility, you would have to create a Looper on the current thread by calling (the static) Looper.prepare(), and then start the loop by calling (the also static) Looper.loop(). These are static because there is only supposed to be one Looper per thread.

The call to loop() usually does not return for some time, but keeps taking messages ("tasks", "commands" or whatever you like to call them) out of the MessageQueue and handles them individually (e.g. by calling back a Runnable contained in the message). When there are no messages left in the queue, the thread blocks until there are new messages. To stop a Looper, you have to call quit() on it (which probably does not stop the loop immediately, but rather sets a private flag that is checked periodically from the loop, signaling the it to stop).

However, you cannot add messages to the queue directly. Instead, you register a MessageQueue.IdleHandler to wait for a queueIdle() callback, in which you can decide if you wish to to something or not. All handlers are called in turn. (So the "queue" isn't really a queue, but instead a collection of callbacks to be called regularly.)

Note regarding the previous paragraph: This I actually guessed. I couldn't find any documentation on that, but it would make sense.

update: see ahcox' comment and his answer.

Because this is a lot of work, the framework provides the Handler class to simplify things. When you create a Handler instance, it is (by default) bound to the Looper already attached to the current thread. (The Handler knows what Looper to attach to because we called prepare() earlier, which probably stored a reference to the Looper in a ThreadLocal.)

With a Handler, you can just call post() to "put a message into the thread's message queue" (so to speak). The Handler will take care of all the IdleHandler callback stuff and make sure your posted Runnable is executed. (It might also check if the time is right already, if you posted with a delay.)

Just to be clear: the only way to actually make a looping thread do something is to post a message to it's loop. This is valid until you call quit() on the looper.

---

Regarding the android UI thread: At some point (probably before any activities and the like are created) the framework has set up a Looper (containing a MessageQueue) and started it. From this point on, everything that happens on the UI thread is through that loop. This includes activity lifecycle management and so on. All callbacks you override (onCreate(), onDestroy()...) are at least indirecty dispatched from that loop. You can see that for example in the stack trace of an exception. (You can try it, just write int a = 1 / 0; somewhere in onCreate()...)

---

I hope this makes sense. Sorry for being unclear previously.

Escallop

But in the Looper.loop() method there is an endless loop set up where messages are picked from the MessageQueue, how come this doesn't lock up everything else happening on the UI thread? – Glantz

I'm sorry for my questions being vague, but I'm still a little confused. I get the part about connecting to an existing looper. But that existing looper will also contain this endless loop I'm talking about. I don't understand how this can run in any thread without locking up everything else happening in that same thread? – Glantz

Excellent, thanks a lot for clearing that up! The last section about the UI thread confirmed my sneaking suspicion. – Glantz

Btw. instead of causing an Exception to occur you can just throw one. throw new RuntimeException("FooBar"); You can't however do that in the middle of a code block, because it would make the compiler will complain that the rest of the block will never be executable. However, you can trick it by doing it like this: if (true) {throw new RuntimeException("Got ya!");} I like to use this my self as your intentions are more clear than with something like doing an intentional arithmetic error. – Lurk

That is a very helpful answer. Just to clarify on your point of uncertainty, there is a real queue in the MessageQueue. Message contains a reference to a Message which MessageQueue uses to form an intrusive linked list queue. You can see Messages being grabbed from the front of it in MessageQueue.pullNextLocked() (non-public method). Only if this message queue is empty do the idle handlers get called. The final resort is for the thread to wait for the next delayed Message's deadline, or for a new Message to turn up. – Logistician

@rogerkk: Regarding the thread "lockup" you mention -- you're right, it loops around endlessly, picking up the next message or runnable that comes around. And it won't lock up so much as take whatever time it needs in order to process that message or runnable, posted from another thread. This is precisely why it's bad to run lengthy operations on the UI thread, as the system will complain with an ANR if you do so. But running the loop on a non-UI thread is fine -- it's simply a nonstop message handling loop, processing each one-by-one. – Torray

Is it possible to find out how many messages are left in the queue? For example, in the handleMessage() function I'd like to show in the logcat "processing Message x of y" for debugging. Or, "There are y Messages left to process" – Cristiano

Answer 2

Following up on the "how it all comes together" part of the question. As user634618 wrote, the looper takes over a thread, the main UI thread in the case of an application's main Looper.

• Looper.loop() pulls Messages out of its message queue. Each Message has a reference to an associated Handler that it is to be given back to (the target member).
• Inside Looper.loop() for each message gotten from the queue:
  • loop() calls public void Handler.dispatchMessage(Message msg) using the Handler that is stored in the Message as its target member.
  • If the message has a Runnable callback member, that is run.
  • Else, if the Handler has a shared callback set, that is run.
  • Else, Handler's handleMessage() is called with the Message as an argument. (Note, if you subclass Handler as AsyncTask does, you could override handleMessage() as it does.)

On your question about all the collaborating objects being on the same UI thread, a Handler must be created on the same thread as the Looper that it will send messages to. Its constructor will lookup the current Looper and store it as a member, tying the Handler to that Looper. It will also reference that Looper's message queue directly in its own member. The Handler can be used to send work to the Looper from any thread, but this identity of the message queues routes the work to be done on the Looper's thread.

When we are running some code on another thread and want to send a Runnable to be executed on the UI thread, we could do it like this:

// h is a Handler that we constructed on the UI thread.
public void run_on_ui_thread(final Handler h, final Runnable r)
{
   // Associate a Message with our Handler and set the Message's
   // callback member to our Runnable:
   final Message message = Message.obtain(h, r);

   // The target is the Handler, so this asks our Handler to put
   // the Message in its message queue, which is the exact same
   // message queue associated with the Looper on the thread on
   // which the Handler was created:
   message.sendToTarget();
}

Logistician

Excellent insight! Thanks. – Cantata

Answer 3

I try to implement these interface by myself in order to understand the concept. By simplicity, just use interface by necessary. Here is my test code:

import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;

public class TestLooper {

    public static void main(String[] args) {
        UIThread thread = new UIThread();
        thread.start();

        Handler mHandler = new Handler(thread.looper);
        new WorkThread(mHandler, "out thread").run();
    }
}

class Looper {
    private BlockingQueue<Message> message_list = new LinkedBlockingQueue<Message>();

    public void loop() {

        try {
            while (!Thread.interrupted()) {
                Message m = message_list.take();
                m.exeute();
            }
        } catch (InterruptedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }

    }

    public void insertMessage(Message msg) {
        message_list.add(msg);
    }

}

class Message {
    String data;
    Handler handler;

    public Message(Handler handler) {
        this.handler = handler;
    }

    public void setData(String data) {
        this.data = data;
    }

    public void exeute() {
        handler.handleMessage(this);
    }
}

class Handler {

    Looper looper;

    public Handler(Looper looper) {
        this.looper = looper;
    }

    public void dispatchMessage(Message msg) {
        System.out.println("Handler dispatchMessage" + Thread.currentThread());
        looper.insertMessage(msg);
    }

    public Message obtainMessage() {
        return new Message(this);
    }

    public void handleMessage(Message m) {
        System.out.println("handleMessage:" + m.data + Thread.currentThread());
    }
}

class WorkThread extends Thread {
    Handler handler;
    String tag;

    public WorkThread(Handler handler, String tag) {
        this.handler = handler;
        this.tag = tag;
    }

    public void run() {
        System.out.println("WorkThread run" + Thread.currentThread());
        Message m = handler.obtainMessage();
        m.setData("message " + tag);
        handler.dispatchMessage(m);
    }
}

class UIThread extends Thread {

    public Looper looper = new Looper();

    public void run() {

            //create handler in ui thread
        Handler mHandler = new Handler(looper);

        new WorkThread(mHandler, "inter thread").run();
        System.out.println("thead run" + Thread.currentThread());
        looper.loop();
    }

}

Unbounded

Answer 4

If I post to a handler in my activity, is the Activity, Handler, MessageQueue and Looper all running on the UI thread? If not, could someone please explain how this all comes together? :)

It depends on how you create Handler

Case 1:

Handler()

Default constructor associates this handler with the Looper for the current thread.

If you create Handler like this in UI thread, Handler is associated with Looper of UI Thread. MessageQueue is also associated with Looper with UI Thread.

Case 2:

Handler (Looper looper)

Use the provided Looper instead of the default one.

If I create a HandlerThread and pass the Looper of HandlerThread to Handler, Handler and Looper are associated with HandlerThread and not UI Thread. Handler, MessageQueue and Looper are associated with HandlerThread.

Use case: You want to execute a Network OR IO operation. You can't execute it on UI Thread and hence HandlerThread is handy for you.

 HandlerThread handlerThread = new HandlerThread("NetworkOperation");
 handlerThread.start();
 Handler requestHandler = new Handler(handlerThread.getLooper());

If you want to pass data back from HandlerThread to UI Thread, you can create one more Handler ( say responseHandler ) with Looper from UI Thread and call sendMessage. The UI Thread responseHandler should override handleMessage

Refer to these posts for more details.

What is the purpose of Looper and how to use it? ( For concepts )

Android: Toast in a thread ( For example code by linking all these concepts)

Haunted