android - Handlers 与 Threads 有任何真正的性能影响吗？

Question

关于 Threads 与 Handlers 与 AsyncTask 的正确使用存在许多问题。 (比如 here 和 here )

这些问题很好地解决了何时使用什么的问题。我的问题更多是关于某些类型案例中的性能影响。

例如，我经常看到其他人在编写代码时使用 Threads 只是为了能够为将来安排一些代码执行。每当我看到这个时，我本能地想要重构代码以使用 Handler 并且只是发布一个延迟的 runnable。

这是一个示例，其中线程用于更新使用 mediaplayer 播放的某些媒体的搜索栏，然后是我执行此操作的方式。

我经常看到的:

 if (positionTracker != null && positionTracker.isAlive()
                && !positionTracker.isInterrupted()) {
            return;
        }

        positionTracker = new Thread(new Runnable() {

            public void run() {
                int currentPosition = 0;
                int total = player.getDuration();
                while (player != null && CurrentPosition < total) {
                    try {
                        Thread.sleep(1000);
                        currentPosition = player.getCurrentPosition();
                    } catch (InterruptedException e) {
                        return;
                    } catch (Exception e) {
                        return;
                    }


                    if (someListener != null) {
                        someListener.onEvent();
                    }

                }
            }

        }, "position tracker thread");

        positionTracker.start();

以及我喜欢的方式:

Runnable trackPositionRunnable = new Runnable() {
            @Override
            public void run() {
                currentPosition = player.getCurrentPosition();
                if (someListener != null) {
                    someListener.onEvent();
                    mHandler.postDelayed(this, 1000);
                }
            }
        };

        mHandler.post(trackPositionRunnable);

显然，我更喜欢的方式更易于阅读且更简洁。 但是性能影响是什么？就性能而言，一种方法是否比另一种方法更好？如果是，为什么？

Answer 1

每种方法都取决于您计划在该 Runnable 中执行的操作，以确定它是否有用。它们之间最大的区别在于您是否打算触摸 UI。在 Android 中，您不能从 UI 线程中触摸 UI 组件(您的媒体播放器示例使用原始线程打破了此规则)。由于这条规则立即划分了每种方法可以做什么和不能做什么。这些方法之间的性能差异可以忽略不计，因为运行后台作业所花费的时间将超过它们之间的任何差异。

Handler 通常使用另一个后台线程来执行逻辑，但这取决于哪个线程构建了 Handler。如果处理程序是在 UI 线程上构建的(响应回调 onSomething)，那么您的 Runnable 将在 UI 线程内运行，从而可以触摸 UI 组件。但是，如果您在发布到它的 UI 线程 Runnables 之外创建它，则不能触及 UI 组件。在 UI 线程上创建处理程序的缺点是您不能在后台执行这些操作，因此如果作业需要很长时间才能运行，它将锁定 UI 直到完成。虽然从非 UI 线程运行的处理程序将解决锁定 UI 的任何问题。它们需要更多的设置工作，您仍然需要考虑如何安全地更新 UI 以响应您的后台作业(即，如果您想要更新 UI，您仍然需要将另一个可运行对象发布回 UI 线程)。

原始线程不会锁定 UI，因为它们独立于 UI 线程运行，但您不能触及它们上的 UI 组件。这意味着您必须在 UI 线程上执行任何要更新 UI 的代码，这意味着需要编写更多代码才能让 UI 线程运行它。这可能非常复杂。原始线程确实应该避免使用，因为使用它们很复杂。

后台任务最常见的例子是等待服务器的响应。大多数库会阻塞，直到服务器发送响应，这意味着您不能在 UI 线程上调用它们，否则您的用户将被阻止执行任何操作，直到服务器返回调用为止。它们不仅会被阻止，而且 UI 也无法自行更新以显示微调器或以其他方式看起来很活跃。这最好推到后台线程。从技术上讲，处理程序和线程可以做到这一点，但必须专门构造处理程序，以便它们使用真正的后台线程。

这是 AsyncTask 胜过 Handlers 的地方，因为它同时执行真正的后台作业和 UI 更新。它有一个部分用于在后台执行一些长时间运行的操作，还有一个部分用于在完成后从 UI 线程更新 UI。它甚至有一个可选的进度部分，因此您可以在任务运行时向 UI 提供任何中间进度。 AsyncTask 的缺点是它们必须有一个结束。继续运行以定期检查是否发生了什么、休眠并检查更多的后台作业不利于 AsyncTask 模型。但是，这并不是说您不能使用 Handler 定期启动 AsyncTask，只是为了讨论的完整性，我提到了这一点。

最后，使用原始线程并不是那么容易甚至“更好”，因为处理程序几乎可以用更少的代码完成线程可以做的任何事情。但是，处理程序很难确定 Runnable 在哪个线程上执行。大多数情况下是 UI 线程，从技术上讲，将其设置为使用非 UI 线程是很棘手的。这两个选项都存在 UI 更新问题，因为您必须做额外的工作才能在真正的后台作业结束时运行 UI 作业。 AsyncTask 确实是我执行后台作业的首选方法。