在解析前，我們先來看下一般我們使用的情況是怎樣的
下面寫了一個簡單的demo，用來做個簡單的任務，從1數(shù)到100，同時調(diào)用publishProgress(i);來更新下進度。
我想用過的人自己直接閱讀下面代碼沒有任何問題。
class MyDemoAsyncTask extends AsyncTask<Integer, Integer, String> {
private TextView textView;
private ProgressBar progressBar;
public MyDemoAsyncTask(TextView textView, ProgressBar progressBar) {
super();
this.textView = textView;
this.progressBar = progressBar;
}
@Override
protected void onPreExecute() {
textView.setText("開始執(zhí)行異步線程");
}
@Override
protected String doInBackground(Integer... params) {
for (int i = 1; i <= 100; i += 1) {
publishProgress(i);
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
return "resultString";
}
@Override
protected void onProgressUpdate(Integer... values) {
progressBar.setProgress(values[0]);
}
@Override
protected void onPostExecute(String result) {
textView.setText("異步操作執(zhí)行結束" + result);
}
}
問題
好了，這樣一個demo，有幾點需要解決的問題。
為何他只能執(zhí)行一次，再調(diào)用execute()就會出錯
doInBackground()是怎么做到在后臺執(zhí)行的
為何 onPreExecute()，onProgressUpdate(）和onPostExecute(）能運行在主線程
為何Task的實例必須在UI thread中創(chuàng)建,execute方法必須在UI thread中調(diào)用；
為何不能手動的調(diào)用onPreExecute()，onPostExecute()，doInBackground(),，onProgressUpdate()這幾個方法；
帶著這么幾個問題，我們開始深入的看下AsyncTask的源代碼。
起源
讓我們根據(jù)線索，先看下execute（）方法吧。
@MainThread
public final AsyncTask<Params, Progress, Result> execute(Params... params) {
return executeOnExecutor(sDefaultExecutor, params);
}
@MainThread
public final AsyncTask<Params, Progress, Result> executeOnExecutor(Executor exec,
Params... params) {
if (mStatus != Status.PENDING) {
switch (mStatus) {
case RUNNING:
throw new IllegalStateException("Cannot execute task:"
+ " the task is already running.");
case FINISHED:
throw new IllegalStateException("Cannot execute task:"
+ " the task has already been executed "
+ "(a task can be executed only once)");
}
}
mStatus = Status.RUNNING;
onPreExecute();
mWorker.mParams = params;
exec.execute(mFuture);
return this;
}
看到這里，我們似乎得到了第一個問題的答案，為何只能執(zhí)行一次，因為AsyncTask會對自己的狀態(tài)做一些標記，如果已經(jīng)是
RUNNING或者FINISHED狀態(tài)，那么就會拋出異常，那么為何需要狀態(tài)呢？這個需要我們繼續(xù)探索在調(diào)用了
Exccute()后，我們看到他順勢也調(diào)用了onPreExecute();，這個運行在主線程也好理解了。-
我們還看到，他使用本地的
sDefaultExecutor執(zhí)行器來執(zhí)行了一個mFuture,我們來看下這個sDefaultExecutor，因為我們都聽說AsyncTask底層是一個線程池，那到底是怎樣的呢？public static final Executor SERIAL_EXECUTOR = new SerialExecutor(); private static volatile Executor sDefaultExecutor = SERIAL_EXECUTOR; private static class SerialExecutor implements Executor { final ArrayDeque<Runnable> mTasks = new ArrayDeque<Runnable>(); Runnable mActive; public synchronized void execute(final Runnable r) { mTasks.offer(new Runnable() { public void run() { try { r.run(); } finally { scheduleNext(); } } }); if (mActive == null) { scheduleNext(); } } protected synchronized void scheduleNext() { if ((mActive = mTasks.poll()) != null) { THREAD_POOL_EXECUTOR.execute(mActive); } } } private static final int CPU_COUNT = Runtime.getRuntime().availableProcessors(); private static final int CORE_POOL_SIZE = CPU_COUNT + 1; private static final int MAXIMUM_POOL_SIZE = CPU_COUNT * 2 + 1; private static final int KEEP_ALIVE = 1; public static final Executor THREAD_POOL_EXECUTOR = new ThreadPoolExecutor(CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE, TimeUnit.SECONDS, sPoolWorkQueue, sThreadFactory);通過代碼我們看到，這個
sDefaultExecutor是最終用了一個靜態(tài)的內(nèi)部類SerialExecutor，這個人如其名，是個線性執(zhí)行的，一次只執(zhí)行一個。
而且每次只運行一個異步任務
而且每次只運行一個異步任務
而且每次只運行一個異步任務
當然了你也可以根據(jù)自己的需要，指定自己的線程池
為了加深你對這個的理解，我寫了個簡單的demo,我們生成10個task，然后執(zhí)行，看打印的時間是怎樣的for (int i = 0; i < 10; i++) { new MySerialAsyncTask().execute(i); } class MySerialAsyncTask extends AsyncTask<Integer, Integer, String> { @Override protected String doInBackground(Integer... params) { Log.e(TAG, " task " + params[0] + " isRuning"); try { Thread.sleep(3000); } catch (InterruptedException e) { e.printStackTrace(); } return "" + params[0]; } @Override protected void onPostExecute(String result) { Log.e(TAG, " task " + result + " finish"); } }
打印結果
12-09 03:09:30.760 23235-23267/org.test.demo E/LoginActivty: task 0 isRuning
12-09 03:09:33.780 23235-23235/org.test.demo E/LoginActivty: task 0 finish
12-09 03:09:33.780 23235-23307/org.test.demo E/LoginActivty: task 1 isRuning
12-09 03:09:36.784 23235-23235/org.test.demo E/LoginActivty: task 1 finish
12-09 03:09:36.784 23235-23348/org.test.demo E/LoginActivty: task 2 isRuning
12-09 03:09:39.792 23235-23235/org.test.demo E/LoginActivty: task 2 finish
12-09 03:09:39.808 23235-23395/org.test.demo E/LoginActivty: task 3 isRuning
12-09 03:09:42.812 23235-23235/org.test.demo E/LoginActivty: task 3 finish
12-09 03:09:42.812 23235-23438/org.test.demo E/LoginActivty: task 4 isRuning
12-09 03:09:45.812 23235-23438/org.test.demo E/LoginActivty: task 5 isRuning
12-09 03:09:45.812 23235-23235/org.test.demo E/LoginActivty: task 4 finish
12-09 03:09:48.816 23235-23438/org.test.demo E/LoginActivty: task 6 isRuning
12-09 03:09:48.816 23235-23235/org.test.demo E/LoginActivty: task 5 finish
12-09 03:09:51.820 23235-23438/org.test.demo E/LoginActivty: task 7 isRuning
12-09 03:09:51.820 23235-23235/org.test.demo E/LoginActivty: task 6 finish
12-09 03:09:54.820 23235-23438/org.test.demo E/LoginActivty: task 8 isRuning
12-09 03:09:54.820 23235-23235/org.test.demo E/LoginActivty: task 7 finish
12-09 03:09:57.824 23235-23438/org.test.demo E/LoginActivty: task 9 isRuning
12-09 03:09:57.824 23235-23235/org.test.demo E/LoginActivty: task 8 finish
12-09 03:10:00.824 23235-23235/org.test.demo E/LoginActivty: task 9 finish
我們看到，嚴格的沒三秒后才執(zhí)行下一個任務
當然，我們完全可以并發(fā)執(zhí)行，用AsyncTask.THREAD_POOL_EXECUTOR，
根據(jù)參數(shù)的值，我們可知道是四種常見的線程池之一的延遲連接池（newScheduledThreadPool），
我們直接用asyncTask.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR, task);
就可以多任務并發(fā)執(zhí)行了。當然你也可以自定義一個。
之所以這樣，是谷歌基于性能的考慮，所以在3.0版本的時候，就改成這個默認的串行。
另外當如果我們開太多進程并發(fā)的去處理網(wǎng)絡請求，擠在一起，那么很容易會把網(wǎng)速都霸占完，結果每個進程分到的網(wǎng)速就那么點， 導致延遲超時問題。
好了，跳了這么遠，我們繼續(xù)回到主線任務上去
主線：
exec.execute(mFuture);
我們回到上面看到execute()，最后調(diào)用了這句，去執(zhí)行一個mFuture的東東，這個mFuture里面很可能就是執(zhí)行我們業(yè)務內(nèi)容的地方。讓我們?nèi)タ赐滤?/p>
public AsyncTask() {
mWorker = new WorkerRunnable<Params, Result>() {
public Result call() throws Exception {
mTaskInvoked.set(true);
Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
//noinspection unchecked
Result result = doInBackground(mParams);
Binder.flushPendingCommands();
return postResult(result);
}
};
mFuture = new FutureTask<Result>(mWorker) {
@Override
protected void done() {
try {
postResultIfNotInvoked(get());
} catch (InterruptedException e) {
android.util.Log.w(LOG_TAG, e);
} catch (ExecutionException e) {
throw new RuntimeException("An error occurred while executing doInBackground()",
e.getCause());
} catch (CancellationException e) {
postResultIfNotInvoked(null);
}
}
};
}
private static abstract class WorkerRunnable<Params, Result> implements Callable<Result> {
Params[] mParams;
}
在我們的構造器里面，我們看到了我們的變量mFuture,它包著我們的worker，這個worker背后是實現(xiàn)了Callback接口，
而worker里面有一個關鍵的的一句Result result = doInBackground(mParams);,在這個worker里面執(zhí)行了我們的doInBackground方法。然后執(zhí)行的結果Result通過PostResult()做了分發(fā)。
對于Runnable，Callback，FutureTask 和 Future 這幾個湊在一起，有時候還真忘了他們是什么關系。
如果你不是清楚，那么記得這么個結論，我們的Executor會調(diào)用FutureTask里面的run()方法，因為FutureTask內(nèi)部是實現(xiàn)了接口RunnableFuture的Run()方法的，在這個run()方法里面，會調(diào)用這個worker的call()方法。
當這個worker工作完了時候，結果就被保存起來了，這時候FutureTask的done()方法會被調(diào)用，這時候我們可以通過get() 方法得到結果啦。（呵呵，好想把代碼貼出來，所謂有代碼有真像的）
所以看到上面的done（）里面這句postResultIfNotInvoked(get());，就是用來獲取我們的worker的運算結果的。
但最少，看到這里我們的第二個問題，doInBackground是怎么做到在后臺執(zhí)行的就知道了，他在call（）里面執(zhí)行的。然后結果用Handler來post出去的。
另外這個解決了我們的第一個問題，為何他只能執(zhí)行一次，再調(diào)用execute()就會出錯。
因為我們的mFuture只會被執(zhí)行一次，再執(zhí)行是沒有效果的，如果我沒記錯的話 -_-
private Result postResult(Result result) {
@SuppressWarnings("unchecked")
Message message = getHandler().obtainMessage(MESSAGE_POST_RESULT,
new AsyncTaskResult<Result>(this, result));
message.sendToTarget();
return result;
}
private static class AsyncTaskResult<Data> {
final AsyncTask mTask;
final Data[] mData;
AsyncTaskResult(AsyncTask task, Data... data) {
mTask = task;
mData = data;
}
}
再來看下我們的getHandler();
private static Handler getHandler() {
synchronized (AsyncTask.class) {
if (sHandler == null) {
sHandler = new InternalHandler();
}
return sHandler;
}
}
我們的getHandler()返回了一個內(nèi)部靜態(tài)Handler類,還記得上一篇文章說為何要寫成靜態(tài)內(nèi)部類嗎？
通過這段代碼，我們了解到，由于 Handler 需要和主線程交互，而 Handler 作為靜態(tài)內(nèi)部類（靜態(tài)成員在加載類的時候初始化）內(nèi)置于 AsyncTask 中的，所以，AsyncTask 的創(chuàng)建必須在主線程。這樣我們的第四個問題就解決了
private static class InternalHandler extends Handler {
public InternalHandler() {
super(Looper.getMainLooper());
//使用的是一個主線程的looper，這樣就把消息切換到了主線程去了
}
@SuppressWarnings({"unchecked", "RawUseOfParameterizedType"})
@Override
public void handleMessage(Message msg) {
AsyncTaskResult<?> result = (AsyncTaskResult<?>) msg.obj;
switch (msg.what) {
case MESSAGE_POST_RESULT:
// There is only one result
result.mTask.finish(result.mData[0]);
break;
case MESSAGE_POST_PROGRESS:
result.mTask.onProgressUpdate(result.mData);
break;
}
}
}
看到這個Handler的內(nèi)部構造，我們看到一個MESSAGE_POST_PROGRESS消息下調(diào)用onProgressUpdate()，在看下我們的publishProgress()方法，確實發(fā)的就是這個消息
@WorkerThread
protected final void publishProgress(Progress... values) {
if (!isCancelled()) {
getHandler().obtainMessage(MESSAGE_POST_PROGRESS,
new AsyncTaskResult<Progress>(this, values)).sendToTarget();
}
}
這樣我們的第三個問題，為何publishProgress() 可以更主線程UI就知道了。
繼續(xù)回到我們的主任務
在這個結果，我們看到了他最后調(diào)用了result的mTask里面的finish方法。我們看下具體的內(nèi)容是什么
private void finish(Result result) {
if (isCancelled()) {
onCancelled(result);
} else {
onPostExecute(result);
}
mStatus = Status.FINISHED;
}
在這里我們看到如果是被取消了，就調(diào)用onCancelled（），沒取消就對onPostExecute(result);的調(diào)用，這樣基本的流程我們就跑完了。從execute()到onPostExecute()
后記
到這里我們就基本把AsyncTask的主要部分代碼看完了，在實現(xiàn)上使用到了FutureTask，Callback這兩個平時比較少用的類，溫習了下，對他的使用以后就可以更有把握啦。
看完覺得好和不好，歡迎評論下，知道改進，謝謝。
