android - 在 Android 上同时将数据保存在内存和数据库中的最佳实践

Question

我们正在设计一个包含大量数据(“客户”、“产品”、“订单”...)的 Android 应用，我们不希望每次需要一些记录时都查询 SQLite。我们希望尽可能避免查询数据库，因此我们决定将某些数据始终保存在内存中。

我们最初的想法是创建两个简单的类:

1. “MemoryRecord”:一个基本上包含对象数组(字符串、整数、 double 、日期时间等)的类，这些对象是表记录中的数据，以及获取这些对象的所有方法从这个数组输入/输出数据。

2. “MemoryTable”:一个基本上包含 [Key,MemoryRecord] 的 Map 以及操作此 Map 以及在数据库中插入/更新/删除记录的所有方法的类。

这些类将派生到我们在数据库中拥有的每一种表。当然还有其他有用的方法没有在上面列出，但在这一点上它们并不重要。

因此，在启动应用程序时，我们将使用这些类将这些表从 SQLite 数据库加载到内存中，并且每次我们需要更改一些数据时，我们都会在内存中进行更改并立即将其发布到数据库中。

但是，我们需要您提供一些帮助/建议。你能建议一些更简单或更有效的方法来实现这样的事情吗？或者也许一些现有的类(class)已经为我们做了？

我理解你们想要向我展示的内容，对此我表示感谢。

但是，假设我们有一个包含 2000 条记录的表，我需要列出这些记录。对于每一个，我必须查询其他 30 个表(其中一些有 1000 条记录，另一些有 10 条记录)以在列表中添加其他信息，而这正在“飞行”(如您所知，我们必须非常快此刻)。

现在你会说:“只需使用所有这些‘连接’构建你的主查询，然后一步完成你需要的一切。如果你的数据库设计得很好，SQLite 可以非常快，等等。 。”。

好的，但是这个查询会变得非常复杂并且可以肯定，即使 SQLite 非常快，它也会“太”慢(2 到 4 秒，正如我所确认的，这不是我们可以接受的时间) .

另一个复杂点是，根据用户交互，我们需要“重新查询”所有记录，因为涉及的表并不相同，我们必须与另一组表“重新连接”。

因此，另一种方法是只带主要记录(这永远不会改变，无论用户做什么或想要什么)而不连接(这非常快!)，并且每次我们想要一些数据时查询其他表。请注意，在只有 10 条记录的表上，我们将多次获取相同的记录。在这种情况下，这是浪费时间，因为无论 SQLite 速度如何，查询、游标、获取等总是比仅仅从一种“内存缓存”中获取记录更昂贵。我想明确一点，我们不打算将所有数据都保存在内存中，只是我们经常查询的一些表。

我们来到了最初的问题:“缓存”这些记录的最佳方式是什么？我真的很喜欢把讨论的重点放在这个问题上，而不是“为什么需要缓存数据？”

Answer 1

平台上的绝大多数应用程序(联系人、电子邮件、Gmail、日历等)都不这样做。其中一些具有极其复杂的数据库模式，可能包含大量数据，因此不需要这样做。你打算做的事情会给你带来巨大的痛苦，没有明显的收获。

您应该首先专注于设计您的数据库和架构，以便能够进行高效的查询。我认为数据库访问速度慢的主要原因有两个:

• 您的数据架构非常复杂。
• 您拥有大量数据。

如果您要拥有大量数据，无论如何您都无法将其全部保存在内存中，因此这是一条死胡同。如果您有复杂的结构，无论哪种情况，您都可以通过优化它们来提高性能。在这两种情况下，您的数据库架构都是获得良好性能的关键。

实际上，优化架构可能有点像一门黑魔法(我不是这方面的专家)，但需要注意的是在您要查询的行上正确创建索引、设计连接以提高效率路径等。我相信有很多人可以在这方面为您提供帮助。

您还可以尝试查看一些平台数据库的来源，以了解如何设计以获得良好性能。例如，Contacts 数据库(特别是从 2.0 开始)非常复杂，并且进行了很多优化，以便在具有大量不同类型查询的相对较大的数据和可扩展数据集上提供良好的性能。

更新:

这里很好地说明了数据库优化的重要性。在 Android 的媒体提供商数据库中，新版本的平台显着更改了架构以添加一些新功能。将现有媒体数据库修改为新架构的升级代码可能需要 8 分钟或更长时间才能执行。

一位工程师做了一项优化，将真实测试数据库的升级时间从 8 分钟缩短到 8 秒。性能提升 60 倍。

这个优化是什么？

这是在升级时在升级操作中使用的重要列上创建一个临时索引。 (然后在完成后将其删除。)因此，即使它还包括在升级期间使用的列之一上构建索引所需的时间，这 60 倍的性能改进也会到来。

SQLite 是其中之一，如果您知道自己在做什么，它会非常高效。如果你不注意如何使用它，你可能会以糟糕的表现告终。但是，如果您遇到性能问题，可以通过改进 SQLite 的使用方式来解决这些问题。