Question

我需要存储我的Android应用程序的很多可变数量的复选框状态。每隔5-10分钟我需要检索一个复选框的状态（应该通过其他活动中的用户交互来更改）。我知道我可以将它们存储在sharedPreferences或SQLite数据库中。数字或复选框的变量范围为10到（infinite-1）。

我的第一个想法是将所有状态存储在一个字符串中：

chk1:true,chk2:false,chk3:false,chk4:false,chk5:true

由:和,分隔。我可以在一个getString()电话中检索所有我的复选框stasus。

我离开了这个解决方案，因为我的复选框数量不断增加，而且我认为只有一个包含数千个数据的字符串就没有效果。

我的第二个想法是将每个chk存储在不同的首选项中。我离开了这个解决方案，因为我需要检索我的复选框状态。想象getString()调用10000次或更多次，这是浪费资源。

我的第三个想法是将所有单个状态存储在SQLite数据库中。

 ID   Status
  1      T
  2      F
  3      F
  4      F
  5      T

在这个解决方案中，我不喜欢我需要很多时间访问我的数据库。

如果我需要每5分钟检索一次从现在到无限的复选框状态，那么最佳解决方案（性能和内存消耗）是什么？ DB或sharedpref ？如果DB，我需要每次打开db并实例化一个Cursor，或者我应该在活动开始时实例化它？

Answer 1

我肯定会选择SQLite。

共享首选项和SQLite都有缓存机制，但SQLite专门用于检索和存储大量数据，而共享首选项更适合于简单的应用程序......以及...首选项。

此外，如果您的数据模型发生变化，SQLite特别有用（相信我，这种情况一直都会发生）。 SQLite还会缓存一些最常用的数据片段（技术上：数据库的页面） - 它将适应数据的实际使用模式。

至于打开数据库 - 我肯定建议打开它一次并多次重用你创建的连接 - 这将节省你每次打开数据库的开销（这是一项代价高昂的操作）并且还允许SQLite学习（适应）如何根据实际使用方式缓存数据（例如访问顺序，特定SQL语句缓存等）。