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? :)

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.

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(); }