加载器框架与普通 AsyncTask答案

【问题标题】：Loader framework vs plain AsyncTask加载器框架与普通 AsyncTask
【发布时间】：2012-10-02 00:00:25
【问题描述】：

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

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

资源清理：我使用单个活动，在onCreate() 中创建 SQLiteOpenHelper 并关闭它onDestroy()。由于加载器管理器可能仍在运行，我检查它并在我的回调对象上设置一个pendingClose 标志，因此它会在加载完成时关闭游标和助手。我认为不关闭数据库是无害的，但如果你不这样做，SQLite 会抱怨，而且我不喜欢错误消息 :) 这里的重点是数据无法在配置更改中存活，所以 Loader 的优势就消失了
我应该创建多少个加载器？假设我有心爱的Customer 和Order 表。加载程序由ID 标识，如CUST_L 或ORD_L，但每次用户单击一些摘要时，我都想带入一个带有详细信息的屏幕。我应该 restart 一个具有不同参数的加载程序，还是应该 init 一个具有随机 ID 的新加载程序？这可能会发生数十次。 Loader 框架适用于大量运行中的小型作业，还是仅适用于一些长时间运行的任务？
在LoaderCallbacks接口内部使用ID的目的是什么？为什么不是简单的initLoader(params, callback)？我不认为可以在回调中重用某些逻辑：最终他会分支（在 ID 上使用 if-else 或 switch）所以我不明白为回调对象提供标识符的意义，而是一种天真的方法每个操作一个回调。

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

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

【问题讨论】：

“我问这个是因为整个框架在我看来设计过度，没有真正的实用性。” --我不知道“过度设计”，但就个人而言，我只是使用AsyncTask。我创建了LoaderEx 来演示如何创建替代的Loader 实现，但在发布它后不久，我得出结论Loader 比它的价值更烦人。唯一的例外是如果您完全使用ContentProvider 并且可以使用CursorLoader，在这种情况下，我对使用它而不是AsyncTask 感到矛盾。
所以基本上你同意我的假设？我的推理有什么错误吗？
“所以基本上你同意我的假设？” -- 对于#1，虽然我同意关闭数据库很好，但请记住，如果您在数据库周围使用ContentProvider 外观，则永远不会发生这种情况，因此ContentProvider-centric Loader 框架的事实并不一定让这件事变得容易也就不足为奇了。对于＃2，我既不同意也不反对，因为您提出了问题而不是发表了意见，而我没有答案。对于＃3，我既不同意也不反对，因为我没有过多考虑您的方法，因为我很少使用Loader。

标签： android sqlite commonsware-cwac

【解决方案1】：

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

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

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

【讨论】：