android - 加载器框架与普通 AsyncTask

Question

在我的应用程序中，我需要大量的 CRUD 内容:从本地 SQLite 数据库读取记录、插入对象和更新内容。大多数查询都非常简单，即使在 UI 线程上运行也不会阻塞，但是在这个应用程序中我想采用 Windows Phone 模式:out 动画立即开始，在动画中在结果交付时开始。

我计划使用 AsyncTask 来完成这项工作，但我注意到 Honeycomb(和兼容包)引入了这个新的 Loader 框架。主要优点似乎是 Loader 加载的数据在配置更改后仍然存在。 LoaderEx Commonsware 项目在 SQLite 和框架之间架起了桥梁，但出现了一些问题。

1. 资源清理:我使用单个 Activity ，在 onCreate() 中创建 SQLiteOpenHelper 并在 onDestroy() 中关闭它。由于加载程序管理器可能仍在运行，我检查它并在我的回调对象上设置一个 pendingClose 标志，因此它会在加载完成时关闭游标和助手。我认为不关闭数据库没有害处，但如果你不这样做，SQLite 会提示，而且我不喜欢错误消息:) 这里的重点是数据不会在配置更改后继续存在，所以 Loader 的优势消失了

2. 我应该创建多少加载器？假设我有心爱的 Customer 和 Order 表。加载程序由 ID 标识，例如 CUST_L 或 ORD_L，但每次用户点击一些摘要时，我都想在屏幕上显示细节。我应该restart具有不同参数的装载机，或者我应该 init一个带有随机 ID 的新的？这可能会发生几十次。 Loader 框架是为大量运行的小作业设计的，还是只为一些长时间运行的任务设计的？

3. 在LoaderCallbacks 接口(interface)中使用ID 的目的是什么？为什么不是简单的 initLoader(params, callback)？我认为不能在回调中重用某些逻辑:最终他会分支(使用 ID 上的 if-else 或 switch)所以我不明白为回调对象提供标识符的关键点，而不是一种天真的方法 one-callbacks-per-operation。

我问这个是因为整个框架对我来说似乎设计过度并且没有真正的实用性。我不明白使用 LoaderManager 集中代码的意义，而且我看不到 AsyncTask 没有提供的任何新机会。

唯一的胜利点是配置更改生存，但由于资源清理我无法利用它，而且我无法找到关闭 SQLiteOpenHelper 的替代方法，因为(很明显) SQLiteCursorLoader需要它，但清理它取决于用户。所以 AsyncTask 似乎是这里的赢家选择，但也许我遗漏了一些东西。

Answer 1

1. 内容提供商比“原始数据库”方法更强大。 stackoverflow 上的许多链接都引发了对此的讨论。
2. LoaderManager 尝试通过 ID 区分加载程序(这就是 initLoader 的签名指定此参数的原因)。如果具有特定 ID 的加载程序的数据已经存在，则需要加载程序的 ID 来重新传送缓存的结果(因此无需再次异步重新加载)。
3. restartLoader 调用强制 LoaderManager 启动由先前创建的加载器指定的异步操作。 initLoader 在创建新加载器之前尝试重用现有加载器。
4. Fragments 和 Activity 有自己的不重叠的 LoaderManagers。

我的经验表明，即使使用 Content Provider 实现起来听起来有些矫枉过正，但它实际上在未来会带来不错的返回。性能影响微不足道(尝试测量它)，UI-Data 绑定(bind)是开箱即用的(因为内容观察器和 CursorLoaders 能够订阅 Uri 通知)，框架通过加载器实现同步性。恕我直言，无论何时需要数据库，大多数时候使用内容提供程序和加载程序是您能想到的最佳解决方案。

其他涉及直接使用数据库的场景，将迫使您手动实现一切。