Android上的SQLite的最佳做法是什么？ [英] What are the best practices for SQLite on Android?
问题描述
在Android应用程式中对SQLite资料库执行查询时，最佳做法会是什么？
是否可以安全地执行插入，删除和AsyncTask的doInBackground？还是应该使用UI线程？我想数据库查询可以是沉重的，不应该使用UI线程，因为它可以锁定应用程序 - 导致应用程序无响应（ANR）。
如果我有几个AsyncTasks，
$ b
插入，更新，删除和读取通常可以从多个主题确定，但Brad的回答不是正确。您必须小心创建连接并使用它们。在某些情况下，即使您的数据库没有损坏，您的更新调用也会失败。
基本答案
SqliteOpenHelper对象持有一个数据库连接。它似乎为您提供读写连接，但它真的不是。调用只读，你将得到写数据库连接。
所以，一个帮助实例，一个db连接。即使你从多个线程使用它，一次一个连接。 SqliteDatabase对象使用java锁来保持访问序列化。因此，如果100个线程有一个数据库实例，则对实际磁盘数据库的调用将被序列化。
所以，一个帮助器，一个db连接，码。一个线程，1000个线程，如果你使用一个在他们之间共享的助手实例，你的所有db访问代码是串行的。和生活是好的（ish）。
如果你尝试从实际不同的连接写入数据库，同时，一个将失败。它不会等到第一个完成然后写。它不会写你的更改。更糟糕的是，如果你不调用SQLiteDatabase上插入/更新的正确版本，你不会得到一个异常。你只会在你的LogCat中收到一条消息，就是这样。
那么，多线程？使用一个帮助器。期。如果你知道只有一个线程将写入，你可以使用多个连接，你的读取速度会更快，但买家要小心。
- 这是一个更详细的博客文章和一个示例应用程序。
- Android Sqlite锁定（更新链接6 / 18/2012）
- Android-Database -Locking-Collisions - 例子by touchlab on GitHub
- Android Sqlite Locking (Updated link 6/18/2012)
- Android-Database-Locking-Collisions-Example by touchlab on GitHub
- >
Gray和我实际上包装了一个ORM工具他的Ormlite，本机与Android数据库实现，并遵循安全创建/调用结构我在博客文章中描述。这应该很快就会发生。请查看。
同时，还有一个后续博文：
还可以通过前面提到的锁定示例的 2point0 检查分支：
What would be considered the best practices when executing queries on an SQLite database within an Android app?
Is it safe to run inserts, deletes and select queries from an AsyncTask's doInBackground? Or should I use the UI Thread? I suppose that database queries can be "heavy" and should not use the UI thread as it can lock up the app - resulting in an Application Not Responding (ANR).
If I have several AsyncTasks, should they share a connection or should they open a connection each?
Are there any best practices for these scenarios?
Inserts, updates, deletes and reads are generally OK from multiple threads, but Brad's answer is not correct. You have to be careful with how you create your connections and use them. There are situations where your update calls will fail, even if your database doesn't get corrupted.
The basic answer.
The SqliteOpenHelper object holds on to one database connection. It appears to offer you a read and write connection, but it really doesn't. Call the read-only, and you'll get the write database connection regardless.
So, one helper instance, one db connection. Even if you use it from multiple threads, one connection at a time. The SqliteDatabase object uses java locks to keep access serialized. So, if 100 threads have one db instance, calls to the actual on-disk database are serialized.
So, one helper, one db connection, which is serialized in java code. One thread, 1000 threads, if you use one helper instance shared between them, all of your db access code is serial. And life is good (ish).
If you try to write to the database from actual distinct connections at the same time, one will fail. It will not wait till the first is done and then write. It will simply not write your change. Worse, if you don’t call the right version of insert/update on the SQLiteDatabase, you won’t get an exception. You’ll just get a message in your LogCat, and that will be it.
So, multiple threads? Use one helper. Period. If you KNOW only one thread will be writing, you MAY be able to use multiple connections, and your reads will be faster, but buyer beware. I haven't tested that much.
Here's a blog post with far more detail and an example app.
Gray and I are actually wrapping up an ORM tool, based off of his Ormlite, that works natively with Android database implementations, and follows the safe creation/calling structure I describe in the blog post. That should be out very soon. Take a look.
In the meantime, there is a follow up blog post:
Also checkout the fork by 2point0 of the previously mentioned locking example:
这篇关于Android上的SQLite的最佳做法是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
