共享首选项“限制”
我知道类似的问题已经被问了无数次，我在网上冲浪，所以我部分地找到了答案，但并不完整，android文档也没有真正的帮助。显然，我知道它们是如何工作的，并且之前已经多次使用共享首选项，但我想知道在什么时候(多少)是太多了，我读到人们有~100KB存储没有任何问题。长话短说--是否有人真的对存储在共享首选项中的太多数据有问题，问题是什么，数据是被删除还是被删除？
**这只是一个好奇的问题，我已经在SQL DB中存储了我的大值，只是想知道如果有人出于某种原因将所有内容都存储在共享首选项中会有什么问题
回答 3
Stack Overflow用户
发布于 2013-03-25 23:21:44
由于SharedPreferences存储在XML文件中，因此缺乏SQLite的强大事务支持，因此我不建议在SharedPreferences中存储“100KB”。
也就是说，我所知道的最小大小限制是您的空闲堆空间量，因为SharedPreferences将整个XML文件的内容读取到内存中。
Stack Overflow用户
发布于 2015-06-04 16:27:52
SharedPreference数据有其局限性。在我例子中，当SharedPreference数据超过1428.51 kb时，它会抛出内存异常。
因此，当您需要存储大量数据时，最好使用SQLite数据库。
Stack Overflow用户
发布于 2013-03-25 23:25:33
通过阅读您的问题，我认为您不应该使用SharedPreferences，因为(a)它们用于存储小得多的数据量(因此使用XML)，以及(b)有许多简单的替代方案。
SharedPreferences唯一的“特殊”之处在于它集成了Preferences活动，可以向用户显示您的首选项，而根据您计划存储的数量，这可能不适用于您的情况。(哦，SharePreferences还会为您处理并发问题。)
您可以使用Java的序列化将首选项类存储在二进制文件中。它们将比可比的PreferenceFile小得多，并且可以很容易地通过GZIPInputStream来使其更小(或CipherInputStream)来加密它。我发现这种替代方法是一种强大、简单和跨平台的方法，可以在不需要SQLite功能的地方存储应用程序数据。
(抱歉，这不是一个直接的回答。)
https://stackoverflow.com/questions/15617825
复制相似问题