我正在尝试分析对于需要附带相当大量文本（几本书）的应用程序使用 SQLite 与使用资源之间的权衡。我读了这篇关于原始 XML 文件与 SQLite 的文章 https://stackoverflow.com/questions/5213550/raw-resources-versus-sqlite-database and 这是关于 XML 资源与 SQLite 的对比 https://stackoverflow.com/questions/7508859/xml-resources-or-sqlite。然而，这两者似乎都在将 SQLite 与运行时解析 XML 进行比较。我不知道使用 string 和 int 资源数组是否也存在同样的问题。实际上我有很多未知数，我很感激其他人可以提供的任何见解。
资料详情：约40册；每本书三种语言；平均图书长度 25 章；平均章节长度 25 段；总共约 75,000 个段落。文本按段落存储；不需要更细的粒度。对于每种语言，应用程序的文本逻辑视图都是跨越所有书籍的单个段落数组。还有细至段落级别的“目录”(TOC) 数据。所有数据都是严格只读的。我需要支持两种查询类型：1）检索指定语言的段落或段落范围的文本； 2) 给定段落编号，确定书籍、章节以及章节中的段落偏移量。我不需要使用任何 SQLite 的字符串函数。
到目前为止我的分析：
SQLite:离线创建 SQLite 数据库，将其打包为原始资源或资产，并在应用程序首次运行（和/或升级）时将其复制到数据库位置。我为此实现了一个原型数据库，其中有六个表。
- 可以使用SQL查询数据库，因此不需要编写任何搜索算法。
- 我知道它可以处理这么多数据。
- 需要多个 SQL 范围查询来回答类型 2 查询。
- 需要两倍的空间：在 .apk 文件中，以及安装到应用程序的数据库区域时再次需要。
- Android 的 SQLite 实现需要外部存储（SD 卡），因此如果没有外部存储，应用程序将无法运行。亚马逊的Kindle Fire 应用指南 https://developer.amazon.com/help/faq.html#KindleFire声明应用程序不能需要 SD 卡，因此这样做可能会排除 Kindle Fire 兼容性。 （坏的！）
资源：离线创建一个xml数组资源文件集合，并将其复制到项目的res/values文件夹中。文本将被划分为许多字符串数组：每本书每章一个数组。大约有 3,000 个阵列。索引将被实现为 int 数组。对于每本书，索引数据将跨语言共享。我可能还需要生成一些类型化数组资源来提供生成的资源 ID 的索引。我希望索引数组足够小，可以在应用程序启动时完全加载到内存中。
- 类型 1 查询涉及加载正确的字符串数组并访问数组元素。类型 2 查询涉及（已加载的）索引数据的二分搜索。
- 不知道Android中的资源系统是否可以处理那么多的资源数组。
- 不知道与使用 SQLite 相比性能如何。
我认为混合方法也是可能的：以一种方式存储 TOC 数据，以另一种方式存储文本本身。
再次强调，如果您有任何有助于此分析的想法或见解，我将不胜感激。
一个切点...
亚马逊针对 Kindle Fire 应用程序的指南规定，应用程序不能需要 SD 卡，因此这样做可能会排除 Kindle Fire 兼容性。 （坏的！）
从今天开始的版本确实推荐
您部署一个可以快速下载和安装的较小 APK，然后在首次启动时下载其他资源并将其保存在本地文件系统上。
对于较大的应用程序，而不是将其完全打包。此外，他们禁止的似乎是[强调我的]
复制、记录、下载、存储或任何类型的类似行为视频或音频内容到 Amazon Fire TV 或 Fire TV Stick 设备、任何 SD 存储卡或任何连接的外部存储（如果适用）。
所以现在这个限制似乎已经过时了。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
