有没有使用AsyncTask优于AsyncTaskLoader的情况？

Question

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

Answer 1

  

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

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

  

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

请注意，AsyncTaskLoader使用AsyncTask。

  

不应该将AsyncTask视为过时的

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

  

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

你的论点似乎是“远洋邮轮比划艇有更多的功能，所以我们不应该认为划艇过时了吗？”。海洋划线员有他们的费用，远洋轮船不能做划艇所能做的一切（例如，在浅水中旅行，被拖在卡车后面）。

装载机的设计 - 在某种程度上它们曾经有过“设计” - 来：

• 通常通过AsyncTask
在后台加载数据
• 跨配置更改保留数据
• 在请求的数据发生变化时自动发送更新

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

Answer 2

这样想，

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

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

所以，无论如何，Loaders是 AsyncTask 的演变，它们基本上是改进的 AsyncTasks 。

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