Android – SQLite ContentResolver在UI线程上插入/删除/更新?

我查看了许多在Android中使用SQLite的示例/教程。 假设您有一个使用SQLite, ContentProviderCursorLoader ,自定义CursorAdapter的应用程序。 现在我发现的所有主要示例都依赖于CursorLoader来获取CursorAdapter数据, CursorLoader的性质以Async-UI线程安全的方式发生。 但是,这些相同的示例都通过主线程上的ContentResolver进行插入/删除/更新调用(例如,来自onClickonResumeonPause )。 ( 示例 )它们不会将这些调用包装在AsyncTask也不会启动单独的线程或使用AsyncQueryHandler 。 为什么这样,这么多写得好的博客/例子怎么会犯这样一个明显的错误呢? 或者是简单的单行插入/删除/更新调用如此之快,以至于它们足以安全地从Main / UI线程启动? 这些快速通话的正确方法是什么?

我也对在主线程上调用的样本感到困惑。 我猜这些示例只是简化了演示,避免了额外的线程和回调,因为单个插入/更新/删除调用可能会很快返回。

除了用于查询的Loader模式之外,android确实提供了一个辅助类AsyncQueryHandler,因为API级别1,用于支持完整CRUD回调的异步CRUD操作。 AsyncQueryHandler在内部使用HandlerThread进行异步操作,并将结果传递回主线程。

所以我相信ContentProvider查询应该在除UI之外的工作线程中运行,根据官方设计,这些样本可能不是最佳实践。

===编辑

从官方框架文档中find注释,请参阅第255行:

 In practice, this should be done in an asynchronous thread instead of on the main thread. For more discussion, see Loaders. If you are not just reading data but modifying it, see {@link android.content.AsyncQueryHandler}. 

=== edit 2 链接到包含上述引用的实际android开发指南

很长一段时间以来,这个问题一直在我的脑海里。 我想,这取决于我们尝试插入,更新或删除的文件的复杂性。 如果我们的应用程序要插入或更新大文件,那么异步执行它总是正确的,如果文件不会那么大,可以在UI线程上运行它。

但是,始终建议在单独的线程上继续执行数据库操作。

我想你已经回答了自己的问题。 我相信CursorLoader扩展了AsyncTaskLoader。 从UI线程进行的调用仅处理对CusorLoader(使用AsyncTask)的调用。在UI线程上,调用仍然没有发生。 调用一个方法/函数然后在一个单独的线程上运行东西仍然在远离UI线程。

你认为在UI线程上发生了什么工作?

如果可能,请显示调试日志或您认为在UI上完成工作的示例。 它不应该。

不试图争辩只是想知道你是如何得出UI工作的结论?