我知道与这个问题类似的问题已经被问过很多次了，通过浏览所以我部分找到了答案，但并不完整，而且 android 文档并没有真正的帮助。显然我知道它们是如何工作的，并且以前曾多次使用过共享偏好，但我想知道什么时候（多少）太多了，我读过人们存储了 ~ 100KBS 没有任何问题。长话短说——是否有人在共享首选项中存储了太多数据，问题是什么，数据是否被删除？
** 这只是一个出于好奇的问题，我已经将我的大值存储在 SQL DB 中，只是想知道如果有人出于某种原因将所有内容存储在共享首选项中会出现什么问题以及是否会有任何问题
由于SharedPreferences存储在 XML 文件中，因此缺乏 SQLite 的强大事务支持，我不建议将“100KBS”存储在SharedPreferences.
话虽如此，我知道的最小大小限制将是您的可用堆空间量，因为SharedPreferences将整个 XML 文件的内容读入内存。
SharedPreference 数据存在局限性。在我的情况下，当 SharedPreference 数据跨越 1428.51-kb 时，它会引发内存异常。
因此，当您需要存储大量数据时，最好使用 SQLite 数据库。
通过阅读您的问题，我认为您不应该使用 SharedPreferences，因为（a）它们旨在存储更少量的数据（因此使用 XML），并且（b）有许多简单的替代方案。
SharedPreferences 唯一“特别”的是与 Preferences Activity 的集成，用于向用户显示您的偏好，根据您计划存储的数量，这可能不适用于您的情况。（哦，SharePreferences 也为您处理并发问题。）
您可以使用 Java 的序列化将 Preference 类存储在二进制文件中。这些将比可比较的 PreferenceFile 小得多，并且可以轻松地通过 GZIPInputStream 传递以使其更小（或 CipherInputStream）以对其进行加密。我发现这种替代方法是一种强大、简单且跨平台的方式来存储不需要 SQLite 功能的应用程序数据。
（对不起，这不是一个直接的答案。）