AsyncTask在概念上确实存在缺陷吗？还是我只是想念一些东西？

我已经研究了这个问题好几个月了，并提出了不同的解决方案，我不满意，因为它们都是大型黑客。我仍然不敢相信，一个存在设计缺陷的类将其纳入了框架，并且没有人在谈论它，所以我想我肯定一定会丢失一些东西。

问题出在哪里AsyncTask。根据文档吧

“允许执行后台操作并在UI线程上发布结果，而无需操纵线程和/或处理程序。”

然后，该示例继续说明如何showDialog()在中调用某些示例性方法onPostExecute()。但是，这似乎完全是我想做的，因为显示对话框始终需要引用有效对象Context，而AsyncTask 绝不能持有对上下文对象的强引用。

原因很明显：如果活动被破坏而触发了任务，该怎么办？这可能一直发生，例如因为您翻转了屏幕。如果该任务将保留对创建它的上下文的引用，则您不仅会保留一个无用的上下文对象（该窗口将被破坏，并且任何 UI交互都会失败，并带有异常！），您甚至可能会冒险创建一个内存泄漏。

除非我的逻辑在这里有缺陷，否则这将转化为：onPostExecute()完全没有用，因为如果您无权访问任何上下文，在UI线程上运行此方法有什么好处？您在这里不能做任何有意义的事情。

一种解决方法是不将上下文实例传递给AsyncTask，而是传递一个Handler实例。这行得通：由于Handler松散地绑定了上下文和任务，因此您可以在它们之间交换消息而不会冒泄漏的风险（对吗？）。但这意味着AsyncTask的前提是错误的，即您不必费心处理程序。由于您是在同一个线程上发送和接收消息，因此这似乎在滥用Handler（您在UI线程上创建消息，并在同样在UI线程上执行的onPostExecute（）中通过它发送消息）。

最重要的是，即使有了这种解决方法，您仍然面临这样的问题：当上下文被销毁时，您没有记录它触发的任务。这意味着在重新创建上下文时（例如，在屏幕方向更改后），您必须重新启动所有任务。这是缓慢且浪费的。

我对此的解决方案（在Droid-Fu库中实现）是WeakReference在唯一的应用程序对象上维护s从组件名称到其当前实例的映射。每当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()。手动将新活动重新关联到AsyncTaskin 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）。

这意味着，如果创建两个AsyncTasks来下载两个文件，则直到第一个下载完成后，第二个下载才会开始。如果您通过两台服务器聊天，而第一台服务器已关闭，则在与第一台服务器的连接超时之前，您将无法连接到第二台服务器。（当然，除非您使用新的API11功能，但这会使您的代码与2.x不兼容）。

而且，如果您希望同时针对2.x和3.0+，那么这些东西将变得非常棘手。

另外，文档说：

警告：使用工作线程时可能遇到的另一个问题是由于运行时配置更改（例如，当用户更改屏幕方向时），活动意外重启，这可能会破坏工作线程。若要查看如何在这些重新启动之一期间继续执行任务，以及在活动被销毁后如何正确取消任务，请参阅Shelves示例应用程序的源代码。

AsyncTask从MVC的角度来看，包括Google在内的所有人都可能在滥用。

一个Activity是一个Controller，并且Controller不应启动可能会使View失效的操作。也就是说，应从Model中使用AsyncTasks ，而从不绑定到Activity生命周期的类中使用AsyncTasks- 请记住，Activation在旋转时被破坏。（对于View，您通常不编程从android.widget.Button派生的类，但是可以。通常，您对View所做的唯一事情就是xml。）

换句话说，将AsyncTask派生类放置在Activity方法中是错误的。OTOH，如果我们一定不能在Activity中使用AsyncTasks，那么AsyncTask就会失去吸引力：它曾经被宣传为一种快速简便的修复方法。

我不确定是否确实会由于引用AsyncTask中的上下文而冒内存泄漏的风险。

实现它们的通常方法是在Activity方法之一的范围内创建一个新的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()拥有的Activity中的方法并AsyncTask从那里取消？

您是完全正确的-这就是为什么在活动中不再使用异步任务/加载器来获取数据的原因越来越流行。一种新方法是使用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等紧密结合的东西。充分了解其范围后，它会更加方便。

确保您在生命周期中有取消策略，以便最终将其进行垃圾回收，并且不再保留对您的活动的引用，也可以对其进行垃圾回收。

在离开Context时没有取消AsyncTask的情况下，您将遇到内存泄漏和NullPointerExceptions的情况，如果仅需要像Toast这样的简单对话框提供反馈，则单身应用上下文将有助于避免NPE问题。

AsyncTask并不都是坏事，但是肯定有很多不可思议的事情会导致一些无法预料的陷阱。

至于“使用它的经验”：可能会杀死所有AsyncTasks 进程，Android将重新创建活动堆栈，以便用户不会提及任何内容。