何时关闭android上的db连接？每次操作完成后或退出应用程序后

我有一个android应用程序，经常访问本地SQLITE3DB，出于性能考虑，所以我总是保持连接打开。但是我的一个朋友建议我每次操作都打开/关闭连接

1） 你们对这两种方法有什么看法？利弊。

---

2） 我做了一些测试，发现DB连接没有太多的性能开销。数据库连接的性能开销是否因数据库的大小而不同？

我不知道频繁关闭/打开数据库（无论其大小）会带来任何性能损失。我认为这个问题的答案还取决于访问数据库的应用程序类型

您经常“重新查询”数据库吗？
然后，它似乎纠正保持开放

每次提取数据时是否提取不同的数据？
同样，让它保持打开状态似乎是合理的（因为您不会从缓存数据中获益）

是否有其他应用程序访问同一数据库？
如果存在并发或阻塞问题的风险，那么在完成对数据库的读/写之后关闭数据库可能是明智的

---

通常我会说，在优化性能时，缓存数据可能比保持数据库打开（与关闭数据库相反）获得更多收益。

如果使用内存中的数据库，则在关闭连接时，数据将被丢弃

---

可能有点边缘问题，但我刚刚发现了这一点。

另外，如果您从多个线程访问数据库，那么频繁地打开和关闭连接可能会导致您遇到臭名昭著的SQLite异常

---

请参阅，如果您甚至通过一个连接从多个线程访问数据库，并且由于这些操作不是原子操作，那么您可以尝试更新刚刚被另一个线程关闭的数据库。

文档中说，只要您需要，连接就可以打开。并且可以在onDestroy（）方法中关闭。

持久化数据库连接：

因为getWritableDatabase（）和getReadableDatabase（）对于 当数据库关闭时调用，您应该离开数据库 只要您可能需要访问它，连接就会一直打开。 通常，最好在的onDestroy（）中关闭数据库 呼叫活动

---

我想说的是，每次使用DB操作的活动（而不是应用程序本身）死亡时，都会有一种妥协？！也许有一个更好的答案：除非迫不得已，否则不要关闭它。谢谢dbm。我的应用程序是唯一一个访问数据库的应用程序，它进行了大量的重新查询。似乎对我来说，始终保持数据库开放是更好的选择。但是，如果您能更具体地说明“缓存数据”带来的性能提升，我不太确定sqlite数据库到底做了什么。我假设（可能是错误的）您查询数据库，从返回的游标对象读取所需的值，然后将其丢弃。下次需要数据时，请再次执行相同的过程。现在，假设检索到的数据的性质不需要在连续的数据库查询之间刷新它。然后，也可以从数据库中读取一次并将值存储在本地HashMap或其他东西中。访问“内存中”数据结构（“缓存”数据）通常比重新查询数据库快得多。现在确实存在需要重新查询数据的情况（因此，缓存不一定是一个选项）。然后，看看“索引”可能会很有趣，即使是“准备好的语句”在数据库引擎支持的地方也会很有趣。这个链接可能也很有趣：这实际上是一个非常好的答案。最近，我成功地将内存中的数据库用作缓存基础结构（我明确希望在退出时丢弃缓存）…一旦打开db/连接，它就已经被缓存了。

    @Override
    protected void onDestroy() {
        mDbHelper.close();
        super.onDestroy();
    }