我不确定从AsyncTask引用上下文是否存在内存泄漏的风险。

实现它们的通常方法是在Activity的一个方法的范围内创建一个新的AsyncTask实例。所以如果活动被销毁，那么一旦AsyncTask完成，它不会是不可达的，然后有资格进行垃圾收集吗?因此对活动的引用并不重要，因为AsyncTask本身不会挂在那里。

就我个人而言，我只是扩展Thread并使用回调接口来更新UI。我永远不能让AsyncTask工作正确没有FC问题。我还使用非阻塞队列来管理执行池。

原因很明显:如果 活动被破坏 触发任务?

在onDestroy()中手动解除活动与AsyncTask的关联。手动将新活动重新关联到onCreate()中的AsyncTask。这需要一个静态内部类或一个标准Java类，再加上大约10行代码。

这样怎么样:

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(...);
    }
}

我以为取消有用，其实没用。

他们在这里rtming:

"如果任务已经开始，则mayinterruptifrunrunning . 参数确定执行此任务的线程是否应该是 试图停止任务时被打断。”

然而，这并不意味着线程是可中断的。这是一个 Java的东西，不是AsyncTask的东西

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

为什么不重写onPause()方法在拥有的活动和取消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]);
            }
        }
    }

}

至于“使用它的经验”:有可能杀死进程连同所有AsyncTasks, Android将重新创建活动堆栈，这样用户就不会提及任何事情。

看起来AsyncTask不仅仅是概念上的缺陷。由于兼容性问题，它也无法使用。安卓文档中写道:

When first introduced, AsyncTasks were executed serially on a single background thread. Starting with DONUT, this was changed to a pool of threads allowing multiple tasks to operate in parallel. Starting HONEYCOMB, tasks are back to being executed on a single thread to avoid common application errors caused by parallel execution. If you truly want parallel execution, you can use the executeOnExecutor(Executor, Params...) version of this method with THREAD_POOL_EXECUTOR; however, see commentary there for warnings on its use.

executeOnExecutor()和THREAD_POOL_EXECUTOR都是在API级别11 (Android 3.0)中添加的。x,蜂窝)。

这意味着如果你创建了两个asynctask来下载两个文件，第二次下载将在第一次下载完成后才开始。如果您通过两个服务器聊天，并且第一个服务器宕机，那么在第一个服务器连接超时之前，您将不会连接到第二个服务器。(当然，除非您使用新的API11特性，但这会使您的代码与2.x不兼容)。

如果你想同时瞄准2。X和3.0+，这些东西变得非常棘手。

此外，医生说:

警告:使用工作线程时可能遇到的另一个问题是由于运行时配置更改(例如用户更改屏幕方向)而在活动中意外重启，这可能会破坏工作线程。要了解如何在这些重新启动过程中保持任务，以及如何在活动被销毁时正确地取消任务，请参阅Shelves示例应用程序的源代码。

可能我们所有人，包括谷歌，都从MVC的角度误用了AsyncTask。

一个活动是一个控制器，控制器不应该启动可能比视图活得更久的操作。也就是说，AsyncTasks应该从Model中使用，从一个不绑定到Activity生命周期的类中使用——记住，Activity在旋转时被销毁。(至于视图，你通常不编写从android.widget派生的类。纽扣，但你可以。通常，你对View所做的唯一一件事就是xml。)

换句话说，将AsyncTask衍生物放在Activities的方法中是错误的。OTOH，如果我们不能在活动中使用AsyncTask, AsyncTask就失去了它的吸引力:它曾经被宣传为一个快速和简单的修复。

你是绝对正确的-这就是为什么在活动中使用异步任务/加载器来获取数据的运动正在获得动力。其中一种新方法是使用Volley框架，它本质上是在数据准备就绪时提供回调——这与MVC模型更加一致。凌空在谷歌I/O 2013普及。不知道为什么更多的人没有意识到这一点。

你最好把AsyncTask看作是与Activity、Context、ContextWrapper等紧密耦合的东西。当它的范围被充分理解时，它更方便。

确保您在生命周期中有一个取消策略，这样它最终将被垃圾收集，不再保留对您的活动的引用，它也可以被垃圾收集。

如果不取消AsyncTask，而遍历离开你的上下文，你会遇到内存泄漏和nullpointerexception，如果你只是需要提供一个简单的对话框吐司反馈，那么你的应用上下文的单例将有助于避免NPE问题。

AsyncTask并不全是坏的，但肯定有很多神奇的东西会导致一些不可预见的陷阱。