AsyncTask源码解析
2015-10-29 14:41
351 查看
一、AsyncTask使用
泛型函数,明显看出后面三个数据类型分别对应于参数类型,返回进度数据类型,以及最终返回结果数据类型;使用实例为下:
代码中使用得:
二、AsyncTask源码解析:
AsyncTask是Handler与Thread相结合的产物,用以处理一些耗时较短的后台处理工作。
1、先从execute出发:
上面的代码很简单,调用了函数executeOnExecutor;
2、executeOnExecutor:
可以看到这里调用了前面代码中需要Override的函数onPreExecute,该函数运行在真正的后台处理函数exec.execute(mFuture)之前,其仍运行在UI线程中,可以做一些初始化工作;
3、exec.execute(mFuture):
先看Executor exec,这里传入的参数是sDefaultExecutor;
其具体类型是SerialExecutor,其用来execute mFuture:
mFuture在构造函数中初始化:
可以看到mFuture是个FutureTask,用以开辟一个执行后台任务的子线程Callable。可以看到该callable执行主逻辑便是前面重写的doInBackground,故该函数运行于子线程中。
前面可以看到,当doInBackground任务执行完毕后,继续执行postResult来传递处理的结果。
4、postResult:
该函数运行在子线程中,向主线程传递消息,可想而知,使用的是Handler;则对事件的处理都应在Handler中;
5、getHandler:
前面doInBackground执行完毕后发送的MESSAGE_POST_RESULT Message,其处理逻辑即是调用finish.
6、finish:
如果任务并未被取消,则最终调用onPostExecute来将结果最终显示在UI界面上,该函数运行与UI线程中;
前面还有一种MESSAGE_POST_PROGRESS Message,其对应的处理函数便是用以实时更新任务完成进程的onProgressUpdate,该Message的产生便是在前面使用的publishProgress方法中;
7、publishProgress:
可以看到这里最终产生MESSAGE_POST_PROGRESS类型的Message并发送出去。
综上来看,AsyncTask只是对Handler与Thread进行了封装,开辟Callable子线程来处理后台任务,处理完后台任务,然后通过Handler与主UI线程进行交互,进行界面更新等操作。
8、前面提到的Executor:
SerialExecutor也是AsyncTask在3.0版本以后做了最主要的修改的地方,它在AsyncTask中是以常量的形式被使用的,因此在整个应用程序中的所有AsyncTask实例都会共用同一个SerialExecutor。
可以看到,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模仿的是单一线程池的效果,如果我们快速地启动了很多任务,同一时刻只会有一个线程正在执行,其余的均处于等待状态。Android照片墙应用实现,再多的图片也不怕崩溃 这篇文章中例子的运行结果也证实了这个结论。
不过你可能还不知道,在Android 3.0之前是并没有SerialExecutor这个类的,那个时候是直接在AsyncTask中构建了一个sExecutor常量,并对线程池总大小,同一时刻能够运行的线程数做了规定,代码如下所示:
可以看到,这里规定同一时刻能够运行的线程数为5个,线程池总大小为128。也就是说当我们启动了10个任务时,只有5个任务能够立刻执行,另外的5个任务则需要等待,当有一个任务执行完毕后,第6个任务才会启动,以此类推。而线程池中最大能存放的线程数是128个,当我们尝试去添加第129个任务时,程序就会崩溃。
因此在3.0版本中AsyncTask的改动还是挺大的,在3.0之前的AsyncTask可以同时有5个任务在执行,而3.0之后的AsyncTask同时只能有1个任务在执行。为什么升级之后可以同时执行的任务数反而变少了呢?这是因为更新后的AsyncTask已变得更加灵活,如果不想使用默认的线程池,还可以自由地进行配置。比如使用如下的代码来启动任务:
这样就可以使用我们自定义的一个Executor来执行任务,而不是使用SerialExecutor。上述代码的效果允许在同一时刻有15个任务正在执行,并且最多能够存储200个任务。
public abstract class AsyncTask<Params, Progress, Result>
泛型函数,明显看出后面三个数据类型分别对应于参数类型,返回进度数据类型,以及最终返回结果数据类型;使用实例为下:
private class myAsyncTask extends AsyncTask<String, Integer, String> { //执行前先进性的初始化操作(可选) @Override protected void onPreExecute() { } //Task操作主体(abstract函数,必须重写) //参数(String类型),由execute传递过来 @Override protected String doInBackground(String... params) { return null; } //运行在UI线程(可选) //实时更新进度条等UI元素 @Override protected void onProgressUpdate(Integer... progress){ publishProgress(progress); } //doInBackground完成后,返回值会传入事件处理程序中(可选) @Override protected void onPostExecute(String result){ } }
代码中使用得:
new myAsyncTask().execute(params);
二、AsyncTask源码解析:
AsyncTask是Handler与Thread相结合的产物,用以处理一些耗时较短的后台处理工作。
1、先从execute出发:
@MainThread public final AsyncTask<Params, Progress, Result> execute(Params... params) { return executeOnExecutor(sDefaultExecutor, params); }
上面的代码很简单,调用了函数executeOnExecutor;
2、executeOnExecutor:
@MainThread 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; }
可以看到这里调用了前面代码中需要Override的函数onPreExecute,该函数运行在真正的后台处理函数exec.execute(mFuture)之前,其仍运行在UI线程中,可以做一些初始化工作;
3、exec.execute(mFuture):
先看Executor exec,这里传入的参数是sDefaultExecutor;
public static final Executor SERIAL_EXECUTOR = new SerialExecutor(); private static volatile Executor sDefaultExecutor = SERIAL_EXECUTOR;
其具体类型是SerialExecutor,其用来execute mFuture:
mFuture在构造函数中初始化:
private final FutureTask<Result> mFuture; private static abstract class WorkerRunnable<Params, Result> implements Callable<Result> { Params[] mParams; } 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); } } }; }
可以看到mFuture是个FutureTask,用以开辟一个执行后台任务的子线程Callable。可以看到该callable执行主逻辑便是前面重写的doInBackground,故该函数运行于子线程中。
前面可以看到,当doInBackground任务执行完毕后,继续执行postResult来传递处理的结果。
4、postResult:
private Result postResult(Result result) { @SuppressWarnings("unchecked") Message message = getHandler().obtainMessage(MESSAGE_POST_RESULT, new AsyncTaskResult<Result>(this, result)); message.sendToTarget(); return result; }
该函数运行在子线程中,向主线程传递消息,可想而知,使用的是Handler;则对事件的处理都应在Handler中;
5、getHandler:
private static Handler getHandler() { synchronized (AsyncTask.class) { if (sHandler == null) { sHandler = new InternalHandler(); } return sHandler; } } 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; } } }
前面doInBackground执行完毕后发送的MESSAGE_POST_RESULT Message,其处理逻辑即是调用finish.
6、finish:
private void finish(Result result) { if (isCancelled()) { onCancelled(result); } else { onPostExecute(result); } mStatus = Status.FINISHED; }
如果任务并未被取消,则最终调用onPostExecute来将结果最终显示在UI界面上,该函数运行与UI线程中;
前面还有一种MESSAGE_POST_PROGRESS Message,其对应的处理函数便是用以实时更新任务完成进程的onProgressUpdate,该Message的产生便是在前面使用的publishProgress方法中;
7、publishProgress:
@WorkerThread protected final void publishProgress(Progress... values) { if (!isCancelled()) { getHandler().obtainMessage(MESSAGE_POST_PROGRESS, new AsyncTaskResult<Progress>(this, values)).sendToTarget(); } }
可以看到这里最终产生MESSAGE_POST_PROGRESS类型的Message并发送出去。
综上来看,AsyncTask只是对Handler与Thread进行了封装,开辟Callable子线程来处理后台任务,处理完后台任务,然后通过Handler与主UI线程进行交互,进行界面更新等操作。
8、前面提到的Executor:
SerialExecutor也是AsyncTask在3.0版本以后做了最主要的修改的地方,它在AsyncTask中是以常量的形式被使用的,因此在整个应用程序中的所有AsyncTask实例都会共用同一个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模仿的是单一线程池的效果,如果我们快速地启动了很多任务,同一时刻只会有一个线程正在执行,其余的均处于等待状态。Android照片墙应用实现,再多的图片也不怕崩溃 这篇文章中例子的运行结果也证实了这个结论。
不过你可能还不知道,在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个任务。
相关文章推荐
- Happy Number
- 图解JavaScript中的this关键字
- menuconfig菜单选项
- linux mongodb 安装
- getOutputStream() has already been called for this response 错误异常的处理
- Java编程思想第四版读书笔记——第十一章 持有对象
- bash 快捷键
- Happy Number
- PostgreSQL-pg_dump,pg_restore
- 终于知道10月27-28-29这3天为什么调整了
- 软件安装方式
- 关于log4j的使用
- 已知先序遍历和中序遍历,求后序遍历 && 求二叉树中节点的最大距离
- Swift(一、基本入门)
- 主成分分析PCA
- log4j.properties详解与例子
- 关于distinct 和group by的去重逻辑浅析
- Flex中的Array和ArrayCollection
- 数据结构排序之选择排序
- HDOJ 5501The Highest Mark(贪心+动态规划)