AsyncTask的优缺点

最新推荐文章于 2024-09-08 10:13:06 发布

TiaPu

最新推荐文章于 2024-09-08 10:13:06 发布

阅读量3.5k

点赞数 4

分类专栏： Anroid-common 文章标签： Android AsyncTask

本文链接：https://blog.csdn.net/weixin_43507738/article/details/83418989

版权

Anroid-common 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

继上篇简单介绍AsyncTask之后，本片开始介绍下AsyncTask的优缺点。
（注：本人所写文章仅作为自己学习使用）

AsyncTask的优点：

封装了Thread和Handler给用户使用，操作比较简单。用户需要使用时，仅需继承AsyncTask，并重写其中的doInBackground方法就可以，若是希望子线程的执行结果反馈到UI线程上，则将onPreExecute（告知UI线程，子线程开始执行）和onPostExectute（将子线程执行的结果反馈给UI线程）和onProgressUpdate（可以实时的将子线程的执行过程反馈给UI，一般是使用进度条）重写就可以。

AsyncTask的缺点

旋转屏幕
使用AsyncTask的最初目的是希望为UI线程开启一个后台线程，用于与之进行交互。因为常见对AsyncTask的使用是去执行一个耗时操作，并在结束后（AsyncTask.onPostExecute()）更新UI。但是旋转屏幕，当前的Activity会被销毁然后重建，Activity重启后，此时AsyncTask对Actvity的引用是invalid，因为他指向的还是前一个没有转屏前的Activity，并不是重建后的Activity，So onPostExecute对重建后的Activity是没有意义的。这点尤其是在将AsyncTask作为Activity的内部类，AsyncTask会隐式应用当前Activity的时候给人制造困惑。
避免该问题的一个常规做法是，保留对AsyncTask的引用，该引用在配置更改之间持续，在重新启动时更新目标Activity。
生命周期
AsyncTask的生命周期和Activity的生命周期不同步。不管Activity的生命周期是否已经结束（即使是application已经退出），AsyncTask会一直执行到doInBackground结束，之后，会选择下面的某一种方式继续执行：
a) 如果cancel(boolean)调用了，则执行onCancelled(Result)方法
b) 如果cancel(boolean)没有调用，则执行onPostExecute(Result)方法
只有一种提早finish AsyncTask方式：通过AsyncTask.cancel()来取消AsyncTask任务。也就是说你需要手动取消AsyncTask，否则你会冒着不必要的后台任务拖垮你的应用程序的风险，或者内存泄露。当你明确不在需要AsyncTask的时候，请确保手动取消该AsyncTask，以免后续在执行APP的过程中出现别的问题。
Cancelling AsyncTask
假设使用AsyncTask来执行一个查询操作。用户可能会在查询的过程中修改参数，此时你需要调用AsyncTask.cancel()来结束当前的任务，然后发起一个新的AsyncTask来执行用户修改完参数的查询。这种方法看起来是ok的，但是当check log的时候，我们会发现当前所有的AsyncTask都在运行，cancel方法并没有任何的意义，就算mayInterruptIfRunning这个参数为True。
Why？
问题发生在AsyncTask.cancel()这个方法上，该方法并不会不计后果的杀死后台线程，它所有的操作唯有将AsyncTask的状态置为“canceled”，然后依赖用户去检查AsyncTask是否被cancel掉了，如果用户发现AsyncTask已经被cancel了，然后才可以终止操作（这句话不是很理解）。对于参数mayInterruptIfRunning，它只是给后台正在运行的线程发了一个interrupt()，在后台线程不可中断的情况下，它根本不会停止线程。
有两种简单的方案可以解决大多数上面的问题：
在耗时较长的任务中，定期检查AsyncTask.isCancelled()，或者保持线程可中断。
无论哪种方式，当调用AsyncTask.isCancelled()时，这些方法都会阻止您的任务执行比必要时间更长的时间。

但是，这个建议并不总是有效的——如果您调用了一个不可间断且耗时较长的方法（比如BitmapFactory.decodeStream())呢？我在这种情况下所获得的唯一成功就是创建了一个导致抛出异常的情况（在本例中，过早地关闭了BitmapFactory使用的流）。这意味着单独的取消不能解决这个问题——需要外部干预。

并发任务数量受限
AsyncTask任务运行于线程池的。一般线程池的大小是固定的，这就导致AsyncTask可以并发的任务也是固定的。Android 1.5规定AsyncTask仅允许存放128个并发任务，同一时间只有10个任务可被同时处理（这10个任务以队列的形式存放）。也就是说如果你在完成138个任务之前排队，你的应用程序就会崩溃。大多数情况下，当人们使用AsyncTask从网络上加载Bitmaps时，会有这个问题。

当你发现自己面临这种限制的时候，应该考虑下你代码的设计，为什么会有这么多需要后台执行的任务了。或者另一种可以选择的方式为，为当前的任务创建一个较智能的队列，不要一次性并发执行那么多的代码。你要是实在是接受不了，可以重新定义AsyncTask的线程池大小。