有关正确使用Threadsvs. Handlersvs. 的问题有很多AsyncTask.(像这里和这里)
这些问题很好地解决了何时使用什么问题.我的问题更多的是关于某些类型案件的绩效影响.
作为一个例子,我经常看到其他人编写代码,他们只使用Threads这些代码来为将来安排一些代码执行.每当我看到这一点时,我本能地感觉要重构代码以使用a Handler而只是延迟发布一个帖子runnable.
这是一个示例,其中一个Thread用于更新某些媒体播放的搜索栏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();
Run Code Online (Sandbox Code Playgroud)
我喜欢这样做的方式:
Runnable trackPositionRunnable = new Runnable() {
@Override
public void run() {
currentPosition = player.getCurrentPosition();
if (someListener != null) {
someListener.onEvent();
mHandler.postDelayed(this, 1000);
}
}
};
mHandler.post(trackPositionRunnable);
Run Code Online (Sandbox Code Playgroud)
显然,我喜欢的方式是更容易阅读和更简洁.但是性能影响是什么?在性能方面,单向方法比其他方法更好吗?如果是这样,为什么?
正确性:您的第一个示例充满了危险,因为 aMediaPlayer必须在具有自己的线程上创建Looper,并且来自任何其他线程的操作可能会导致错误。同样,由于您someListener.onEvent()可能正在更新 UI,因此最好知道无论如何都要发布到 UI 线程上的处理程序。
性能:我没有提供任何测量结果,但在您的示例中,运行时成本是(线程切换)+(处理程序开销),而不是(处理程序开销)。因此,对于任何线程切换开销 > 0 的情况,线程的成本都更高。另一方面,如果您的整个应用程序都是按照您喜欢的风格进行编码的,并且您的任何代码片段都是缓慢且同步的,那么您只会让您的应用程序感觉滞后。
这就是为什么任何可能缓慢或同步的事情都需要转向线程(或服务)风格,尽管感觉更复杂且容易出错。您的特定 MediaPlayer 示例并不是说明此情况的完美典范。
| 归档时间: |
|
| 查看次数: |
3498 次 |
| 最近记录: |