2

这是我们的情况：

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

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

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

问题是：如果这样做了，Android SDK（Java层）是否仍然可以正常打开数据库，获取Cursor对象等？我们可以保持数据库极其简单；没有外键、触发器、约束等。虽然索引是非常可取的。

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

如果有人对此有任何信息，我们很乐意听取您的意见。

非常感谢，P。

4

1 回答 1

4

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

性能方面，这是一个巨大的飞跃！通过在本机层插入我们的记录，我们发现性能大幅提升。以前，将 20,000 条记录插入非复杂数据库大约需要 4 分钟。一些简单的分析表明，几乎整个 4 分钟都用于将数据从本机层传递到 Java 层。

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

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

pragma journal_mode=memory;

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

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

磷

于 2012-08-05T01:21:56.650 回答