Android 通过C+创建SQLite数据库+；。通过Java SDK访问它？

我们的情况如下：

我们有一些本机代码，可以在特定时间扫描用户定义的目录。目标是收集关于特定类型文件的数据，并从中构建SQLite数据库。可能有成千上万的文件需要查询

问题是，每次找到文件时，必须将收集到的关于该文件的数据穿过JNI边界引入Java land，然后才能通过Android SDK提供的SQLite类提交到数据库。这需要的时间太长

建议的解决方案是下载SQLite源代码，将其链接到我们的项目中，并按如下所述本地构建数据库：。这将消除将数据从C++层完全传递到java层所花费的时间。

问题是：如果这样做了，Android SDK（Java层）是否仍能正常用于打开数据库、获取光标对象等？我们可以保持数据库非常简单；没有外键、触发器、约束等，尽管索引非常理想

我们已经考虑使用管道和套接字跨JNI边界移动数据。但是，Fat32文件系统不支持命名管道（因此，如果用户将应用程序移动到Fat32格式的SD卡，则无法使用命名管道）。套接字也不可用，因为我们必须在清单中包含我们认为可疑的internet权限

如果有人有这方面的消息，我们很乐意听到你的消息

非常感谢,，

---

P.

为了跟进，我们冒险编写了一个测试应用程序，该应用程序编译了最新的SQLite合并（3.7.13）源代码。我们发现，我们确实能够通过Android Java SDK与本机创建的数据库进行交互

就性能而言，这是一个巨大的飞跃！通过在本机层插入记录，我们发现性能大大提高。以前，将20000条记录插入一个不复杂的数据库大约需要4分钟。一些简单的分析表明，几乎整个4分钟都花在了将数据从本机层传递到Java层上

现在，插入需要4到6秒。我们还可以按照常规使用Java API打开、查询数据库等

要注意的性能调整包括事务和使用以下方法将日志移动到内存：

pragma journal_mode=memory;

出于稳定性原因，我们决定不关闭同步，而且我们对已经取得的性能非常满意

希望其他人会发现这个建议很有用

---

p

为了跟进，我们冒险编写了一个测试应用程序，该应用程序编译了最新的SQLite合并（3.7.13）源代码。我们发现，我们确实能够通过Android Java SDK与本机创建的数据库进行交互

就性能而言，这是一个巨大的飞跃！通过在本机层插入记录，我们发现性能大大提高。以前，将20000条记录插入一个不复杂的数据库大约需要4分钟。一些简单的分析表明，几乎整个4分钟都花在了将数据从本机层传递到Java层上

现在，插入需要4到6秒。我们还可以按照常规使用Java API打开、查询数据库等

要注意的性能调整包括事务和使用以下方法将日志移动到内存：

pragma journal_mode=memory;

出于稳定性原因，我们决定不关闭同步，而且我们对已经取得的性能非常满意

希望其他人会发现这个建议很有用

---

p

您是如何处理数据库锁的？如果我在Android和本机中从几个线程访问DB，是否会有DB损坏的可能？你有没有遇到过这样的问题？我知道SQL是线程安全的，但是我不确定java和C++之间是否真的是线程安全的。我知道这是一篇非常古老的文章，但如果您能在这里提供一些想法，我将非常感激。很抱歉，线程不是我们的问题，因为我们在应用程序的任何其他部分（Java层）之前在本机层插入所有记录已开始读取/写入/删除/修改这些记录。@protectedmember您是如何分析这些记录的？-一些简单的分析表明，几乎整个4分钟都花在了将数据从本机层传递到Java层上。@b-boysh1ftI@m对不起，这是很多年前的事了I@m不再为同一家公司工作。我不记得我们是如何分析的，我没有权限查看任何代码来检查你。你是如何处理DB锁的？如果我在Android和本机中从几个线程访问DB，是否会有DB损坏的可能？你有没有遇到过这样的问题？我知道SQL是线程安全的，但是我不确定java和C++之间是否真的是线程安全的。我知道这是一篇非常古老的文章，但如果您能在这里提供一些想法，我将非常感激。很抱歉，线程不是我们的问题，因为我们在应用程序的任何其他部分（Java层）之前在本机层插入所有记录已开始读取/写入/删除/修改这些记录。@protectedmember您是如何分析这些记录的？-一些简单的分析表明，几乎整个4分钟都花在了将数据从本机层传递到Java层上。@b-boysh1ftI@m对不起，这是很多年前的事了I@m不再为同一家公司工作。我不记得我们是怎么分析的了，我没有权限查看任何代码。