为什么主线程的 Looper.loop() 不阻塞 UI 线程？

Question

今天我阅读了一些关于 Handler 和 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 的源代码中读到的那样。处理消息队列然后派发消息供回调处理是一个无限循环。

根据这个，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();
    }
}

Answer 1

其实主线程中的Looper就是允许绘图的。当视图失效时，一条消息会传递给主 Looper，告诉它已请求绘制。当 Looper 处理该消息时，实际绘制发生。其他 activity 阻止 UI 线程阻止绘图的原因是它阻止 Looper 处理该绘图消息。

从 Windows 到 Mac 再到 Android。

这或多或少是在任何基于事件的系统中的绘图方式。

为什么不立即绘制而不是发送消息？表现。画的很慢。如果您为响应一个事件而进行多项更改，您不希望为每一项都重绘屏幕。这样做意味着您将处理单个事件的所有重绘集中到 1 个重绘中。例如，如果您设置 1 个视图的文本和另一个视图的图像，它们将同时重绘，并且只重绘一次。

Answer 2

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

开始的

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

所有的更新回调都是由消息引起的，这些消息来自于系统服务，比如ActivityManagerService， InputManagerService、WindowMangerService。如果需要更新UI，android服务会通过IPC向循环发送消息。

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

为什么主线程的 Looper.loop() 不阻塞 UI 线程？

Why main thread's Looper.loop() doesn't block UI thread?

multithreading

android

handler

looper

android-looper