私はこれと同様の質問が何度も聞かれていることを知っています、そしてそれをサーフィンして私は部分的に答えを見つけましたが、完全ではありません、そしてアンドロイドドキュメントは本当に役に立ちません。明らかに、それらがどのように機能するかを知っており、共有設定を何度も使用したことがありますが、どの時点（いくつ）が多すぎるのか疑問に思っています。問題なく100KBSまで保存されている人を読んだことがあります。簡単に言うと、共有設定に保存されているデータが多すぎるという問題が実際に発生したのでしょうか。また、何が問題だったのでしょうか。データが削除されるのでしょうか。
**これは好奇心からの質問です。私はすでに大きな値をSQLDBに保存していますが、誰かが何らかの理由ですべてを共有設定に保存した場合、問題が発生するかどうか疑問に思いました。
XMLファイルに保存され、SQLiteの強力なトランザクションサポートが不足しているためSharedPreferences、「100KBS」をに保存することはお勧めしませんSharedPreferences。
そうは言っても、私が知っている最小のサイズ制限は、SharedPreferencesXMLファイルの内容全体をメモリに読み込むための空きヒープスペースの量です。
SharedPreferenceデータには制限があります。私の場合、SharedPreferenceデータが1428.51-kbを超えると、メモリ例外がスローされます。
したがって、保存するのに膨大なデータが必要な場合は、SQLiteデータベースを使用することをお勧めします。
あなたの質問を読んだことから、SharedPreferencesは（a）はるかに少量のデータを格納することを目的としているため（したがってXMLを使用）、（b）多くの単純な代替手段があるため、SharedPreferencesを使用すべきではないと思います。
SharedPreferencesの「特別な」唯一のことは、ユーザーに設定を表示するための設定アクティビティとの統合です。これは、保存する予定の量に基づいて、おそらくあなたのケースには当てはまりません。（ああ、SharePreferencesも並行性の問題を処理します。）
Javaのシリアル化を使用して、Preferenceクラスをバイナリファイルに保存できます。これらは、同等のPreferenceFileよりも大幅に小さくなり、GZIPInputStreamを介して簡単に渡して、暗号化するために小さく（またはCipherInputStream）することができます。この代替手段は、SQLiteの機能が不要な場所にアプリデータを保存するための、強力でシンプルなクロスプラットフォームの方法であることがわかりました。
（申し訳ありませんが、これは直接の答えではありません。）