问：SharedPreferences 存储比较大或者比较读的键值对会有什么问题吗？为什么？
答：SharedPreferences 是一种轻量级的存储方式，之所以轻量级是由其设计所决定的，因为 SharedPreferences 在创建的时候会把整个文件全部加载进内存，所以如果 SharedPreferences 文件比较大就会带来如下一些性能问题：
首次从 SharedPreferences 获取值时可能阻塞主线程从而使 UI 界面卡顿丢帧。
解析 SharedPreferences 时会产生大量的临时对象而导致频繁 GC 使得 UI 界面卡顿丢帧。
被解析的同一个 SharedPreferences 文件的内容会占用大量内存。
问：如何优雅的使用 SharedPreferences 存储？你有哪些经验？
答：
SharedPreferences 中不要存放大的键值对，因为会占用太多内存、引起 UI 卡顿及内存抖动等问题。
在进行 SharedPreferences 数据持久时应该对持久化数据进行分类，多 SharedPreferences 文件存储（譬如同一功能相关的放一个文件，或者按照读写频率及大小进行文件拆分），因为文件越大读取越慢，所以分类存储相对会好很多。
对于频繁修改尽量做到批量一次性提交，尽量不要多次 edit 和 commit 或者 apply。
不要直接用其进行跨进程读写操作，因为 SharedPreferences 不是进程安全的（MODE_MULTI_PROCESS 标记只是保证了在 API 11 以后如果内存中已经存在该 SharedPreference 则重新读一次文件到内存而已），如果要进行跨进程读写保证进程并发安全则建议使用 ContentProvider 对 SharedPreferences 进行包装或者采用其他 AIDL 等方式存储实现。
问：SharedPreferences 的加载实现是在子线程，但是为什么说 getX(key) 操作可能还会阻塞主线程呢？
答：看过 SharedPreferences 实现源码的小伙伴一定知道怎么回事了，下面给出关键部分源码分析。
//getSharedPreferences 获取 SP 的核心源码
class ContextImpl extends Context {
//Context会把对应 SP 缓存起来
private static ArrayMap<String, ArrayMap<File, SharedPreferencesImpl>> sSharedPrefsCache;
......
@Override
public SharedPreferences getSharedPreferences(File file, int mode) {
......
SharedPreferencesImpl sp;
synchronized (ContextImpl.class) {
final ArrayMap<File, SharedPreferencesImpl> cache = getSharedPreferencesCacheLocked();
sp = cache.get(file);
if (sp == null) {
//第一次或者新进程中时缓存没有就新 new 一个对应实例
sp = new SharedPreferencesImpl(file, mode);
cache.put(file, sp);
return sp;
}
}
......
return sp;
}
......
}
接下来看看 SharedPreferencesImpl 实例化及通过 SharedPreferences 获取一个指定 key 的值的核心源码部分，如下：
//一个File对应的一个SP实例
final class SharedPreferencesImpl implements SharedPreferences {
//用来存储该SP的所有Key-Value对
private Map<String, Object> mMap;
SharedPreferencesImpl(File file, int mode) {
......
//构造方法从磁盘加载SP文件
startLoadFromDisk();
}
private void startLoadFromDisk() {
......
//启动一个名字为SharedPreferencesImpl-load的线程从磁盘读文件
new Thread("SharedPreferencesImpl-load") {
public void run() {
loadFromDisk();
}
}.start();
}
//子线程中读取文件解析成key-value对Map
private void loadFromDisk() {
......
Map map = null;
StructStat stat = null;
try {
stat = Os.stat(mFile.getPath());
if (mFile.canRead()) {
BufferedInputStream str = null;
try {
str = new BufferedInputStream(
new FileInputStream(mFile), 16*1024);
map = XmlUtils.readMapXml(str);
} catch (Exception e) {
Log.w(TAG, "Cannot read " + mFile.getAbsolutePath(), e);
} finally {
IoUtils.closeQuietly(str);
}
}
} catch (ErrnoException e) {
/* ignore */
}
synchronized (mLock) {
mLoaded = true;
if (map != null) {
mMap = map;
mStatTimestamp = stat.st_mtime;
mStatSize = stat.st_size;
} else {
mMap = new HashMap<>();
}
//子线程读取SP文件到mMap成功后通过notify通知释放阻塞锁
mLock.notifyAll();
}
}
//通过SharedPreferences对象获取指定key的值
//（一般与SharedPreferences获取在一个线程，主线程）
public int getInt(String key, int defValue) {
synchronized (mLock) {
//阻塞等待SP读取到内存后再get
awaitLoadedLocked();
Integer v = (Integer)mMap.get(key);
return v != null ? v : defValue;
}
}
private void awaitLoadedLocked() {
......
while (!mLoaded) {
try {
//阻塞等待SP读取到内存完成
mLock.wait();
} catch (InterruptedException unused) {
}
}
}
......
}
从上面代码可以看出，SharedPreferences 读取 Map 虽然在子线程，但是其 getX(key) 系列方法想要调用的前提是 SharedPreferences 子线程已经读取完成，否则就会阻塞，所以 SharedPreferences 中如果存储太大内容或者太多内容导致 XML 解析等变慢就会导致后面的 getX(key) 阻塞主线程，从而导致主线程卡顿，所以说 SharedPreferences 是轻量级的持久化工具。
因此首次使用一个指定 File 的 SharedPreferences 时最好先尽可能早的调用 getSharedPreferences() 获取 SharedPreferences 实例，然后在用的时候调用其 getX(key) 方法，这样就尽可能的避免了潜在的阻塞问题，不过这个建议不是绝对的，如果你的 SharedPreferences 比较小或者这种建议会破坏你代码的组织性，则可以忽略。
问：SharedPreferences 为什么存储大数据就比较占用内存？
答：通过上面一题源码的分析你会发现 SharedPreferencesImpl 会将 File 文件在子线程中全部加载到一个内存的 Map 中，而 SharedPreferences 对象又会被 ContextImpl 的 static Map 进程 Cache 操作，所以 SharedPreferencesImpl 就相当于是一个单例存储的，故而其 Map 在内存中就会持续存在，即便使用 Editor 进行修改后 commit 操作实质也是对 SharedPreferencesImpl 中 Map 进行对应操作。
//一个SharedPreferences的get操作与Editor操作对应的内存Map操作原理
final class SharedPreferencesImpl implements SharedPreferences {
//用来存储该SP的所有Key-Value对
private Map<String, Object> mMap;
......
SharedPreferencesImpl(File file, int mode) {
......
//构造方法新起一个线程从磁盘加载SP文件解析XML到mMap中
startLoadFromDisk();
}
......
//通过SharedPreferences对象获取指定key的值
public int getInt(String key, int defValue) {
......
Integer v = (Integer)mMap.get(key);
return v != null ? v : defValue;
}
......
//通过SharedPreferences.edit()获取的Editor对象
public final class EditorImpl implements Editor {
//Editor要增删改查的操作Map记录
private final Map<String, Object> mModified = Maps.newHashMap();
......
public Editor putString(String key, @Nullable String value) {
......
mModified.put(key, value);
}
......
public Editor remove(String key) {
......
mModified.put(key, this);
}
......
//提交到内存mMap
// Returns true if any changes were made
private MemoryCommitResult commitToMemory() {
......
for (Map.Entry<String, Object> e : mModified.entrySet()) {
String k = e.getKey();
Object v = e.getValue();
if (v == this || v == null) {
if (!mMap.containsKey(k)) {
continue;
}
mMap.remove(k);
} else {
if (mMap.containsKey(k)) {
Object existingValue = mMap.get(k);
if (existingValue != null && existingValue.equals(v)) {
continue;
}
}
mMap.put(k, v);
}
changesMade = true;
if (hasListeners) {
keysModified.add(k);
}
}
//清空Editor的mModified的Map
mModified.clear();
......
}
......
//commit提交
public boolean commit() {
......
//提交到内存
MemoryCommitResult mcr = commitToMemory();
//提交到磁盘文件
SharedPreferencesImpl.this.enqueueDiskWrite(
mcr, null /* sync write on this thread okay */);
try {
mcr.writtenToDiskLatch.await();
} catch (InterruptedException e) {
return false;
} finally {
......
}
notifyListeners(mcr);
return mcr.writeToDiskResult;
}
......
}
}
你可以理解成一个 SharedPreferencesFile 对应一个单例的 SharedPreferencesImpl 对象，这个单例的 SharedPreferencesImpl 实例化时会将文件全部加载到内存中以 Map 存储，然后 Editor 操作会 new 一个新的 modifyMap，接着到了 Editor 的 commit 操作时会将 modifyMap 进行遍历增删改查到 SharedPreferencesImpl 的 Map 中，然后进行存盘操作。
而 SharedPreferencesImpl 进行 getX(key) 操作时都是直接从 SharedPreferencesImpl 的 Map 中进行读取的，所以说 SharedPreferences 只适合轻量级的数据存储操作。
