Loader框架与普通的AsyncTask

Question

在我的应用程序中，我需要很多CRUD东西：从本地SQLite数据库读取记录，插入对象和更新东西。大多数查询都非常简单，即使在UI线程上运行也不会阻塞，但是在这个应用程序中我想采用Windows Phone模式： out动画立即启动并且在动画中在结果传递时启动。

我计划使用AsyncTask来完成这项工作，但我注意到Honeycomb（以及compat包）引入了这个新的 Loader框架。主要优势似乎是Loader加载的数据存活配置发生了变化。 Commonsware的LoaderEx项目在SQLite和框架之间架起了桥梁，但是出现了一些问题。

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

2. 我应该创建多少个装载机？假设我有心爱的Customer和Order表。加载程序由ID标识为CUST_L或ORD_L，但每次用户点击某些摘要时，我都会在屏幕上显示详细信息。我应该restart使用不同参数的加载器，还是应该init使用随机ID的新加载器？这可能会发生几十次。 Loader框架是针对许多小型正在运行的作业，还是仅针对一些长期运行的任务？

3. 在ID界面中使用LoaderCallbacks的目的是什么？为什么不简单initLoader(params, callback)？我不认为可以在回调中重用一些逻辑：最终他将分支（在ID上使用if-else或switch）所以我不明白给出一个标识符的重点回调对象，而不是简单的方法每次操作一次回调。

我问这个是因为整个框架似乎对我来说过于工程化而没有实际效用。我不明白使用LoaderManager集中代码的重点，我看不到任何新的机会AsyncTask没有提供。

唯一的胜利点是配置改变生存，但由于资源清理我无法利用它，我无法找到另一种方法来关闭SQLiteOpenHelper因为（很明显）AsyncTask 3}}需要它，但清理它取决于用户。所以{{1}}似乎是赢家的选择，但也许我错过了一些东西。

Answer 1

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

我的经验表明，尽管使用内容提供商听起来有点矫枉过正，但实际上它在未来的表现相当不错。性能损失是微不足道的（尝试测量它），UI-Data绑定是开箱即用的（因为内容观察者和CursorLoaders能够订阅Uri通知），框架通过加载器实现同步。恕我直言，每当需要数据库时，大多数时候使用带有加载器的内容提供商是您可以提出的最佳解决方案。

涉及直接使用数据库的其他方案将迫使您手动实现所有内容。