AsyncTask的新認識

我也是參考下面兩篇頗有價值的文檔，而後作一個總結的：

http://blog.csdn.net/hitlion2008/article/details/7983449

http://blog.csdn.net/mylzc/article/details/6784415

 

最近主管讓我看一下某個性能方面的問題，場景相似於一個weibo頁，外層weibo列表加載不少圖片並非很卡，可是進入單個weibo，評論列表裏面滑動有時就會卡頓。緩存方面本來已經作好，那到底是爲何呢？

想到的主要緣由：列表頁同一時間相對圖片須要下載的並非不少，評論頁的話都是小圖片，屏幕裏可見區域裏須要下載的圖片較多，因此會卡頓。

找了一個下午，發現了上面這兩篇文章，在API10(包括10)以後AsycnTask的實現有了大變化。10以前默認是最多5個線程運行，超過5個的就要等待。google在以後意識到了這個問題，增長了一個executeOnExecutor的方法，能夠自定義線程池來運行和調度Thread。原來的execute方法到了api10以後默認就是按提交的次序，每次只啓動一個線程執行一個任務，完成以後再執行第二個任務，也就是至關於只有一個後臺線程在執行所提交的任務(Executors.newSingleThreadPool())。而後改成根據api版本號來分別調用前者或者executeOnExecuteor方法，並傳入本身定義的Executor

private static final int CORE_POOL_SIZE = 5;
private static final int MAXIMUM_POOL_SIZE = 128;
private static final int KEEP_ALIVE = 1;

private static final BlockingQueue<Runnable> sPoolWorkQueue =
            new LinkedBlockingQueue<Runnable>(10);

    /**
     * An {@link Executor} that can be used to execute tasks in parallel.
     */
public static final Executor THREAD_POOL_EXECUTOR
            = new ThreadPoolExecutor(CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE,
                    TimeUnit.SECONDS, sPoolWorkQueue, sThreadFactory);

能夠在executeOnExecuteor根據本身要求第一個參數傳入

new ThreadPoolExecutor(CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE,
TimeUnit.SECONDS, sPoolWorkQueue, sThreadFactory)，這樣的話能夠本身控制並行最多幾個線程運行，緩衝隊列有多大，緩衝隊列也滿後能夠作多開多少線程。

經過這麼修改後發現圖片加載很快，並且在老的android機器上測試也不會有何問題。

 

疑問：

1.文章中說：executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR)就跟2.3版本的AsyncTask.execute()效果是同樣的

我感受仍是不太同樣。

2.上面桔黃色部分，我看了source,感受仍是用了默認5個線程的THREAD_POOL_EXECUTOR而並非1個的newSingleThreadPool。