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

Posted 2023-03-08

【中文标题】在 Android 上同时将数据保存在内存和数据库中的最佳实践

【英文标题】：Best practice for keeping data in memory and database at same time on Android

【发布时间】：2011-04-10 10:18:14

【问题描述】：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【问题讨论】：

"我们希望尽可能避免查询数据库，因此我们决定将某些数据始终保存在内存中。" -- 您是否使用 Traceview 确认这是您的应用程序的问题？ “我们需要您的帮助/建议”——我的建议是：首先证明存在问题。您可以使用的 RAM 非常少。建立一些大框架来处理一个不存在的问题将是浪费精力。如果您已经证明这是一个问题，我希望您能将其指向您撰写它的博客文章，因为我一直对性能测试结果感兴趣。

@CommonsWare：我理解你的观点并且完全同意你的看法。但是，作为 PalmOS 和 .NetCF 的开发人员，我们之前已经面临过这个问题。在 PalmOS 中，所有数据都按设计 (.pdb) 存储在内存中，并且在获取数据时没有性能问题。另一方面，在 WM 中我们面临“问题”，然后我们创建了上面列出的这个“解决方案”。但是现在，在 Android 中，我们希望以“正确的方式”来做。我们想知道在“每次”查询数据库时是否会遇到性能问题。所以我们决定在这里征求意见。无论如何，谢谢。

"我们想知道“每次”查询数据库时是否会遇到性能问题。所以我们决定在这里征求建议。" - 不，你没有。我希望你有。相反，您声明存在问题（“我们不想在每次需要记录时都查询 sqlite”）并且您需要有关解决方案的帮助。与大多数平台一样，如果您“在查询数据库时将面临性能问题”，答案是“取决于查询”。相信我，仅仅因为 WM 上存在问题并不意味着其他地方也存在同样的问题。使用 Traceview。

你不需要查询数据库为什么滚动。您可以在活动开始时查询所需的所有数据。

根据您的编辑，听起来您“需要”具有缓存和/或内存数据库的复杂设计，因为您个人认为连接过于复杂。在这两个弊端中，我会坚持使用（性能更高的）最佳实践，并使用联接正确编写查询。我做过类似的事情，一旦我重构了代码并编写了方法来帮助生成查询和从游标膨胀对象，它并没有变得太不守规矩。虽然，如果有人设置使用内存数据库，SQLiteOpenHelper 通过提供 null 作为数据库文件名来允许这样做。

【参考方案1】：

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

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

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

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

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

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

更新：

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

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

这个优化是什么？

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

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

【参考方案2】：

内存缓存的问题当然是您需要使其与数据库保持同步。我发现查询数据库实际上是相当快的，你可能在这里进行了预优化。我对具有不同数据集的查询进行了很多测试，它们从不超过 10-20 毫秒。

当然，这完全取决于您使用数据的方式。 ListViews 已经很好地优化了处理大量行（我已经测试到 5000 范围，没有真正的问题）。

如果您要保留内存缓存，您可能希望数据库在其内容更改时通知缓存，然后您可以更新缓存。这样任何人都可以在不知道缓存的情况下更新数据库。此外，如果您在数据库上构建 ContentProvider，如果您使用 registerContentObserver 注册，则可以使用 ContentResolver 通知您更改。

【讨论】：

很高兴知道你所说的这些统计数据。我很确定我们正在预先优化，但这是因为我们过去在 SQLite e 移动设备 (WM) 方面的经验。内存和数据库之间的同步不是我们担心的，因为在同一“时间”我们改变了一些东西，我们会将它发布到数据库中。缓存将是全局的，因此所有应用程序都会看到相同的内容。所有更改都将首先在内存中进行，然后在数据库中进行（在“原子”操作中，在这些类中实现）。