Android 使用可读SQLite数据库的原因

Android类SQLiteOpenHelper有一个返回可读数据库以及可读写数据库的方法。目前我只使用可写数据库，没有任何问题，但我想知道，如果我只在异步任务（或活动）中读取数据，那么改为仅使用可读数据库会有什么好处

可能有性能优势，但我没有看到任何实际数字的参考。此外，如果我一直在可读和可写之间切换，那么更改会带来开销，可能会带走所有性能优势

---

有没有人有这方面的真实数字或经验？是否值得实施单独访问？

好问题。我没有电话号码。最近的解释（来自SQLLiteOpenHandler javadoc）

“此（getReadableDatabase）将是getWritableDatabase（）返回的同一对象，除非某个问题（如磁盘已满）要求以只读方式打开数据库。在这种情况下，将返回只读数据库对象。如果问题已解决，则以后将调用getWritableDatabase（）”可能会成功，在这种情况下，只读数据库对象将关闭，并且读/写对象将在将来返回。“

---

我不能对性能优势发表评论，但对于任何“数据”源（文本文件、DBs或其他）的访问，我总是努力遵循“良好实践”（甚至是“最佳实践”）的原则

从总体上看（不是特定于Android），在决定访问级别时要做出的决定，可以归结为要执行的操作以及任何外部影响

我能想到的两个例子

如果外部过程可能具有 维护数据的责任- 在这种情况下，它可能已“打开” 以这样的方式创建数据源： 它通过以下方式阻止除“读取”访问之外的所有访问： 维护阶段的任何其他过程。在这种情况下,， 如果出现以下情况，您的代码将被拒绝访问： 您在以下情况下请求读/写访问权限： 没有必要

危害数据完整性的风险——从外部世界入侵系统的风险可以通过使用内部代码的安全漏洞实现，该代码可以读取/写入数据，而实际上只需要“读取”访问

---

好的，这些观点可能与Android相关，也可能与Android无关（特别是如果你的数据源特定于你的应用程序），但正如我所说的，我试着从总体上看问题，并使用“最佳实践”方法。如果我不需要“写”访问权限，我就不会请求它。

很好的发现，并且会在我回答中提到的第一点上采取某种方式来防止失败。@Manfred Moser在我的回答中说。。。。不确定我们是否能以这种或那种方式证明这一点（即，有/没有性能优势）。以下是一个（未经证实的）原因，我认为这可能会对性能产生影响。如果使用getWritableDatabase（），则需要调用close（）方法，否则会在LogCat中显示大量红色。其中（此部分未验证）getReadableDatabase（）不强制调用方法close（）。如果您的应用程序经常关闭数据库，这可能会（！）影响性能。我通常将其解释为一种保护措施，而不是性能。可以将所有Java类/方法/数据成员声明为公共的，但我们使用

受保护的

，

私有的

，以及包-

受保护的

，以防止自己搞砸。类似地，可读数据库可能有助于捕获编码错误。也就是说，由于

SQLiteOpenHelper

在将来的

getwriteabledatabase（）

调用中透明地将数据库“升级”为可写，因此该值可能有点有限。感谢您的提示。我想我不会像下面提到的那样在这个阶段打扰你。虽然我同意你的观点，但在这个例子中，它们不适用于Android。没有这样的db服务器，而是一个唯一的db文件和访问代码（naitve和via dalvik vm），这是该应用程序独有的。在每个应用程序中，db访问是独占（强制）和顺序的。如果另一个应用程序有一个db，那么它是一个单独的db文件，执行access和all（每个应用程序都有自己的vm）。正如您在上面的另一条评论中所看到的，javadoc甚至说返回了相同的对象，所以这一切就变得更加没有意义了。@Manfred Moser：是的，我知道应用程序存在于他们自己的虚拟机中，我非常熟悉没有服务器的SQLite（我在各种平台上使用SQLite已经有一段时间了）。但是，是否所有SQLite数据库都存在“进程中”？例如，那些可以在SD卡上创建的呢？另外，从同一应用程序中的其他线程访问如何？Commonware关于我们不能将所有东西都创建为“公共”的评论基本上就是我的意思——“最佳实践”等等。永远不要认为你的“舞台”永远不会改变。在这个阶段我会接受你的答案。在这个阶段，我怀疑我是否会努力重构它，因为在我的例子中，我认为不断的关闭和打开会降低性能。在保护方面，我看不到任何价值，因为数据是非关键的。