从非 UI 线程调用 Snackbar.make() 是如何工作的？

Question

我可以毫无问题地从后台线程调用Snackbar.make()。这让我感到惊讶，因为我认为 UI 操作只允许来自 UI 线程。但这绝对不是这里的情况。

究竟是什么让Snackbar.make() 与众不同？为什么当您从后台线程修改它时，它不会像任何其他 UI 组件一样导致异常？

Answer 1

首先：make() 不执行任何 UI 相关操作，它只是创建一个新的Snackbar 实例。是对show() 的调用实际上将Snackbar 添加到视图层次结构中并执行其他危险的UI 相关任务。但是，您可以从任何线程安全地执行此操作，因为它被实现为在 UI 线程上安排任何显示或隐藏操作，无论哪个线程调用 show()。

更详细的答案让我们仔细看看Snackbar的源代码中的行为：

---

让我们从你的电话show()开始吧：

public void show() {
    SnackbarManager.getInstance().show(mDuration, mManagerCallback);
}

如您所见，对show() 的调用获取SnackbarManager 的实例，然后将持续时间和回调传递给它。 SnackbarManager 是一个单例。它负责显示、调度和管理Snackbar 的类。现在让我们继续在SnackbarManager 上实现show()：

public void show(int duration, Callback callback) {
    synchronized (mLock) {
        if (isCurrentSnackbarLocked(callback)) {
            // Means that the callback is already in the queue. We'll just update the duration
            mCurrentSnackbar.duration = duration;

            // If this is the Snackbar currently being shown, call re-schedule it's
            // timeout
            mHandler.removeCallbacksAndMessages(mCurrentSnackbar);
            scheduleTimeoutLocked(mCurrentSnackbar);
            return;
        } else if (isNextSnackbarLocked(callback)) {
            // We'll just update the duration
            mNextSnackbar.duration = duration;
        } else {
            // Else, we need to create a new record and queue it
            mNextSnackbar = new SnackbarRecord(duration, callback);
        }

        if (mCurrentSnackbar != null && cancelSnackbarLocked(mCurrentSnackbar,
                Snackbar.Callback.DISMISS_EVENT_CONSECUTIVE)) {
            // If we currently have a Snackbar, try and cancel it and wait in line
            return;
        } else {
            // Clear out the current snackbar
            mCurrentSnackbar = null;
            // Otherwise, just show it now
            showNextSnackbarLocked();
        }
    }
}

现在这个方法调用有点复杂。我不打算详细解释这里发生了什么，但总的来说，围绕它的synchronized 块确保了对show() 的调用的线程安全。

在synchronized 块内，如果您两次show() 相同的时间，经理会负责关闭当前显示的Snackbars 更新持续时间或重新安排时间，当然还会创建新的Snackbars。对于每个Snackbar，都会创建一个SnackbarRecord，其中包含最初传递给SnackbarManager的两个参数，持续时间和回调：

mNextSnackbar = new SnackbarRecord(duration, callback);

在上面的方法调用中，这发生在中间，在第一个 if 的 else 语句中。

然而，唯一真正重要的部分——至少对于这个答案来说——就在底部，即对showNextSnackbarLocked()的调用。这就是魔法发生的地方，下一个 Snackbar 排队 - 至少有点。

这是showNextSnackbarLocked()的源码：

private void showNextSnackbarLocked() {
    if (mNextSnackbar != null) {
        mCurrentSnackbar = mNextSnackbar;
        mNextSnackbar = null;

        final Callback callback = mCurrentSnackbar.callback.get();
        if (callback != null) {
            callback.show();
        } else {
            // The callback doesn't exist any more, clear out the Snackbar
            mCurrentSnackbar = null;
        }
    }
}

正如您首先看到的，我们通过检查 mNextSnackbar 是否不为空来检查 Snackbar 是否排队。如果不是，我们将SnackbarRecord 设置为当前Snackbar 并从记录中检索回调。现在发生了一些事情，在进行一次简单的 null 检查以查看回调是否有效之后，我们在回调上调用 show()，这是在 Snackbar 类中实现的 - 而不是在 SnackbarManager 中实现的 - 实际显示Snackbar 在屏幕上。

起初这可能看起来很奇怪，但它很有意义。 SnackbarManager 只负责跟踪Snackbars 的状态并协调它们，它并不关心Snackbar 的外观、显示方式甚至是什么，它只是调用show() 方法正确的回调在正确的时间告诉Snackbar展示自己。

---

让我们倒带一下，到目前为止，我们从未离开过后台线程。 SnackbarManager 的 show() 方法中的 synchronized 块确保没有其他 Thread 可以干扰我们所做的一切，但是在主 Thread 上安排显示和关闭事件的内容仍然缺失。然而，当我们查看 Snackbar 类中回调的实现时，这种情况现在会改变：

private final SnackbarManager.Callback mManagerCallback = new SnackbarManager.Callback() {
    @Override
    public void show() {
        sHandler.sendMessage(sHandler.obtainMessage(MSG_SHOW, Snackbar.this));
    }

    @Override
    public void dismiss(int event) {
        sHandler.sendMessage(sHandler.obtainMessage(MSG_DISMISS, event, 0, Snackbar.this));
    }
};

因此，在回调中，一条消息被发送到静态处理程序，MSG_SHOW 显示Snackbar 或MSG_DISMISS 再次隐藏它。 Snackbar 本身作为有效负载附加到消息中。现在，只要我们查看该静态处理程序的声明，我们就差不多完成了：

private static final Handler sHandler;
private static final int MSG_SHOW = 0;
private static final int MSG_DISMISS = 1;

static {
    sHandler = new Handler(Looper.getMainLooper(), new Handler.Callback() {
        @Override
        public boolean handleMessage(Message message) {
            switch (message.what) {
                case MSG_SHOW:
                    ((Snackbar) message.obj).showView();
                    return true;
                case MSG_DISMISS:
                    ((Snackbar) message.obj).hideView(message.arg1);
                    return true;
            }
            return false;
        }
    });
}

所以这个处理程序在 UI 线程上运行，因为它是使用 UI 循环器创建的（如 Looper.getMainLooper() 所示）。消息的有效负载 - Snackbar - 被强制转换，然后根据消息的类型在 Snackbar 上调用 showView() 或 hideView()。 这两种方法现在都在 UI 线程上执行！

这两种方法的实现都有些复杂，所以我不会详细介绍它们中究竟发生了什么。但是很明显，这些方法负责将View 添加到视图层次结构中，在它出现和消失时对其进行动画处理，处理CoordinatorLayout.Behaviours 和其他有关UI 的内容。

如果您有任何其他问题，请随时提出。

---

滚动浏览我的答案，我意识到这比预期的要长方式，但是当我看到这样的源代码时，我情不自禁！我希望你能欣赏一个长而深入的回答，或者我可能只是浪费了几分钟的时间！

Answer 2

Snackbar.make 完全不会被非 ui 线程调用。它在其管理器中使用了一个处理程序，该处理程序在主循环器线程上运行，从而将调用者隐藏在它的底层复杂性中。

Answer 3

只有创建视图层次结构的原始线程才能接触其视图。

如果您使用 onPostExecute，您将能够访问视图

protected void onPostExecute(Object object) { .. }