我不知道在哪里问这个问题，我找不到有关android应用程序体系结构的战略信息，即“全图”信息，因此请耐心等待。我尝试了developers.stackexchange，但是那里几乎没有活动。
这是我的问题：
我有一个Android应用程序，其中用户具有项目集，每个项目都有大约10个属性。
我目前正在做什么：
我当时在想，这是一种好习惯吗？我可以绕过第3步（将项目存储在本地数据库中），但是可以维护该LinkedHashSet对象的寿命并直接从那里获取项目。如果我对这个建议是正确的，我该怎么做？
就个人而言，以我自己的经验，我会避免第二个数据库存储。引入2个数据库（其中一个用于装载，另一个用于存储）会引入一个新的潜在故障点，因为另外，在将数据同步到内存中后，您还必须在某个时刻同步两个数据库，这意味着您必须实施一个额外的过程，这在性能上可能是昂贵的。
此外：假设您已LinkedHashSet与本地SQLite数据库进行了同步，但未与服务器数据库进行同步，并且由于某种原因，Android决定终止您的应用程序：您LinkedHashSet的内存不足，哎呀……您的内存更改丢失了。现在，您重新启动应用程序，哪个数据库具有最新数据？好的，您可以存储一个last_change时间戳值，但是我想让它看不到它是不值得的。至少不是同一类型的两个。
我要做的是以下之一：
只需使用中央服务器数据库。要进行同步，请在您的应用程序处于活动状态时，定期（在合理的时间内）打开一个新文件，Thread或者AsyncTask将一个新文件打开Socket到您的中央数据库并同步您的数据（与该Saving as draft...机制类似的行为）。您的应用可能会崩溃，但是如果您定期同步数据，则损失不会像您那样灾难性，因为您将拥有一个合理的最近备份。支持这种方法的事实是，这样一来，您几乎总是可以拥有自己的数据最新。缺点是，您必须设置一个“更强”的数据库服务器（我的意思是在硬件性能上），就好像您打算有很多用户一样，现在，对数据库的请求将变得更加频繁（总体而言，用于编写） 。另一个缺点是连接性主题。可能会发生某些情况，由于连接问题而无法连接到数据库，但这仅意味着您必须通过catch处理相应的Exceptions来处理此过程。
如果您不喜欢第一种方法，则有另一个想法：使用POJO，这意味着可以将其转换为JSON，因此可以将其保存到中SharedPreferences。这可能是您的辅助数据库，并且与定期同步的想法一起，您可以简单地将其保存到您的数据库中SharedPreferences并将其用作存储。一次只需将这些首选项与中央数据库同步即可（例如，每次启动应用程序时），其主要优点是这是一个非常高效的操作（因此，与数据库同步方法相比，您可以更频繁地调用它） ），这样您将拥有某种复制系统。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句