Android AsyncTaskソースの簡単な分析

分析して見る4.0のソースコード、3.0の下で異なっていて、簡単に分析して、学習過程を記録して、熟知した方法から分析して、次第に深くなります.1.まず構造方法から構造方法を分析する.

  public AsyncTask() {
        mWorker = new WorkerRunnable() {
            public Result call() throws Exception {
                mTaskInvoked.set(true);
                Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
                Result result = doInBackground(mParams);
                Binder.flushPendingCommands();
                return postResult(result);
            }
        };

        mFuture = new FutureTask(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);
                }
            }

主にmWorkerとmFutureオブジェクトを初期化し、この2つの定義を見てみましょう.

    private final WorkerRunnable mWorker;
    private final FutureTask mFuture;
    private static abstract class WorkerRunnable<Params, Result> implements Callable<Result> {
        Params[] mParams;
    }

mWorkerはCallableオブジェクトで、mFutureはFutureTask、javaが発注して提供しています.この2つのクラスについての紹介を見てください.ここでmWorkerはmFutureの構造方法に伝わり、本当に実行されているのはmWorkerのcall方法です.callメソッドの論理は、主にdoInBackgroundとpostResultであり、その前の方法はダウンロードタスクなど、カスタマイズされたバックグラウンド処理です.

private Result postResult(Result result) {
        @SuppressWarnings("unchecked")
        Message message = getHandler().obtainMessage(MESSAGE_POST_RESULT,
                new AsyncTaskResult(this, result));
        message.sendToTarget();
        return result;
    }

このresultは非同期タスクの結果であり,getHandler()処理にこの結果を伝えることが分かる.

    private static Handler getHandler() {
        synchronized (AsyncTask.class) {
            if (sHandler == null) {
                sHandler = new InternalHandler();
            }
            return sHandler;
        }
    }
    private static class InternalHandler extends Handler {
        public InternalHandler() {
            super(Looper.getMainLooper());
        }
        @Override
        public void handleMessage(Message msg) {
            AsyncTaskResult> result = (AsyncTaskResult>) msg.obj;
            switch (msg.what) {
                case MESSAGE_POST_RESULT:result.mTask.finish(result.mData[0]);
                    break;
                case MESSAGE_POST_PROGRESS:
                    result.mTask.onProgressUpdate(result.mData);
                    break;
            }
        }
    }
     private static class AsyncTaskResult<Data> {
        final AsyncTask mTask;
        final Data[] mData;

        AsyncTaskResult(AsyncTask task, Data... data) {
            mTask = task;
            mData = data;
        }
    }

ここでhandlerが呼び出したのはresultです.mTask.finish(result.mData[0])、実はAsyncTaskのfinish()です.

private void finish(Result result) {
        if (isCancelled()) {
            onCancelled(result);
        } else {
            onPostExecute(result);
        }
        mStatus = Status.FINISHED;
    }

finsh()は、まずキャンセルされたかどうかを判断し、そうでない場合はonPostExecuteを呼び出し、そうでない場合はonCancelledを呼び出し、ステータスを完了に設定します.onPostExecuteこれが最後に開発者が書き換える必要がある方法であり,タスクの実行が完了し,この方法をコールバックし,その後開発者のカスタマイズを処理する.同じ理屈でonCancelledも同じです.構造方法から分析を開始し,バックグラウンドタスクの実行と終了のコールバックを分析した.
2.execute()メソッドを解析する上の解析では、タスクの実行がmWorkerとmFutureで行われていることがわかりました.AsyncTaskの使い方でバックグラウンドタスクがサブスレッドで実行されていることがわかります.executeがどのように行われているかを見てみましょう.

     public final AsyncTask<Params, Progress, Result> execute(Params... params) {
        return executeOnExecutor(sDefaultExecutor, params);
    }

     public final AsyncTask<Params, Progress, Result> executeOnExecutor(Executor exec,
            Params... params) {
        /×        ×/
        mStatus = Status.RUNNING;
        onPreExecute();
        mWorker.mParams = params;
        exec.execute(mFuture);
        return this;
    }

最終的に実行されるのはexecuteOnExecuteorであり,まず状態をrunningに設定し,onPreExecuteメソッドを呼び出したのか,これまでコードの実行がメインスレッドにあったのか,onPreExecuteではコントロールの初期化操作を行い,その後パラメータをmWorkerに割り当て,最後にsDefaultExecuterがexecute(mFuture)を実行することができる.上で分析したように、mFutureではバックグラウンドタスクの実行ロジックであり、sDefaultExecutorはスレッドプールであり、どのようにしているかを見てみましょう.ここについてSDK 3.0ちょっと違うから、後で話しましょう.

    public static final Executor SERIAL_EXECUTOR = new SerialExecutor();
    private static volatile Executor sDefaultExecutor = SERIAL_EXECUTOR;
    private static class SerialExecutor implements Executor {
        final ArrayDeque mTasks = new ArrayDeque();
        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);
            }
        }
    }

sDefaultExecutorはスレッドプールであり、そのexecuteメソッドはRunnableを受け入れ、コードに伝わるのはmFutureであり、mTasksはキューであり、すべてのタスクを格納し、mActiveは現在実行されているタスクを表し、executeメソッドでは、まずパラメータを転送するrunメソッドをパッケージし、それから入隊し、初めてここを実行するとき、mActiveは空であり、だからscheduleNext()を実行して、この方法の中で、先に1つの任務を出て、それからTHREAD_POOL_EXECUTOR.execute(mActive);,THREADを見てPOOL_EXECUTOR.

  public static final Executor THREAD_POOL_EXECUTOR
            = new ThreadPoolExecutor(CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE,
                    TimeUnit.SECONDS, sPoolWorkQueue, sThreadFactory);

スレッドプールの最大数、同時に実行できるスレッド数などの情報を設定します.タスク実行スレッドを実際に呼び出す場所です.なぜここに2つのスレッドプールがあるのか、1つ目のスレッドプールは役に立たないようですが、実は1つ目のスレッドプールの役割はタスクのパッケージにあり、そのパッケージのRunnableには、最後にscheduleNext()が追加されているのか、try-finallyに囲まれているのか、つまりこのコードは実行されなければなりません.つまり、1つのタスクが完了した後、再びこの方法を呼び出します.引き続きデキューし、次のタスクを引き続き実行し、実行が完了したらscheduleNext()を引き続き実行し、デキューを継続する.......タスクがすべて実行されるまで、このプロセスを分析すると、複数のタスクの実行は並列ではなく、1つの実行が完了した後に次のタスクを実行し、各時点で1つのタスクしか実行していないという結論が得られます.以前は3.0と言っていましたが、3.0以前のソースコードは見ていませんでしたが、資料を調べてみると、3.0以前は最初のスレッドプールがなく、2番目だけだったので、タスクを実行するのは並列で、前に分析した最初のスレッドプールの役割と一致しています.しかし、ここではもう一つの問題があります.ソースコードには、2番目のスレッドプールに最大タスクの数128が設定されており、この数を超えるとエラーが表示されます.では、3.0以降のAsyncTaskでタスクを実行するのは並列ですか?最初のスレッドプールを上書きするか呼び出さないだけでいいです.1.setDefaultExecutor(Executor exec)メソッドを呼び出します.自分でスレッドプールを書くことも、2番目のスレッドプールを使ってAsyncTaskを伝えることもできます.THREAD_POOL_EXECUTORでいいです.呼び出すときはexecute()ではなくexecuteOnExecutor(Executor exec,Params...params)を呼び出します.最初のパラメータはカスタマイズできますし、THREAD_POOL_EXECUTOR.
3.まとめるもう一つの方法は、onProgressUpdate(Progress...)に進捗情報を表示する方法で、上の分析ではhandlerに、実は処理があり、開発者がpublishProgress()メソッドを呼び出すと、実は内部はhandlerにmsgを送って、それからonProgressUpdateをコールして、開発者が自分で処理します.多分プロセス分析の差は多くないので、簡単に分析しただけです.ソースコードの表示を学ぶには、よく知っている方法から、徐々に深くなることが重要です.道は長くて遠い.
参照先:http://www.cnblogs.com/dolphin0520/p/3949310.html http://blog.csdn.net/singwhatiwanna/article/details/17596225