AsyncTask的缺陷

导语：在开发Android应用的过程中，我们需要时刻注意保障应用的稳定性和界面响应性，因为不稳定或者响应速度慢的应用将会给用户带来非常差的交互体验。在越来越讲究用户体验的大环境下，用户也许会因为应用的一次Force Close(简称FC)或者延迟严重的动画效果而卸载你的应用。由于现在的应用大多需要异步连接网络，本系列文章就以构建网络应用为例，从稳定性和响应性两个角度分析多线程网络任务的性能优化方法。

概述：为了不阻塞UI线程（亦称主线程），提高应用的响应性，我们经常会使用新开线程的方式，异步处理那些导致阻塞的任务。

AsyncTask是Android为我们提供的方便编写异步任务的工具类，但是，在了解AsyncTask的实现原理之后，发现AsyncTask并不能满足我们所有的需求，使用不当还有可能导致应用FC。

本文主要通过分析AsyncTask提交任务的策略和一个具体的例子，说明AsyncTask的不足之处，至于解决办法，我们将在下篇再讲解。

分析：

AsyncTask类包含一个全局静态的线程池，线程池的配置参数如下：

?
我们这里不详细讲解ThreadPoolExecutor的原理，但将会讲解一个异步任务提交到AsyncTask的线程池时可能会出现的4种情况,并会提出在Android硬件配置普遍较低这个客观条件下，每个情况可能会出现的问题。

1、线程池中的工作线程少于5个时，将会创建新的工作线程执行异步任务（红色表示新任务，下同）





2、线程池中已经有5个线程，缓冲队列未满，异步任务将会放到缓冲队列中等待





3、线程池中已经有5个线程，缓冲队列已满，那么线程池将新开工作线程执行异步任务





问题：Android的设备一般不超过2个cpu核心，过多的线程会造成线程间切换频繁,消耗系统资源。

4、线程池中已经有128个线程，缓冲队列已满，如果此时向线程提交任务，将会抛出RejectedExecutionException





问题：抛出的错误不catch的话会导致程序FC。

好吧，理论分析之后还是要结合实际例子，我们通过实现一个模拟异步获取网络图片的例子，看看会不会出现上面提到的问题。

例子：使用GridView模拟异步加载大量图片

ActivityA.java

?




由运行图可见

当网络情况较差，异步任务不能尽快完成执行的情况下，新开的线程会造成listview滑动不流畅。当开启的工作线程过多时，还有出现FC的可能。

至此，你还相信万能的AsyncTask吗？至于你信不信，反正我不信。

总结：

AsyncTask可能存在新开大量线程消耗系统资源和导致应用FC的风险，因此，我们需要根据自己的需求自定义不同的线程池，由于篇幅问题，将留到下篇再讲。

文章转自：http://blog.csdn.net/mylzc/article/details/6784415