为什么主线程的Looper.loop()不会阻止UI线程?

时间:2016-03-11 03:55:42

标签: android multithreading handler looper android-looper

今天我读了一些关于Handler& amp;的博客和源代码。 Looper一起工作。

根据我所学到的,我们可以使用ThreadLocal魔法在每个线程上只有一个Looper。通常Handler是在主线程中启动的,否则你必须在一个单独的线程上手动启动或说出prepare Looper,然后将其循环。

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

让我感到困惑的是主线程中的loop()。正如我在Looper的源代码中读到的那样。这是一个无限循环来处理消息队列,然后调度消息以便回调处理。

根据这个https://stackoverflow.com/a/5193981/2290191,Handler和它的Looper在同一个线程中运行。

如果主线程上有无限循环,它是否会阻止整个UI系统?

我知道我必须如此愚蠢才能错过一些东西。但是,如果有人透露这背后的秘密,那将是可爱的。

public static void loop() {
    final Looper me = myLooper();
    if (me == null) {
        throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
    }
    final MessageQueue queue = me.mQueue;

    // Make sure the identity of this thread is that of the local process,
    // and keep track of what that identity token actually is.
    Binder.clearCallingIdentity();
    final long ident = Binder.clearCallingIdentity();

    for (;;) {
        Message msg = queue.next(); // might block
        if (msg == null) {
            // No message indicates that the message queue is quitting.
            return;
        }

        // This must be in a local variable, in case a UI event sets the logger
        Printer logging = me.mLogging;
        if (logging != null) {
            logging.println(">>>>> Dispatching to " + msg.target + " " +
                    msg.callback + ": " + msg.what);
        }

        msg.target.dispatchMessage(msg);

        if (logging != null) {
            logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
        }

        // Make sure that during the course of dispatching the
        // identity of the thread wasn't corrupted.
        final long newIdent = Binder.clearCallingIdentity();
        if (ident != newIdent) {
            Log.wtf(TAG, "Thread identity changed from 0x"
                    + Long.toHexString(ident) + " to 0x"
                    + Long.toHexString(newIdent) + " while dispatching to "
                    + msg.target.getClass().getName() + " "
                    + msg.callback + " what=" + msg.what);
        }

        msg.recycleUnchecked();
    }
}

2 个答案:

答案 0 :(得分:3)

实际上主线程中的Looper是允许绘图的。当视图无效时,会向主Looper传递一条消息,告知它已请求绘制。当Looper处理该消息时,会发生实际绘图。阻止UI线程的其他活动阻止绘图的原因是它阻止Looper处理该绘制消息。

这或多或少是绘图在任何基于事件的系统中的工作方式,从Windows到Mac再到Android。

为什么不立即绘制而不是发送消息?性能。绘图很慢。如果您针对某个事件进行了多项更改,则不希望为每个事件重新绘制屏幕。这样做意味着您将所有重绘用于将单个事件处理为1次重绘。例如,如果您设置1个视图的文本和另一个视图的图像,它们将同时重绘,并且只重绘一次。

答案 1 :(得分:1)

这个问题是一个微妙的陷阱。为什么无限循环不会阻止UI线程,因为所有UI线程行为都是从msg.next开始的。

如果没有消息,则表示不需要更新。我们所有的代码都只是一个回调,例如Application onCreate,Activit onCreate,BroadcastReceiver onReceive。

所有更新回调都是由消息引起的,这些消息来自系统服务,例如ActivityManagerService, InputManagerService,WindowMangerService。如果您需要更新UI,Android服务将通过IPC向循环发送消息。

所以无限循环是无限更新。