AsyncTask执行缓慢的原因分析

转载请标注:

披萨大叔的博客 http://blog.csdn.net/qq_27258799/article/details/51372052

如果您觉得这篇文章对您有帮助,请点下文章最下面的赞~

这几天在做一个缓存网络加载的信息模块,在读取缓存并更新UI的时候用到AsyncTask,本来是想这样代码比较干净的,然后就发现问题了。

问题:

执行execute()以后,从onPreExecute()doInBackground()之间竟然等待了长达7秒,而且这个时间时长时短,然后就开始查找原因。

后来发现了AsyncTask的黑历史:

在1.6(Donut)之前:

在第一版的AsyncTask,任务是串行调度。一个任务执行完成另一个才能执行。由于串行执行任务,使用多个AsyncTask可能会带来有些问题。所以这并不是一个很好的处理异步(尤其是需要将结果作用于UI试图)操作的方法。

从1.6到2.3(Gingerbread)

后来Android团队决定让AsyncTask并行来解决1.6之前引起的问题,这个问题是解决了,新的问题又出现了。很多开发者实际上依赖于顺序执行的行为。于是很多并发的问题蜂拥而至。

3.0(Honeycomb)到现在

好吧,开发者可能并不喜欢让AsyncTask并行,于是Android团队又把AsyncTask改成了串行。当然这一次的修改并没有完全禁止AsyncTask并行。你可以通过设置executeOnExecutor(Executor)来实现多个AsyncTask并行。

上面这段话中心思想就是,现在AsyncTask是默认串行执行的,AsyncTask默认自己维护一个静态的线程池,而该线程池只允许同时执行一个线程,也就是说,你的应用中,可能有多个AsyncTask实例,而多次不管多少个AsyncTask,只要是调用execute()方法,都是共享这个默认进程池的,你的任务必须在之前的任务执行完以后,才能执行。可以理解为,默认情况下,所有的AsyncTask在一个独立于UI线程的线程中执行,任务需要排队,先execute的先执行,后面的只能等。所以才会出现楼主这样漫长的等待问题。

解决:

除了excute方法外,我们可以自己调用executeOnExecutor,如果使用executeOnExecutor方法,可以在外部自定义线程池,解决不能并发执行异步任务的问题。

例如:

executeOnExecutor(Executors.newCachedThreadPool());

这样这个AsyncTask实例就有了自己的线程池而不必使用AsyncTask默认的。

追加:

AsyncTask新增了两个预定义的线程池SERIAL_EXECUTORTHREAD_POOL_EXECUTOR

其实 THREAD_POOL_EXECUTOR 并不是新增的,之前的就有,只不过之前(Android 2.3)它是AsyncTask私有的,未公开而已。THREAD_POOL_EXECUTOR 是一个corePoolSize为5的线程池,也就是说最多只有5个线程同时运行,超过5个的就要等待。所以如果使用 executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR) 就跟2.3版本的 AsyncTask.execute() 效果是一样的。

SERIAL_EXECUTOR 是新增的,它的作用是保证任务执行的顺序,也就是它可以保证提交的任务确实是按照先后顺序执行的。它的内部有一个队列用来保存所提交的任务,保证当前只运行一个,这样就可以保证任务是完全按照顺序执行的,默认的execute()使用的就是这个,也就是 executeOnExecutor(AsyncTask.SERIAL_EXECUTOR) 与execute()是一样的。

最后引用大牛的建议:

虽然建议使用AsyncTask而不是使用Thread,但是AsyncTask似乎又有它的限制,这就要根据具体的需求情况而选择合适的工具,No Silver Bullet。下面是一些建议:

改善你的设计,少用异步处理

线程的开销是非常大的,同时异步处理也容易出错,难调试,难维护,所以改善你的设计,尽可能的少用异步。对于一般性的数据库查询,少量的I/O操作是没有必要启动线程的。

与主线程有交互时用AsyncTask,否则就用Thread

AsyncTask被设计出来的目的就是为了满足Android的特殊需求:非主线程不能操作(UI)组件,所以AsyncTask扩展Thread增强了与主线程的交互的能力。如果你的应用没有与主线程交互,那么就直接使用Thread就好了。

当有需要大量线程执行任务时,一定要创建线程池

线程的开销是非常大的,特别是创建一个新线程,否则就不必设计线程池之类的工具了。当需要大量线程执行任务时,一定要创建线程池,无论是使用AsyncTask还是Thread,因为使用AsyncTask它内部的线程池有数量限制,可能无法满足需求;使用Thread更是要线程池来管理,避免虚拟机创建大量的线程。比如从网络上批量下载图片,你不想一个一个的下,或者5个5个的下载,那么就创建一个CorePoolSize为10或者20的线程池,每次10个或者20个这样的下载,即满足了速度,又不至于耗费无用的性能开销去无限制的创建线程。

对于想要立即开始执行的异步任务,要么直接使用Thread,要么单独创建线程池提供给AsyncTask

默认的AsyncTask不一定会立即执行你的任务,除非你提供给他一个单独的线程池。如果不与主线程交互,直接创建一个Thread就可以了,虽然创建线程开销比较大,但如果这不是批量操作就没有问题。

Android的开发没有想像中那样简单,要多花心思和时间在代码上和测试上面,以确信程序是优质的

看完上面的建议,我发现,其实我做的这个缓存只是缓存字符串,根本用不着开线程,就直接放到UI线程里好了。

时间: 2025-01-14 10:21:24

AsyncTask执行缓慢的原因分析的相关文章

Rxjava 执行阻塞的原因分析 tolist() observable.from()等。

开发中多次碰到了tolist方法阻塞住的问题.一直为了赶进度,避开使用该操作符号. 直到有一天发现flatmap中的 observable.from()也会阻塞.排查原因才发现是  onComplete()方法没有调用的原因. 根据rxjava的链式调用原理,有从下到上一步步传递回调函数,在从上到下逐步执行的过程. 而该过程中有的步骤执行需要等待oncomplete调用. Rxjava 执行阻塞的原因分析 tolist() observable.from()等.

SELECT TOP 1 比不加TOP 1 慢的原因分析以及SELECT TOP 1语句执行计划预估原理

现实中遇到过到这么一种情况: 在某些特殊场景下:进行查询的时候,加了TOP 1比不加TOP 1要慢(而且是慢很多)的情况, 也就是说对于符合条件的某种的数据,查询1条(符合该条件)数据比查询所有(符合该条件)数据慢的情况, 这种情况往往只有在某些特殊条件下会出现,那么,就有两个问题:为什么加了TOP 1 会比不加TOP 1慢?这种“特殊条件”是什么条件? 本文将对此情况进行演示和原理分析,以及针对此种情况采用什么方法来解决. 按照一贯风格,先造一个测试环境:1000W+的数据 数据的特点为: 1

Windows变慢原因分析及解决方法

<p>Windows变慢原因分析及解决方法  <br/> <br/> <br/> <br/> 谁都希望计算机一开机就可以立即进入Windows 系统而不用等待,或者是系统在使用的时候不会越来越慢,但由于种种原因常常使这些愿望不能实现,甚至一开机就死机或者用着用着就越来越慢的情况也经常发生.其实有些时候Windows 启动速度缓慢并不是它本身的问题,而是一些设备或软件造成的.本文就是软件.硬件和病毒三大方面来分析系统速度变慢的原因,并且提供了针对系

Android ListView异步加载图片乱序问题,原因分析及解决方案

转载请注明出处:http://blog.csdn.net/guolin_blog/article/details/45586553 在Android所有系统自带的控件当中,ListView这个控件算是用法比较复杂的了,关键是用法复杂也就算了,它还经常会出现一些稀奇古怪的问题,让人非常头疼.比如说在ListView中加载图片,如果是同步加载图片倒还好,但是一旦使用异步加载图片那么问题就来了,这个问题我相信很多Android开发者都曾经遇到过,就是异步加载图片会出现错位乱序的情况.遇到这个问题时,不

SQL Server 磁盘请求超时的833错误原因分析以及解决

本文出处:http://www.cnblogs.com/wy123/p/6984885.html 最近遇到一个SQL Server服务器响应极度缓慢,并且出现客户端请求报错的情况,在数据库中的errorlog中出现磁盘请求超过一定时间才完成的error消息.对于此类问题,到底是存储系统或者磁盘的故障,还是SQL Server 自己的问题,亦或是应用程序引发的呢?又要如何解决?本文将对引起此问题的某一方面的因素进行简单的分析,但是无法涵盖所有潜在的可能性,因此遇到类似问题还要做具体的分析. SQL

Android异步任务AsyncTask的使用与原理分析

在上一篇文章<Android缓存机制&一个缓存框架推荐>中说到,在了解了Android缓存机制后我准备自己动手写一个LruCache和DiskLruCache二级缓存的轻量级的图片请求框架,在思考如何搭建这个框架时,纠结于用何种方式去下载图片,是直接new出一个线程呢,还是用看起来稍微高大上档次一点的AsyncTask异步任务来处理?思来想去,还是虚荣心作怪,还是用AsyncTask吧,正好这个工具类我之前用的也比较少,对它的原理也不是很清楚,趁这个机会,好好学一下AsyncTask的

Inotify数达到限制或文件空间不足的不同表现同一本质原因分析

操作系统环境: LSB Version:    :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch Distributor ID: RedHatEnterpriseServer Description:    Red Hat Enterprise Linux Serve

ListView+CheckBox两种解决方案及原因分析

最近在用ListView+CheckBox搞一个item选中的项目,我将CheckBox的focus设置为false,另我大喜的是,CheckBox竟然可以选中(窃喜中),这么简单就搞定了,因为数据量较小,也没有发现什么问题. 后来数据多了, 页面需要滑动了, 发现了一个奇怪的问题,前面明明选中了,而再次滑动回去的时候竟然变成未选中状态! 这是我刚开始写的那段错误的代码: @Override public View getView(int position, View convertView,

Beforeunload打点丢失原因分析及解决方案

淘宝的鱼相在 2012 年 8 月份发表了一篇文章,里面讲述了他们通过一个月的数据采集试验,得到的结果是:如果在浏览器的本页面刷新之前发送打点请求,各浏览器都有不同程度的点击丢失情况,具体点击丢失率统计大家请看下图(数据日期为 2012 年 7 月份): 从图中可以看出,chrome,safari 这类 webkit 内核的浏览器在本页刷新之前发送打点,导致的丢失最为严重,分别为 61%,76%,而 ie8 丢失的情况最少,为7%. (具体大家可以参看此文:http://ued.taobao.c