java - Android关于数据持久化的战略决策

Question

我不知道在哪里询问这个问题，我找不到战略信息，关于 Android 应用程序架构的“全貌”信息，所以请耐心等待我。我尝试了programmers.stackexchange，但那里几乎没有任何 Activity 。

这是我的问题:

我有一个 Android 应用程序，其中用户拥有多组项目，每个项目大约有 10 个属性。

我现在在做什么:

• 项目存储在服务器数据库中
• 当用户登录时，我通过 API 获取所有项目(比如 37)，并将它们放入 LinkedHashSet< UserItem >(UserItem 是一个带有 setter 和 getter 的 POJO)
• 然后我从集合中获取 37 个项目并将它们放入本地 SQLite 数据库
• 当用户在应用中打开“我的项目”屏幕时，我从本地 SQLite DB 获取 37 个项目

我在想，这是一个好的做法吗？我可以绕过第 3 步(将项目存储在本地数据库中)，而是维持 LinkedHashSet 对象的生命周期并直接从那里获取项目吗？如果我的建议是正确的，我该怎么做？

Answer 1

就我个人而言，根据我自己的经验，我会避免第二个数据库存储。引入 2 个数据库，一个用于加载，一个用于存储，引入了一个新的潜在故障点，因为另外在同步内存中的数据时，您必须在某个时刻同步两个数据库，这意味着您必须实现一个额外的过程，这可能会降低性能。

此外:假设您已将 LinkedHashSet 与本地 SQLite 数据库同步，但未与服务器的数据库同步，并且由于某种原因 Android 决定终止您的应用:您拥有 LinkedHashSet 在内存中，哎呀...您在内存中的更改丢失了。现在你重新启动你的应用程序，哪个数据库拥有最新的数据？好吧，您可以存储 last_change 时间戳值，但我试图让您看到它不值得。至少不是两个相同的类型。

我要做的是其中之一:

• 只需使用中央服务器数据库即可。要同步，当您的应用程序处于 Activity 状态时，请定期(在合理的时间内)打开一个新的Thread或AsyncTask，这将打开一个Socket到您的中央数据库并同步您的数据(与另存为草稿... 机制类似的行为)。您的应用程序可能会崩溃，但如果您定期同步数据，损失不会像您不会那么灾难性，因为您将有一个相当新的备份。支持这种方法的事实是，通过这种方式，您的数据将始终保持最新。缺点是您必须设置一个“更强大”的数据库服务器(我的意思是在硬件性能方面)，就好像您计划拥有很多用户一样，对数据库的请求现在会更加频繁(总体而言，对于写入而言) 。另一个缺点是连接问题。可能会发生在某些时候由于连接问题而无法连接到数据库的情况，但这仅意味着您必须通过捕获相应的异常来处理此过程.

• 如果您不喜欢第一种方法，还有另一个想法:您使用 POJO，这意味着它可以转换为 JSON，因此您可以将其保存到 SharedPreferences 。这可能是您的辅助数据库，结合定期同步的想法，您可以简单地将其保存到您的 SharedPreferences 中并将其用作存储。有时只需将这些首选项与您的中央数据库同步(例如，每次启动应用程序时)，主要优点是这是一个非常有效的操作(因此您可以比数据库同步方法更频繁地调用它)，这样你就会拥有某种复制系统。