问题
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? :)
回答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.
回答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()
callspublic 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 overridehandleMessage()
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();
}
回答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();
}
}
回答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)
来源:https://stackoverflow.com/questions/5193913/handlers-messagequeue-looper-do-they-all-run-on-the-ui-thread