有没有使用 AsyncTask 比 AsyncTaskLoader 更好的场景？答案

【问题标题】：Is there any scenario where using AsyncTask is better than AsyncTaskLoader?有没有使用 AsyncTask 比 AsyncTaskLoader 更好的场景？
【发布时间】：2018-06-11 02:53:35
【问题描述】：

我目前正在研究 Loaders 以及它们如何克服应用程序生命周期中的屏幕方向等变化，到目前为止，根据我所读到的内容，AsyncTaskLoader 与 AsyncTask 的工作相同，甚至更好。因此，AsyncTask 不应该被认为是过时的，还是它为开发人员提供了一些隐藏的优势？

【问题讨论】：

AsyncTaskLoader 与 AsyncTask 相比需要更多代码。如果在方向改变时不需要保留任务，最好使用 AsyncTask。顺便说一句，您也可以考虑 ViewModel。

标签： android android-asynctask loader

【解决方案1】：

我目前正在研究加载器以及它们如何克服应用程序生命周期中的屏幕方向等变化

架构组件对视图模型和 LiveData 的支持是 Google 当前解决加载程序试图解决的问题的方向。

AsyncTaskLoader 的工作与 AsyncTask 相同，甚至更好

注意AsyncTaskLoader 使用AsyncTask。

AsyncTask 不应该被认为是过时的

是的，只要我们有其他模式和库可以使用（例如，RxJava，LiveData）。话虽如此，正确使用AsyncTask 是一个不错的选择。挑战在于正确使用它（例如，从保留的片段中，注意避免与后台线程上的托管活动交互）。

它是否为开发者提供了一些隐藏的优势？

您的论点似乎是“远洋班轮比划艇有更多的功能，所以我们不应该认为划艇已经过时了吗？”。远洋客轮有其成本，远洋客轮不能做划艇所能做的一切（例如，在浅水中旅行，被拖在卡车后面）。

装载机的设计——就他们曾经有过“设计”的程度而言——是为了：

在后台加载数据，通常通过AsyncTask
在配置更改时保留该数据
当请求的数据发生变化时自动提供更新

并非一切都需要它。例如，加载器模式的目标是读取操作（我们实际上“加载”数据的地方），但它对写入操作（我们正在更改数据的地方）没有真正的帮助。然而，即使我们经历了配置更改，我们仍然希望异步执行写入操作并了解结果。您可以将写操作压缩到加载程序中，但这不是一种自然的方式。使用AsyncTask 或其他东西代替加载程序会更自然。

【讨论】：

【解决方案2】：

这样想，

AsyncTaskLoader 可以在 AsyncTask 所在的任何地方使用。主要优点是能够在生命周期之间持续存在。

如果您使用 AsyncTask 并调用网络操作从 Internet 获取一些数据并且用户旋转手机，您的 AsyncTask 将不得不再次启动任务以获取数据，这可能对您的应用程序有潜在危险因为你可能有内存泄漏。

因此，无论如何，Loader 是 AsyncTask 的演变，它们基本上是改进的 AsyncTasks。

我相信 AsyncTask 仍然存在，因为当您在后台线程中执行一些简单的任务时，您可以更简单地使用带有匿名内部类的 AsyncTask 来执行此操作，并立即将结果传递给 UI 线程。

【讨论】：

因此，基本上，与 AsyncTaskLoader 相比，优势在于它们易于实现。谢谢！