5

今天我阅读了一些关于 Handler 和 Looper 如何协同工作的博客和源代码。

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

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

2 回答 2

6

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

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

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

于 2016-03-11T04:19:34.163 回答
2

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

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

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

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

于 2017-04-13T08:11:41.047 回答