AsyncTaskは本当に概念的に欠陥があるのですか、それとも何か不足していますか？

私は今月この問題を調査してきましたが、さまざまな解決策を考え出しましたが、それらはすべて大規模なハックなので、満足できません。デザインに欠陥のあるクラスがフレームワークに組み込まれ、誰もそれについて話していないとはまだ信じられないので、私は何かを逃しているにちがいないと思います。

問題はにありAsyncTaskます。ドキュメントによると

「スレッドやハンドラーを操作しなくても、UIスレッドでバックグラウンド操作を実行して結果を公開できます。」

次に、例では引き続き、いくつかの例示的なshowDialog()メソッドがで呼び出される方法を示しますonPostExecute()。ただし、ダイアログを表示するには常に有効なへの参照が必要であり、AsyncTask がコンテキストオブジェクトへの強い参照を保持してはならないため、これは私には完全にContext不自然に思われます。

その理由は明らかです。タスクをトリガーしたアクティビティが破棄された場合はどうなりますか？これは常に発生する可能性があります。たとえば、画面をめくった場合などです。タスクは、それを作成したコンテキストへの参照を保持したい場合、あなたは（ウィンドウが破壊されているでしょうし、無用なコンテキストオブジェクトへの上に保持しているだけでなく、任意の UIの相互作用が例外で失敗します！）、あなたもAを作成する危険性メモリーリーク。

私のロジックにここで欠陥がない限り、これは次のように変換されます：onPostExecute()コンテキストにアクセスできない場合にこのメソッドをUIスレッドで実行するのはどのようなメリットがあるので、これはまったく役に立たないのですか？ここでは意味のあることは何もできません。

回避策の1つは、コンテキストインスタンスをAsyncTaskに渡すのではなく、Handlerインスタンスを渡すことです。これは機能します。ハンドラーはコンテキストとタスクを緩やかにバインドするため、リークの危険を冒すことなく、それらの間でメッセージを交換できます（正しいですか）。しかし、それはAsyncTaskの前提、つまりハンドラーに煩わされる必要がないということは間違っていることを意味します。同じスレッドでメッセージを送受信しているため、ハンドラーを悪用しているようにも見えます（UIスレッドでメッセージを作成し、UIスレッドで実行されるonPostExecute（）で送信します）。

さらに、その回避策を使用しても、コンテキストが破棄されたときに、それが起動したタスクの記録がないという問題があります。つまり、たとえば画面の向きが変わった後など、コンテキストを再作成するときにタスクを再起動する必要があります。これは遅く、無駄です。

これに対する私の解決策（Droid-Fuライブラリで実装されている）は、WeakReferencesのコンポーネント名から、一意のアプリケーションオブジェクトの現在のインスタンスへのマッピングを維持することです。AsyncTaskが起動すると、そのマップに呼び出しコンテキストが記録され、コールバックごとに、そのマッピングから現在のコンテキストインスタンスがフェッチされます。これにより、失効したコンテキストインスタンスを参照することがなくなり、コールバック内の有効なコンテキストに常にアクセスできるため、そこで有効なUI作業を実行できます。また、参照が弱く、特定のコンポーネントのインスタンスが存在しなくなったときにクリアされるため、リークも発生しません。

それでも、これは複雑な回避策であり、いくつかのDroid-Fuライブラリクラスをサブクラス化する必要があるため、これはかなり煩わしいアプローチになります。

今私は単に知りたいです：私は何かを大規模に欠落していますか、それともAsyncTaskは本当に完全に欠陥がありますか？あなたの経験はどのように機能していますか？これらの問題をどのように解決しましたか？

ご入力いただきありがとうございます。

このようなものはどうですか：

class MyActivity extends Activity {
    Worker mWorker;

    static class Worker extends AsyncTask<URL, Integer, Long> {
        MyActivity mActivity;

        Worker(MyActivity activity) {
            mActivity = activity;
        }

        @Override
        protected Long doInBackground(URL... urls) {
            int count = urls.length;
            long totalSize = 0;
            for (int i = 0; i < count; i++) {
                totalSize += Downloader.downloadFile(urls[i]);
                publishProgress((int) ((i / (float) count) * 100));
            }
            return totalSize;
        }

        @Override
        protected void onProgressUpdate(Integer... progress) {
            if (mActivity != null) {
                mActivity.setProgressPercent(progress[0]);
            }
        }

        @Override
        protected void onPostExecute(Long result) {
            if (mActivity != null) {
                mActivity.showDialog("Downloaded " + result + " bytes");
            }
        }
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        mWorker = (Worker)getLastNonConfigurationInstance();
        if (mWorker != null) {
            mWorker.mActivity = this;
        }

        ...
    }

    @Override
    public Object onRetainNonConfigurationInstance() {
        return mWorker;
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        if (mWorker != null) {
            mWorker.mActivity = null;
        }
    }

    void startWork() {
        mWorker = new Worker(this);
        mWorker.execute(...);
    }
}

理由は明らかです。タスクをトリガーしたアクティビティが破棄された場合はどうなりますか？

のアクティビティとの関連付けを手動で解除AsyncTaskしonDestroy()ます。手動に新しいアクティビティを再度関連付けるAsyncTaskの中でonCreate()。これには、静的内部クラスまたは標準Javaクラスのいずれかと、おそらく10行のコードが必要です。

以下のように見えますAsyncTaskビットですよりちょうどより概念的に不備。また、互換性の問題により使用できません。Androidのドキュメントは次のとおりです。

最初に導入されたとき、AsyncTasksは単一のバックグラウンドスレッドで順次実行されました。 DONUTから、これはスレッドのプールに変更され、複数のタスクが並行して動作できるようになりました。 HONEYCOMBを開始すると、タスクは単一のスレッドで実行されるように戻り、並列実行によって引き起こされる一般的なアプリケーションエラーを回避します。 本当に並列実行が必要な場合は executeOnExecutor(Executor, Params...) 、このメソッドのバージョンをで 使用できますTHREAD_POOL_EXECUTOR。ただし、その使用に関する警告については、解説を参照してください。

executeOnExecutor()とTHREAD_POOL_EXECUTORはどちらもAPIレベル11で追加されています（Android 3.0.x、HONEYCOMB）。

つまり、2つAsyncTaskのを作成して2つのファイルをダウンロードした場合、2番目のダウンロードは最初のダウンロードが完了するまで開始されません。2つのサーバーを介してチャットし、最初のサーバーがダウンしている場合、最初のサーバーへの接続がタイムアウトするまで、2番目のサーバーに接続しません。（もちろん、API11の新機能を使用しない限り、これによりコードが2.xと互換性がなくなります）。

また、2.xと3.0+の両方をターゲットにしたい場合は、かなり注意が必要です。

さらに、ドキュメントは言う：

注意：ワーカースレッドの使用時に発生する可能性があるもう1つの問題は、ランタイム構成の変更（ユーザーが画面の向きを変更した場合など）によるアクティビティの予期しない再起動であり、ワーカースレッドが破壊される可能性があります。これらの再起動中にタスクを永続化する方法と、アクティビティが破棄されたときにタスクを適切にキャンセルする方法については、Shelvesサンプルアプリケーションのソースコードを参照してください。

おそらく、Googleを含め、私たち全員AsyncTaskがMVCの観点から誤用しています。

アクティビティはコントローラーであり、コントローラーはビューよりも長く存続する可能性のある操作を開始しないでください。つまり、AsyncTasksは、Modelから、Activityライフサイクルにバインドされていないクラスから使用する必要があります。Activityはローテーションで破棄されることに注意してください。（ビューに関しては、通常android.widget.Buttonなどから派生したクラスをプログラムすることはありませんが、プログラムすることはできます。通常、ビューに対して行うことはxml のみです。）

つまり、アクティビティのメソッドにAsyncTask派生物を配置するのは間違っています。OTOH、アクティビティでAsyncTasksを使用してはならない場合、AsyncTaskはその魅力を失います。以前は迅速で簡単な修正として宣伝されていました。

AsyncTaskからのコンテキストへの参照でメモリリークが発生する危険性があるかどうかはわかりません。

それらを実装する通常の方法は、アクティビティのいずれかのメソッドのスコープ内に新しいAsyncTaskインスタンスを作成することです。したがって、アクティビティが破棄された場合、AsyncTaskが完了すると、到達できなくなり、ガベージコレクションの対象になりますか？したがって、AsyncTask自体はハングアップしないため、アクティビティへの参照は重要ではありません。

あなたの活動にWeekReferenceを保持する方がより堅牢になります：

public class WeakReferenceAsyncTaskTestActivity extends Activity {
    private static final int MAX_COUNT = 100;

    private ProgressBar progressBar;

    private AsyncTaskCounter mWorker;

    @SuppressWarnings("deprecation")
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_async_task_test);

        mWorker = (AsyncTaskCounter) getLastNonConfigurationInstance();
        if (mWorker != null) {
            mWorker.mActivity = new WeakReference<WeakReferenceAsyncTaskTestActivity>(this);
        }

        progressBar = (ProgressBar) findViewById(R.id.progressBar1);
        progressBar.setMax(MAX_COUNT);
    }

    @Override
    public boolean onCreateOptionsMenu(Menu menu) {
        getMenuInflater().inflate(R.menu.activity_async_task_test, menu);
        return true;
    }

    public void onStartButtonClick(View v) {
        startWork();
    }

    @Override
    public Object onRetainNonConfigurationInstance() {
        return mWorker;
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        if (mWorker != null) {
            mWorker.mActivity = null;
        }
    }

    void startWork() {
        mWorker = new AsyncTaskCounter(this);
        mWorker.execute();
    }

    static class AsyncTaskCounter extends AsyncTask<Void, Integer, Void> {
        WeakReference<WeakReferenceAsyncTaskTestActivity> mActivity;

        AsyncTaskCounter(WeakReferenceAsyncTaskTestActivity activity) {
            mActivity = new WeakReference<WeakReferenceAsyncTaskTestActivity>(activity);
        }

        private static final int SLEEP_TIME = 200;

        @Override
        protected Void doInBackground(Void... params) {
            for (int i = 0; i < MAX_COUNT; i++) {
                try {
                    Thread.sleep(SLEEP_TIME);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                Log.d(getClass().getSimpleName(), "Progress value is " + i);
                Log.d(getClass().getSimpleName(), "getActivity is " + mActivity);
                Log.d(getClass().getSimpleName(), "this is " + this);

                publishProgress(i);
            }
            return null;
        }

        @Override
        protected void onProgressUpdate(Integer... values) {
            super.onProgressUpdate(values);
            if (mActivity != null) {
                mActivity.get().progressBar.setProgress(values[0]);
            }
        }
    }

}

onPause()所有するアクティビティのメソッドをオーバーライドしてAsyncTask、そこからをキャンセルしないのはなぜですか？

あなたは絶対的に正しいです-それが、データをフェッチするためのアクティビティで非同期タスク/ローダーを使用することから離れる動きが勢いを増している理由です。新しい方法の1つは、データの準備ができたら基本的にコールバックを提供するVolleyフレームワークを使用することです。MVCモデルとの整合性が大幅に向上します。VolleyはGoogle I / O 2013で人気を博しました。なぜこれを知らない人が増えているのかわかりません。

個人的には、Threadを拡張し、コールバックインターフェイスを使用してUIを更新します。FCの問題がなければ、AsyncTaskを正しく機能させることはできませんでした。実行プールの管理には、非ブロッキングキューも使用します。

キャンセルは機能すると思いましたが、機能しません。

ここで彼らはそれについてRTFMingしています：

""タスクが既に開始されている場合、mayInterruptIfRunningパラメータは、このタスクを実行しているスレッドがタスクを停止するために中断されるべきかどうかを決定します。 "

ただし、スレッドが割り込み可能であることを意味するものではありません。これはJavaの問題であり、AsyncTaskの問題ではありません。」

http://groups.google.com/group/android-developers/browse_thread/thread/dcadb1bc7705f1bb/add136eb4949359d?show_docid=add136eb4949359d

AsyncTaskは、Activity、Context、ContextWrapperなどとより密接に結合しているものと考えるのがよいでしょう。スコープを完全に理解すると、より便利になります。

ライフサイクルにキャンセルポリシーがあり、最終的にはガベージコレクションされ、アクティビティへの参照が保持されなくなり、ガベージコレクションもできるようにしてください。

コンテキストから離れるときにAsyncTaskをキャンセルしないと、メモリリークとNullPointerExceptionsが発生します。単純なダイアログのトーストのようなフィードバックを提供するだけの場合は、アプリケーションコンテキストのシングルトンがNPEの問題を回避するのに役立ちます。

AsyncTaskはすべてが悪いわけではありませんが、予期しない落とし穴につながる可能性のある多くの魔法が確実に進行しています。

「操作の経験」について：すべてのAsyncTaskとともにプロセスを強制終了することが可能で、Androidはユーザーが何も言及しないようにアクティビティスタックを再作成します。