AsyncTask中cancel方法的误读

你是否遇到过使用AsyncTask做下载逻辑时，在下载进行到一半点击返回键，然后再次回到下载界面时，线程并未立即执行，而是过一段时间之后才开始。为了究其原因，我写了个Demo进行了下验证。

Demo很简单，主要就是展示一个进度条，在doInBackground中用一个for循环来定时发送publishProgress(i)，在onProgressUpdate中接受传递过来的i，然后让进度条进行显示。

运行后你会发现进度条会按照既定设定进行百分比显示，但是后来你就发现，一旦你在显示过程中点击返回键退出程序，然后再次进入程序，你会发现进度条并未立即显示，而是等了一段时间后才开始运行。原因就是AsyncTask维护了一个线程池，你点击返回的时候并未结束当前线程的执行，所以你再次打开的时候，系统会先将上一次的线程结束之后，再开始新的线程。

解决方案，我们需要在退出时候给线程发送一个线程终止的操作，让当前线程停下来，这样才能在下次开始时候立即运行新线程。这就有用到了生命周期的相关概念了，具体可以参考我的另一篇文章：项目中回退Fragment导致界面刷新的猜想。我们在onPause中进行停止线程操作，代码如下：

@Override    protected void onPause() {        // TODO Auto-generated method stub        super.onPause();        if(myTask != null && myTask.getStatus() == AsyncTask.Status.RUNNING){            myTask.cancel(true);        }    }

之后再次运行程序，咦，发现问题依旧，原因是cancel()方法并非是直接停止当前线程，而是发送一个停止线程的状态位，也就是说将线程池中的某个控制状态的标志位变为CANCEL状态。于是我们还需要继续进行编码，在发送进度的时候判断下线程是否取消状态，即isCancelled()，如果是，break或者return出去。

OK了，再次运行程序，看下是否可以立即执行了？

小结下：写本篇文章的目的就是让大家知道并非cancel方法就能立即终止线程，并非所有的方法是见名知意，这个以后得多加注意。另外就是我发现好多涉及到线程的代码，只是写了线程运行时候的各种操作，而不去考虑线程何时终止，终止后有何操作的逻辑，会无故引发很多的bug。

具体文中Demo代码的下载地址