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的风险，因此，我们需要根据自己的需求自定义不同的线程池，由于篇幅问题，将留到下篇再讲。