android–HandlersvsThreads是否有任何真正的性能影响？

关于Threads vs. Handlers与AsyncTask的正确使用有很多问题. (如here和here)

这些问题很好地解决了何时使用什么问题.我的问题更多的是关于某些类型案件的绩效影响.

作为一个例子,我经常看到其他人编写代码,他们使用Threads只是为了能够为将来安排一些代码执行.每当我看到这一点时,我本能地感觉要重构代码以使用Handler而只是发布一个延迟的runnable.

下面是一个示例,其中一个Thread用于更新某些媒体播放器的搜索栏,然后是我的方式.

我看到了很多东西：

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


显然,我喜欢的方式是更容易阅读和更简洁.但是性能影响是什么？在性能方面,单向方法比其他方法更好吗？如果是这样,为什么？

解决方法:

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

处理程序通常使用另一个后台线程来执行逻辑,但它取决于构造处理程序的线程.如果Handler是在UI Thread上构建的(响应于回调onSomething),那么Runnable将在UI Thread内部运行,这使得触摸UI组件成为可能.但是,如果您在UI线程上创建了Runnables,则无法触及UI组件.在UI线程上创建的处理程序的缺点意味着您没有在后台执行这些操作,因此如果作业需要很长时间才能运行,它将锁定UI直到完成.虽然从非UI线程运行的处理程序将修复锁定UI的任何问题.他们需要做更多的工作来设置,你仍然需要争论如何安全地更新UI以响应你的后台工作(即如果你想更新UI,你仍然必须将另一个可运行的东西发回UI线程).

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

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

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

最后使用原始线程并不是那么简单甚至“更好”,因为处理程序可以做很多线程可以用更少的代码做的事情.但是,处理程序在确定Runnable正在执行哪个线程时很棘手.通常它是UI线程,并且技术上将其设置为使用非UI线程是棘手的.这两个选项都受到UI更新问题的影响,因为您必须在真正的后台作业结束时执行额外的工作来运行UI作业. AsyncTask是我做背景作业的首选方法.