6

背景

我听说有一些在后台加载数据的新解决方案比 AsyncTask 更推荐（如loaders）。

问题

AsyncTask 非常好用且易于使用。但是，它有一些限制：

  1. 类本身必须修改，因为它受到待处理任务数量（大约 256 个左右）的限制。当然，在 listView 的适配器中，如果不需要任务，我总是会取消它（例如，当我需要更新用于不同项目的视图时）。

  2. 当重新创建活动/片段时，我还必须全部取消它们（或以不同的方式处理）。

  3. 由于 1&2，我需要管理它们并参考它们

  4. AsyncTask 使用任务队列，有时我需要使用堆栈来代替，因此我必须创建自己的 AsyncTask 类来代替使用堆栈。

问题

AsyncTask 有替代方案吗？

我知道这在之前的一些帖子中被问过（比如这里），但我在想是否有一种新的通用方法可以在后台加载数据来取代 asyncTask。

关于加载器，我认为他们的想法是它们用于数据库和 contentProviders，但它们也可以用于加载（例如）来自 Internet 的数据（如图像文件）吗？

还有一个由 google 制作的很好的示例（这里称为“bitmapFun”），根据我所看到的使用 AsyncTask （甚至扩展它，可能是因为我提到的相同原因）。但也许我也错过了一些东西？

4

3 回答 3

2

是的。

加载器是托管的 AsyncTasks。如果您不使用 Loader，您可能会缺少它们所需的管理。

AsyncTasks（和加载器）是一种非常糟糕的方式来获取设备外的东西。要从远程服务器获取数据，请查看使用 IntentService。请参阅：https ://www.youtube.com/watch?v=xHXn3Kg2IQE

于 2013-03-17T16:37:10.587 回答
2

也许您应该考虑检查您的方法，您需要根据视图执行多次更新并取消先前视图中的所有待处理任务，这给人的印象是您正在为需要创建的每个视图单独执行数据加载.

在带有列表适配器的列表视图中，通常的方法是加载一部分数据（作为 ValueObject 的列表或作为来自多个数据库行的游标）按需要或在一个目标中分页，而不是逐项加载。因此，如果您希望更新下一页，您基本上只执行一个操作，使用 AsyncTask 或 Loaders 将新项目获取到模型，然后使其可供 UI 显示它们。这样，您将应用 MVC，并且您不会有几个待处理的任务需要取消和控制，并且您的结构将更加稳固且更易于管理。

关于替代方案，如果您正在处理数据库，最直接的方法是使用 CursorLoader，即加载程序而不是AsyncTask，但如果您正在处理来自网络或文件系统的数据，您有点自由从各种可用的其他选项中进行选择。AsyncTask使用起来要简单得多，主要推荐用于简单的事情或一次性查询。但是您也可以将 Loaders 用于此类任务，请参阅AsyncTaskLoader。

于 2013-03-17T16:51:57.240 回答
1

AsyncTask 被设计为围绕 Thread 和 Handler 的辅助类，并不构成通用线程框架。AsyncTasks 最好用于短时间的操作（最多几秒钟）。如果您需要保持线程长时间运行，强烈建议您使用 java.util.concurrent 包提供的各种 API，例如Executor、ThreadPoolExecutor 和 FutureTask。有关更多信息，请参阅http://developer.android.com/reference/android/os/AsyncTask.html。

asynctask 的替代方案是 robospice。https://github.com/octo-online/robospice。

您可以在此处开始使用 robopice。https://github.com/octo-online/robospice/wiki/Starter-Guide。

https://play.google.com/store/apps/details?id=com.octo.android.robospice.motivations&feature=search_result上的 robospice 示例。

robospice 的一些特性。

1.executes asynchronously (in a background AndroidService) network requests (ex: REST requests using Spring Android).

2.is strongly typed ! You make your requests using POJOs and you get POJOs as request results.

3.enforce no constraints neither on POJOs used for requests nor on Activity classes you use in your projects.

4.caches results (in Json with both Jackson and Gson, or Xml, or flat text files, or binary files, even using ORM Lite).

5.notifies your activities (or any other context) of the result of the network request if and only if they are still alive

6.no memory leak at all, like Android Loaders, unlike Android AsyncTasks notifies your activities on their UI Thread.

7.uses a simple but robust exception handling model.
于 2013-03-17T16:40:34.503 回答