Android AsyncTask解析

Posted 2020-08-07 huaxun66

我们都知道，android UI是线程不安全的，如果想要在子线程里进行UI操作，就需要借助Android的异步消息处理机制，参考之前一篇文章Android 异步消息处理机制：Looper、Handler、Message。但是费时的任务操作总会启动一些匿名的子线程，太多的子线程会给系统带来巨大的负担，随之带来一些性能问题。因此Android提供了一个工具类AsyncTask，顾名思义异步执行任务，使用它就可以非常灵活方便地从子线程切换到UI线程。

AsyncTask的基本用法

由于AsyncTask是一个抽象类，所以如果我们想使用它，就必须要创建一个子类去继承它。在继承时我们可以为AsyncTask类指定三个泛型参数Params，Progress和Result，这三个参数的用途如下：

• Params
  传入doInBackground()方法的参数类型。启动任务执行的输入参数，比如HTTP请求的URL。
• Progress
  传入onProgressUpdate()方法的参数类型。后台任务执行的百分比。
• Result
  传入onPostExecute()方法的参数类型，也是doInBackground()方法返回的类型。后台执行任务最终返回的结果，比如String,Integer等

AsyncTask的执行分为四个步骤，每一步都对应一个回调方法，开发者需要实现这些方法：

• onPreExecute()
  该方法将在执行实际的后台操作前被UI 线程调用。可以在该方法中做一些准备工作，如在界面上显示一个进度条，或者一些控件的实例化，这个方法可以不用实现。
• doInBackground(Params…)
  将在onPreExecute 方法执行后马上执行，该方法运行在后台线程中。这里将主要负责执行那些很耗时的后台处理工作。可以调用 publishProgress方法来更新实时的任务进度。该方法是抽象方法，子类必须实现。
• onProgressUpdate(Progress…)
  在publishProgress方法被调用后，UI 线程将调用这个方法从而在界面上展示任务的进展情况，例如通过一个进度条进行展示。
• onPostExecute(Result)
  在doInBackground 执行完成后，onPostExecute 方法将被UI 线程调用，后台的计算结果将通过该方法传递到UI 线程，并且在界面上展示给用户.
• onCancelled()
  在用户取消线程操作的时候调用。当在主线程中调用task.cancel()的时候回调。和onPostExecute一样，都是在UI线程中执行，所以当我们想要取消之后，有些界面变化我们可以在oncancel里面改变UI。

注：public final boolean cancel (boolean mayInterruptIfRunning)
当布尔值为true时，表示直接中断当前正在执行的任务，否则中断那些等待执行还尚未执行的任务。
当调用cancel()后，在doInBackground() return后，我们将会调用onCancelled(Object) 不再调用onPostExecute(Object)。为了保证任务更快取消掉，应该在doInBackground()中周期性的检查iscancelled 去进行判断。

class DownloadTask extends AsyncTask<String, Integer, Boolean> {

    @Override
    protected void onPreExecute() {
        progressDialog.show();
    }

    @Override
    protected Boolean doInBackground(String... params) {
        try {
            String url = params[0];
            while (true) {
                int downloadPercent = doDownload(url);
                publishProgress(downloadPercent);
                if (downloadPercent >= 100) {
                    break;
                }
            }
        } catch (Exception e) {
            return false;
        }
        return true;
    }

    @Override
    protected void onProgressUpdate(Integer... values) {
        progressDialog.setMessage("当前下载进度：" + values[0] + "%");
    }

    @Override
    protected void onPostExecute(Boolean result) {
        progressDialog.dismiss();
        if (result) {
            Toast.makeText(context, "下载成功", Toast.LENGTH_SHORT).show();
        } else {
            Toast.makeText(context, "下载失败", Toast.LENGTH_SHORT).show();
        }
    }
}

在UI线程中启动这个任务：

DownloadTask task = new DownloadTask();
task.execute(URL);

以上就是AsyncTask的基本用法，是不是感觉在子线程和UI线程之间进行切换变得灵活了很多？我们并不需求去考虑什么异步消息处理机制，也不需要专门使用一个Handler来发送和接收消息，只需要调用一下publishProgress()方法就可以轻松地从子线程切换到UI线程了。
注：
1.Task的实例必须在UI 线程中创建。
2.execute方法必须在UI 线程中调用。
3.不要手动调用onPreExecute(), onPostExecute(Result)，doInBackground(Params…), onProgressUpdate(Progress…)这几个方法，需要在UI线程中实例化这个task来回调。
4.该task只能被执行一次，否则多次调用时将会出现异常。

AsyncTask的源码分析

接下来，我们来分析一下AsyncTask的源码，对它的实现原理一探究竟。注意这里我选用的是Android M(6.0)的源码，源码我已经上传了，下载地址：Android M(6.0)的源码。
执行任一任务之前，要先new出它的实例，因此，我们先来看一看AsyncTask构造函数中的源码，如下所示：

public AsyncTask() {
        mWorker = new WorkerRunnable<Params, Result>() {
            public Result call() throws Exception {
                mTaskInvoked.set(true);
Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
                //noinspection unchecked
                Result result = doInBackground(mParams);
                Binder.flushPendingCommands();
                return postResult(result);
            }
        };

        mFuture = new FutureTask<Result>(mWorker) {
            @Override
            protected void done() {
                try {
                    postResultIfNotInvoked(get());
                } catch (InterruptedException e) {
                    android.util.Log.w(LOG_TAG, e);
                } catch (ExecutionException e) {
                    throw new RuntimeException("An error occurred while executing doInBackground()",e.getCause());
                } catch (CancellationException e) {
                    postResultIfNotInvoked(null);
                }
            }
        };
    }

只是初始化了两个变量，mWorker和mFuture，并在初始化mFuture的时候将mWorker作为参数传入。mWorker是一个Callable对象，mFuture是一个FutureTask对象，这两个变量会暂时保存在内存中，稍后才会用到它们。
接着如果想要启动某一个任务，就需要调用该任务的execute()方法，来看看execute()方法的源码：

public final AsyncTask<Params, Progress, Result> execute(Params... params) {
     return executeOnExecutor(sDefaultExecutor, params);
}

代码很简单，只有一句，再进去看看：

public final AsyncTask<Params, Progress, Result> executeOnExecutor(Executor exec, Params... params) {
     if (mStatus != Status.PENDING) {
         switch (mStatus) {
             case RUNNING:
                 throw new IllegalStateException("Cannot execute task:" + " the task is already running.");
             case FINISHED:
                 throw new IllegalStateException("Cannot execute task:" + " the task has already been executed " + "(a task can be executed only once)");
            }
        }
        mStatus = Status.RUNNING;
        onPreExecute();
        mWorker.mParams = params;
        exec.execute(mFuture);
        return this;
    }

可以看到，onPreExecute()方法在此处调用。那么doInBackground()什么时候执行呢？别着急，往后看。在第13行调用了Executor的execute()方法，并将前面初始化的mFuture对象传了进去，那么这个Executor对象又是什么呢？往下追踪：

public static void execute(Runnable runnable) {
    sDefaultExecutor.execute(runnable);
}

原来是传入了一个sDefaultExecutor变量，接着找一下这个sDefaultExecutor变量是在哪里定义的

public static final Executor SERIAL_EXECUTOR = new SerialExecutor();
private static volatile Executor sDefaultExecutor = SERIAL_EXECUTOR;

可以看到，这里先new出了一个SERIAL_EXECUTOR常量，然后将sDefaultExecutor的值赋值为这个常量，也就是说明，刚才的sDefaultExecutor.execute(runnable)方法，其实也就是调用的SerialExecutor类中的execute()方法。那么我们自然要去看看SerialExecutor的源码了

private static class SerialExecutor implements Executor {
        final ArrayDeque<Runnable> mTasks = new ArrayDeque<Runnable>();
        Runnable mActive;

        public synchronized void execute(final Runnable r) {
            mTasks.offer(new Runnable() {
                public void run() {
                    try {
                        r.run();
                    } finally {
                        scheduleNext();
                    }
                }
            });
            if (mActive == null) {
                scheduleNext();
            }
        }

        protected synchronized void scheduleNext() {
            if ((mActive = mTasks.poll()) != null) {
                THREAD_POOL_EXECUTOR.execute(mActive);
            }
        }
    }

可以看到，SerialExecutor是使用ArrayDeque这个队列来管理Runnable对象的，如果我们一次性启动了很多个任务，首先在第一次运行execute()方法的时候，会调用ArrayDeque的offer()方法将传入的Runnable对象添加到队列的尾部，然后判断mActive对象是不是等于null，第一次运行当然是等于null了，于是会调用scheduleNext()方法。在这个方法中会从队列的头部取值，并赋值给mActive对象，然后调用THREAD_POOL_EXECUTOR去执行取出的取出的Runnable对象。之后如何又有新的任务被执行，同样还会调用offer()方法将传入的Runnable添加到队列的尾部，但是再去给mActive对象做非空检查的时候就会发现mActive对象已经不再是null了，于是就不会再调用scheduleNext()方法。
那么后面添加的任务岂不是永远得不到处理了？当然不是，看一看offer()方法里传入的Runnable匿名类，这里使用了一个try finally代码块，并在finally中调用了scheduleNext()方法，保证无论发生什么情况，这个方法都会被调用。也就是说，每次当一个任务执行完毕后，下一个任务才会得到执行，SerialExecutor模仿的是单一线程池的效果，如果我们快速地启动了很多任务，同一时刻只会有一个线程正在执行，其余的均处于等待状态。

SerialExecutor类中也有一个execute()方法，这个方法里的所有逻辑都是在子线程中执行的，注意这个方法有一个Runnable参数，那么目前这个参数的值是什么呢？当然就是mFuture对象了，也就是说在第9行我们要调用的是FutureTask类的run()方法：

public void run() {
        if (state != NEW || !U.compareAndSwapObject(this, RUNNER, null, Thread.currentThread()))
            return;
        try {
            Callable<V> c = callable;
            if (c != null && state == NEW) {
                V result;
                boolean ran;
                try {
                    result = c.call();
                    ran = true;
                } catch (Throwable ex) {
                    result = null;
                    ran = false;
                    setException(ex);
                }
                if (ran)
                    set(result);
            }
        } finally {
            // runner must be non-null until state is settled to
            // prevent concurrent calls to run()
            runner = null;
            // state must be re-read after nulling runner to prevent
            // leaked interrupts
            int s = state;
            if (s >= INTERRUPTING)
                handlePossibleCancellationInterrupt(s);
        }
    }

可以看到，在第10行调用了callable的call()方法，那么这个callable对象是什么呢？其实就是在初始化mFuture对象时传入的mWorker对象了，此时调用的call()方法，也就是一开始在AsyncTask的构造函数中指定的，我们把它单独拿出来看一下，代码如下所示：

mWorker = new WorkerRunnable<Params, Result>() {
     public Result call() throws Exception {
           mTaskInvoked.set(true);
Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND); //noinspection unchecked
           Result result = doInBackground(mParams);
           Binder.flushPendingCommands();
           return postResult(result);
     }
};

终于找到了doInBackground()方法的调用处，虽然经过了很多周转，但目前的代码仍然是运行在子线程当中的，所以这也就是为什么我们可以在doInBackground()方法中去处理耗时的逻辑。接着将doInBackground()方法返回的结果传递给了postResult()方法，这个方法的源码如下所示：

private Result postResult(Result result) {
    @SuppressWarnings("unchecked")
    Message message = getHandler().obtainMessage(MESSAGE_POST_RESULT,new AsyncTaskResult<Result>(this, result));
    message.sendToTarget();
    return result;
}

这里使用getHandler()对象发出了一条消息，消息中携带了MESSAGE_POST_RESULT常量和一个表示任务执行结果的AsyncTaskResult对象。这个getHandler()对象是什么呢？来看一下：

    private static Handler getHandler() {
        synchronized (AsyncTask.class) {
            if (sHandler == null) {
                sHandler = new InternalHandler();
            }
            return sHandler;
        }
    }

它是InternalHandler类的一个实例，那么稍后这条消息肯定会在InternalHandler的handleMessage()方法中被处理。InternalHandler的源码如下所示：

private static class InternalHandler extends Handler {
        public InternalHandler() {
            super(Looper.getMainLooper());
        }

        @SuppressWarnings({"unchecked", "RawUseOfParameterizedType"})
        @Override
        public void handleMessage(Message msg) {
            AsyncTaskResult<?> result = (AsyncTaskResult<?>) msg.obj;
            switch (msg.what) {
                case MESSAGE_POST_RESULT:
                    // There is only one result
                    result.mTask.finish(result.mData[0]);
                    break;
                case MESSAGE_POST_PROGRESS:
                    result.mTask.onProgressUpdate(result.mData);
                    break;
            }
        }
    }

这里对消息的类型进行了判断，如果这是一条MESSAGE_POST_RESULT消息，就会去执行finish()方法，如果这是一条MESSAGE_POST_PROGRESS消息，就会去执行onProgressUpdate()方法。finish()方法的源码如下所示：

private void finish(Result result) {
    if (isCancelled()) {
        onCancelled(result);
    } else {
        onPostExecute(result);
    }
    mStatus = Status.FINISHED;
}

可以看到，如果当前任务被取消掉了，就会调用onCancelled()方法，如果没有被取消，则调用onPostExecute()方法，这样当前任务的执行就全部结束了。
我们注意到，在刚才InternalHandler的handleMessage()方法里，还有一种MESSAGE_POST_PROGRESS的消息类型，这种消息是用于当前进度的，调用的正是onProgressUpdate()方法，那么什么时候才会发出这样一条消息呢？相信你已经猜到了，查看publishProgress()方法的源码，如下所示：

protected final void publishProgress(Progress... values) {
    if (!isCancelled()) {
            getHandler().obtainMessage(MESSAGE_POST_PROGRESS, new AsyncTaskResult<Progress>(this, values)).sendToTarget();
     }
}

完全正确！正是这里发出的消息。正因为如此，在doInBackground()方法中调用publishProgress()方法才可以从子线程切换到UI线程，从而完成对UI元素的更新操作。其实也没有什么神秘的，因为说到底，AsyncTask也是使用的异步消息处理机制，只是做了非常好的封装而已。

注：在Android 3.0之前是并没有SerialExecutor这个类的，那个时候是直接在AsyncTask中构建了一个sExecutor常量，并对线程池总大小，同一时刻能够运行的线程数做了规定，代码如下所示：

private static final int CORE_POOL_SIZE = 5;  
private static final int MAXIMUM_POOL_SIZE = 128;  
private static final int KEEP_ALIVE = 10;  
……  
private static final ThreadPoolExecutor sExecutor = new ThreadPoolExecutor(CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE, TimeUnit.SECONDS, sWorkQueue, sThreadFactory);

可以看到，这里规定同一时刻能够运行的线程数为5个，线程池总大小为128。也就是说当我们启动了10个任务时，只有5个任务能够立刻执行，另外的5个任务则需要等待，当有一个任务执行完毕后，第6个任务才会启动，以此类推。而线程池中最大能存放的线程数是128个，当我们尝试去添加第129个任务时，程序就会崩溃。

因此在3.0版本中AsyncTask的改动还是挺大的，在3.0之前的AsyncTask可以同时有5个任务在执行，而3.0之后的AsyncTask同时只能有1个任务在执行。为什么升级之后可以同时执行的任务数反而变少了呢？这是因为更新后的AsyncTask已变得更加灵活，如果不想使用默认的线程池，还可以自由地进行配置。比如使用如下的代码来启动任务：

Executor exec = new ThreadPoolExecutor(15, 200, 10, TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>());  
new DownloadTask().executeOnExecutor(exec); 

这样就可以使用我们自定义的一个Executor来执行任务，而不是使用SerialExecutor。上述代码的效果允许在同一时刻有15个任务正在执行，并且最多能够存储200个任务。