我目前正在尝试使用Android中的“共享首选项”在键值对中保存数据。好吧，我这样做的问题似乎就出现了（考虑到我保存了一大块数据。）在我的应用程序中保存多少个不同的Key Value对仍然可以？我目前正在考虑节省100到150个不同的值。 （所有仍具有唯一的键字符串名称。）使用共享首选项存储的数据太多了吗？
这可能是一个愚蠢的问题，但唯一愚蠢的问题是未提出的问题，我似乎无法找到答案。只有我所知道的是你应该只使用共享首选项保存原始值。 （我已经这样做了......） - 谢谢你
答案 0 :(得分：5)
有多少是真正的意见问题。但是，值得注意的是SharedPreferences work in order to get a feel for whether using SharedPreferences`是如何实现的。
据我所知，SharedPreferences的大小没有硬性限制，但SharedPreferences存储在XML文件中，当您第一次访问SharedPreferences整个文件时读取并存储在内存中，因此这本身会对应用程序使用的堆空间产生影响，并可能导致内存不足错误（部分取决于数据的大小，可用内存以及其余内存的使用情况）应用程序要求）。因此，对大量数据使用SharedPreferences通常意味着您使用的内存超过了必要的数量。如果您正在将数据从SharedPreferences读入另一个数据结构，那么您将在内存中将此数据两次。此外，就文件系统上使用的空间而言，XML效率不高。
我并不是说使用SharedPreferences是错误的，但是在使用可能更高效的内存（例如SQLite DB）和提供额外功能（搜索，事务支持等）之间经常需要权衡。 ，与使用SharedPreferences的简单性相比。
它还部分取决于您存储的内容 - 例如无论是存储布尔值还是长字符串，都会在内存使用方面产生巨大差异。您正在对数据进行的操作可能会对哪种方式产生影响。您是否需要它可扩展（例如，您现在存储100到150个值，但可能会增加吗？）。
如果我是你，我会考虑我的数据有多大（即使用的内存量不仅仅是键值对的数量）？未来我还需要存储更多吗？ SQLite的额外功能是否有用？
根据您提供的有限信息，我的直觉是我可能会使用SQLite，但我的基础是可扩展性可能很重要并且您存储的字符串超过几个字符，即便如此，我确信有些人会不同意，因为“多少太多”在这种情况下是主观的。