AsyncTask 真的在概念上存在缺陷还是我只是错过了一些东西？

Question

我已经研究这个问题几个月了，提出了不同的解决方案，但我对此并不满意，因为它们都是大规模的黑客攻击。我仍然不敢相信一个设计上有缺陷的类进入了框架并且没有人谈论它，所以我想我一定是错过了一些东西。

问题出在 AsyncTask 上。根据文档它

“允许执行后台操作 操作并公布结果 UI线程无需操作 线程和/或处理程序。”

然后，该示例继续展示如何在 onPostExecute() 中调用一些示例性的 showDialog() 方法。然而，这似乎完全对我来说这是人为的，因为显示对话框总是需要对有效的上下文的引用，并且 AsyncTask 绝不能持有对上下文对象的强引用

。原因很明显：如果触发任务的活动被破坏怎么办？这种情况可能一直发生，例如，因为您翻转了屏幕，如果任务保留对创建它的上下文的引用，那么您不仅要保留。到一个无用的上下文对象（窗口将被破坏，任何 UI 交互都会失败并出现异常！），

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

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

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

我的解决方案（在 Droid-Fu 库中实现）是维护以下映射：从组件名称到唯一应用程序对象上的当前实例的弱引用。每当 AsyncTask 启动时，它都会在该映射中记录调用上下文，并且在每次回调时，它都会从该映射中获取当前上下文实例。这可以确保您永远不会引用过时的上下文实例，并且您始终可以在回调中访问有效的上下文，以便您可以在那里执行有意义的 UI 工作。它也不会泄漏，因为引用很弱，并且当给定组件的实例不再存在时会被清除。

尽管如此，它仍然是一个复杂的解决方法，需要对一些 Droid-Fu 库类进行子类化，这使得这是一种相当侵入性的方法。

现在我只想知道：我是否只是严重遗漏了一些东西，或者 AsyncTask 真的完全有缺陷吗？您使用它的体验如何？您是如何解决这些问题的？

感谢您的意见。

Answer 1

像这样的事情怎么样：

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

Answer 2

原因很明显：如果
活动被破坏
触发任务了吗？

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

Answer 3

看起来AsyncTask不仅仅是概念上的缺陷。它还因兼容性问题而无法使用。 Android 文档中写道：

首次引入时，AsyncTasks 是在单个后台线程上串行执行的。 从 DONUT 开始，这被更改为允许多个任务并行操作的线程池。< /em> 启动 HONEYCOMB，任务又回到在单线程上执行，以避免并行执行引起的常见应用程序错误。 如果您确实想要并行执行，可以使用 > executeOnExecutor(Executor, Params...) 此方法的版本 THREAD_POOL_EXECUTOR; 但是，请参阅其中有关其使用警告的评论。

executeOnExecutor() 和 THREAD_POOL_EXECUTOR 均在 API 级别 11 中添加 >（Android 3.0.x，蜂窝）。

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

如果你想同时针对 2.x 和 3.0+，事情就变得非常棘手。

此外，文档说：

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

Answer 4

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

活动是一个控制器，控制器不应启动可能比视图寿命更长的操作。也就是说，AsyncTasks 应该从 Model 使用，从一个不绑定到 Activity 生命周期的类 - 请记住，Activities 在轮换时被销毁。 （对于View，您通常不会对从 android.widget.Button 派生的类进行编程，但您可以。通常，您对 View 所做的唯一事情是 xml。）

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

Answer 5

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

实现它们的通常方法是在 Activity 方法之一的范围内创建一个新的 AsyncTask 实例。因此，如果 Activity 被销毁，那么一旦 AsyncTask 完成，它是否将无法访问并有资格进行垃圾回收？因此，对活动的引用并不重要，因为 AsyncTask 本身不会挂起。

Answer 6

对您的活动保留 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]);
            }
        }
    }

}

Answer 7

为什么不直接重写所属 Activity 中的 onPause() 方法并从那里取消 AsyncTask 呢？

Answer 8

你是绝对正确的 - 这就是为什么在活动中使用异步任务/加载器来获取数据的运动正在获得动力。其中一种新方法是使用 Volley 框架，该框架本质上在以下情况下提供回调：数据已准备就绪 - 与 MVC 模型更加一致。 Volley 在 2013 年 Google I/O 大会上流行起来。不知道为什么更多的人没有意识到这一点。

Answer 9

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

Answer 10

我以为取消有效，但事实并非如此。

在这里他们 RTFMing 对此：

“”如果任务已经开始，那么 mayInterruptIfRunning
参数决定执行此任务的线程是否应该
被中断以试图停止任务。”

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

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

Answer 11

您最好将 AsyncTask 视为与 Activity、Context、ContextWrapper 等更紧密耦合的东西。当其范围被完全理解时，它会更加方便。

确保您的生命周期中有取消策略，以便它最终会被垃圾收集，并且不再保留对您的活动的引用，并且它也可以被垃圾收集。

如果在离开 Context 时取消 AsyncTask，您将遇到内存泄漏和 NullPointerExceptions，如果您只需要提供诸如 Toast 之类的简单对话框之类的反馈，那么应用程序上下文的单例将有助于避免 NPE 问题。

AsyncTask 并不全是坏事，但肯定有很多神奇的事情发生，可能会导致一些不可预见的陷阱。

Answer 12

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