AsyncTask是一只命途多舛的小麻雀,为什么说它命途多舛,因为它一直被改,从Android 1.6之前,然后1.6到2.3,再从3.0到现在(其实5.1开始后也有细微的改动),反反复复,从串行到并行,再恢复至串行,可见其内心之纠结,尽管如此,它还是不断被开发人员各种吐槽,内存泄露,不靠谱的cancel等等,真可谓命途多舛。
一 需求和api选型
想想看我们对于AsyncTask的需求是什么,大概会有以下几点:
- 能定义以下执行过程的操作:预执行、执行后台任务、执行进度反馈、执行完毕、终止线程执行
- 能停止线程任务
- 子线程能与UI线程交互(反馈线程执行进度和执行结果)
第1点,我们定义这些方法目的是让调用者重写而实现各种交互,因此这5种操作实际上是5个抽象方法(或者空方法),我们需要在SimpleAsyncTask类中合适的时机去调用这5个抽象方法,显然,这是模板方法模式(Template Method)的应用。
对于第2点,如何停止线程?这方面的最佳实践是中断+条件变量,纵观java.util.concurrent,有个api很适合这个场景,那便是Future和Callback,而作为Future的唯一实现——FutureTask便是我们写AsyncTask的重点。
第3点,看到子线程和UI线程,so easy呀,有了Handler,麻麻再也不用担心线程之间的通讯了,关于Handler,如果你闲的蛋疼的话不妨看看笔者写的《Handler和他的小伙伴们》上和中。 有一点要注意的是,AsyncTask会在各Activity中实例化,有可能在主线程或子线程中实例化,这么多的AsyncTask实例中,我们只需要一个持有mainLooper的Handler的实例,因此它将是一个单例对象,单个进程内共享。
确定好需求和api选型之后,接下来我们来写代码。
二 使用Template Method
首先定义五个空方法:预执行、执行后台任务、执行进度反馈、执行完毕、终止线程执行。
这几个方法见名知意,同时从各自携带的参数类型可以清晰的理解几个泛型的作用:
- Params:执行后台任务的时候使用
- Progress:反馈进度的时候使用
- Result:反馈结果的时候使用
(注:这里为了代码简洁,去掉了Params和Progress的可变参数)
当然,模板方法模式最重要的是我们在何时去调用这些抽象的模板方法,很显然,doInBackground作为后台执行的逻辑,应该在线程中调用,也就是下文会讲到的FutureTask,而其他几个方法跟UI有关系,会在主线程中执行,因此它们会在Handler中调用到。
三 FutureTask开发
上文提到,Future和Callable是java.util.concurrent中提供了取消任务的一组api,要理解AsyncTask的话,需要先理解下这对组合。以下做个简单的介绍:
- Callable与Runable
简单来讲,Callable接口等价于Runable,call()等价于run(),区别在于它是有返回值的。
我们可以通过ExecutorService调用Callable,执行后将返回Future对象,比如:
Future<String> future = Executors.newSingleThreadExecutor().submit(mCallable);
- Future
Future接口两个方法着重理解下,一是cancel(boolean mayInterruptIfRunning)
,顾名思义就是终止线程,二是get()
,它会阻塞线程,直到Callable的call()返回对象,并以此作为返回值。至于mayInterruptIfRunning
这个boolean值的含义,大家看看FutureTask中相应的源码就直到了,其实只是多了thread.interrupt()
的逻辑而已。结合Callable的代码,Future的使用如下:
- FutureTask
- FutureTask的继承关系
从FutureTask的继承关系来看,它既是Runable也是Future,所以我们可以把当做Runable来使用,同时它也具备Future的能力,可以终止线程,可以阻塞线程,等待Callable的执行,并获取返回值。另外要注意的是,它的构造函数是public FutureTask(Callable<V> callable)
,因此实例化FutureTask时需要Callable对象作为参数。
关于这部分基础知识的demo代码在此处,有需要的可以跑起来看看。 - SimpleAsyncTask中的FutureTask
介绍完Future和Callable的基础知识后,我们回归正题。FutureTask在AsyncTask里充当了线程的角色,因此耗时的后台任务doInBackground应该在FutureTask中调用,同时我们还要提供线程池对象来执行FutureTask,代码如下:
四 Handler开发
到目前为止,我们已经消费掉了两个模板方法,分别是onPreExecute和doInBackground,此时还剩下3个模板方法,他们都需要有UI交互的,因此他们将在Handler中被调用。
首先,对于终止线程和线程执行完毕这两个方法,我们都称之为线程finish了,所以我们先定义个finish(Result result)
方法,如下:
接下来,开始写关键的Handler类对象,因为该Handler位于SimpleAsyncTask内部,因此把它命名为InternalHandler,这个静态内部类有几点要注意:
- 它是静态的单实例,所有AsyncTask对象共享
- 它必须持有mainLooper对象,才能与主线程进行交互
- 注意它调用几个模板方法的时机
代码如下:
到目前为止5个模板方法都已经调用到了,其中四个方法均有触发的时机和调用的时机,除了onProgressUpdate,它只有调用,但并没有触发的时机,因此,我们还要提供一个方法,供调用者主动触发:
写到这里,我们这只简化版的小麻雀基本上已经完成,当然对比源码还是有一点点细微的不同,大家可以自行对比一下。通过自己写个SimpleAsyncTask的方式可以帮助我们更好的理解源码,以上所写的完整代码在此。
五 关于其他细节
- 串行or并行?
在SimpleAsyncTask中,我们使用private static final Executor EXECUTOR = Executors.newCachedThreadPool()
作为线程池,而实际上,源码中的默认线程池是自定义的,这个类是SerialExecutor
,从类的命名上看,Serial是串行的意思,所以很明显,AsyncTask默认是串行的。除此之外,AsyncTask里还有个线程池THREAD_POOL_EXECUTOR
,实在需要并行的话我们就用这个线程池。
如果都些都不满足要求,我们也可以自定义符合自己业务要求的线程池,并通过setDefaultExecutor(Executor exec)
改变默认的线程池。 - 不能执行多次
AsyncTask只能执行一次,类似这样的代码是会抛异常的:
原理很简单,AsyncTask会判断当前状态,如果是RUNNING或者FINISHED状态,则直接抛异常:
- AsyncTask是否只能在主线程创建和运行?
比如,这样的代码能否正常使用:
从Android4.1(API 16)之后其实已经没什么问题了,通过源码来理解的话非常简单,比如在我们自己写的SimpleAsyncTask中,重写了Handler的构造器,如下:
这样一来,无论AsyncTask在什么时候创建,实例化出来的静态InternalHandler对象都持有mainLooper,都能与主线程进行通讯。有一点小区别,如果在子线程中调用execute(),则onPreExecute不能执行UI的操作,否则会抛异常。
要注意的是,这是Android 5.1(API 22)以及之后的写法,API 16~API 21是另外一种写法,参考下一点。
- AsyncTask.init()
AsyncTask中有个隐藏方法init()(API 22之后已经移除)
与此对应的,在ActivityThread的main方法中会调用AsyncTask.init(),目的是什么?
由于AsyncTask中的Handler是静态的单实例对象,他会在类加载期间进行初始化,万一调用者在子线程中加载AsyncTask,将会导致同一进程的所有AsyncTask无法使用。因此,系统先下手为强,一开始就直接加载,保证该Handler持有主线程的mainLooper,能正常进行UI交互。
- postResultIfNotInvoked的作用是什么?
AsyncTask有很多逻辑干扰了我们解读源码,postResultIfNotInvoked便是其中一个。它实际上是Google解决的一个bug,确保如果cancel()方法过早调用的场景下,onCancelled()仍然能顺利的执行,参考stackoverflow这篇文章。
比如,我们自定义的SimpleAsyncTask,如果我们执行以下代码,onCancelled()是不会执行的,而AsyncTask则可以正常执行:
六 最后
AsyncTask作为一只命途多舛的小麻雀,他是一只纯粹的麻雀,脱离了低级趣味的麻雀,值得好好品尝的小麻雀。
参考文章:http://droidyue.com/blog/2015/12/20/worker-thread-in-android/?droid_refer=ninki_postshttp://droidyue.com/blog/2014/11/08/bad-smell-of-asynctask-in-android/index.htmlhttp://stackoverflow.com/questions/25322651/asynctask-source-code-questions