我什么时候应该在另一个线程（不是主线程）上执行某些 SQLite 操作？答案

【问题标题】：When should I do certain SQLite operations on another thread(not the main thread)?我什么时候应该在另一个线程（不是主线程）上执行某些 SQLite 操作？
【发布时间】：2011-02-18 22:47:31
【问题描述】：

我的 Android 应用程序包含一个带有 SQLiteOpenHelper 类的 SQLite 数据库来帮助管理它。在应用程序使用过程中，用户可能会对数据库进行一些操作，例如添加/删除/更新等。

有时会知道操作的大小，如下所示：

用户点击按钮保存项目
SQLiteDatabase 执行单个 insert 查询
用户继续使用应用程序

在应用程序的其他区域，操作可能很大，例如一次将 10 多个项目全部插入数据库。

问题：

我应该线程简单的操作，如插入/更新/删除/查看 1 项？
将 1 个项目插入包含许多项目（如 30 多个项目）的表中是否会比插入没有项目的表中花费更长的时间？
如果我不需要线程化这些简单的操作，您建议我在什么时候开始线程化它们？

当我说线程时，我的意思是使用不是主 UI 线程的线程。

edit：我意识到小操作不需要太多时间，我可以很好地在主线程上执行它们。我只是担心在主线程上执行它们是不好的做法，并希望得到澄清！

【问题讨论】：

标签： android sqlite

【解决方案1】：

所有事情的一般规则：如果速度足够快，请在主线程上执行。如果没有，请使用工作线程。

除非你有一个大得离谱的数据库，否则单个操作几乎不需要单独的线程。一般来说，数据库设计得很好，但是当然一个非常大的数据库（超过 10,000 行？）会比一个小的数据库慢一些。然而，30 行不算什么。

如果您有很多操作正在进行，例如一堆查询或跨越多个表的复杂查询，我会开始线程处理。

与所有内容一样 - 分析您的应用，如果速度太慢，请进行优化。如果您的查询时间都不超过 2 毫秒，请不要编写出色的同步超级重复多核就绪数据库处理程序。

【讨论】：

google IO 上关于 Android REST 客户端应用程序的讨论怎么样。他说“永远不要在主线程的上下文中执行数据库操作”。我希望我不会断章取意，但这可能是一个好习惯。
我还是坚持最后一句话——不优化不慢的。如果您的数据库非常小，则不需要对其进行优化。添加多线程将大大增加应用程序的复杂性，并为难以发现和调试的同步错误引入迷人的温床。
使用加载器，它们现在作为兼容性库的一部分提供。
根据您使用的 SQLite 库，将内容移至后台线程可能不是什么大问题。我目前正在使用 anko，它并不关心在什么线程数据库操作上运行。它为您处理并发问题。我在主线程上有几个数据库操作和一个前台服务，它使用 IO 线程通过 kotlin 协程访问数据库。对此没有任何问题，也不必自己实现任何线程安全。因此，如果不需要，您不必进行优化。但是如果你需要使用像 anko 这样的库，这样做是任意的。

【解决方案2】：

在优化之前始终进行测量！

确保您所做的数据库操作会影响用户体验，然后开始寻找解决方案。

如果数据库内容变慢，请使用AsyncTask，它旨在在后台执行任务，然后在 EDT 上更新 GUI。

【讨论】：

甚至可以使用 Loader 代替 AsyncTask。解决从 UI 线程加载数据的问题有很多优点。 link
EDT 代表什么？

【解决方案3】：

绝对没有理由在这里使用线程。只需返回游标，从游标中提取信息并将其返回给主活动即可。

具体来说，线程是理想情况下会重复的东西，直到某事发生或超时。由于我假设您正在使用的数据库在手机上，因此访问它几乎需要零时间。

您还可以做的另一件事是创建一个实用程序类来帮助您的活动与数据库交互。这将是您的活动调用与数据库交互的方式。具体来说，控制流程是这样的：

活动 -> 实用程序 -> 数据库

它位于活动和数据库之间，以使它们彼此隔离并使其更容易访问所需的任何内容，因为它不必直接进入数据库本身。

【讨论】：

线程对于与另一个线程并行执行某些操作很有用。当您不能保证它会很快恢复时，最好使用单独的线程，因为另一个线程/进程/应用程序可能会导致磁盘争用，因此访问磁盘的任何东西都是这种情况。 SQLite 访问磁盘很重。