目录
1、源码简单分析
2、对比commit和apply
3、为什么会造成ANR？
4、可以跨进程通信？
5、有什么优化方式和存储替代方案？
1、源码简单分析(api 28)
SharedPreferences大致流程：
在ContextImpl中进行初始化，在SharedPreferenceImpl实现读写数据。
SharedPreferences整体结构和类：
- SharedPreferences和Editor是个接口
- SharedPreferenceImpl是SharedPreferences的实现类
- EditorImpl是Editor的实现类，它是SharedPreferenceImpl的内部类
SharedPreferences存储位置：
//通过在ContextImpl实现类中的一段代码看出
private File getPreferencesDir() {
synchronized (mSync) {
if (mPreferencesDir == null) {
mPreferencesDir = new File(getDataDir(), "shared_prefs");
}
return ensurePrivateDirExists(mPreferencesDir);
}
}
/data/data/应用包名/shared_prefs/xxx.xml
//存储结构
<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<map>
<boolean name="key3" value="false" />
<int name="key2" value="134" />
<string name="key1">test</string>
</map>
总结：
1、第一次调用getSharedPreferences时，xml文件会被加载进内存缓存起来，这是一个耗时操作，会阻塞主线程。当第二次调用getSharedPreferences时，会直接从内存中读取，避免了频繁的I/O操作。
2、SharedPreferences 的写入操作，首先是将源文件备份：mFile.renameTo(mBackupFile)，再写入所有数据，只有写入成功，并且通过sync完成落盘后，才会将Backup(.bak)文件删除。如果写入过程中进程被杀，或者关机等非正常情况发生，进程再次启动后如果发现该SharedPreferences存在Backup文件，就将Backup 文件重名为源文件，原本未完成写入的文件就直接丢弃，这样最多也就是未完成写入的数据丢失，它能保证保存最后一次落盘(真正落盘)成功后的数据。
2、对比commit和apply
执行方式：
commit是同步的执行writeToFile，有返回值
apply是将writeToFile加入到一个任务队列中异步的执行，无返回值
执行耗时：
| 提交方式 | 数据量 | 耗时(ms) |
|---|---|---|
| commit多次提交 | 30 | 22 |
| apply多次提交 | 30 | 3 |
| commit一次性提交 | 30 | 11 |
| apply一次性提交 | 30 | 1 |
//多次提交
SharedPreferences sp = getSharedPreferences("test", Context.MODE_PRIVATE);
SharedPreferences.Editor editor = sp.edit();
editor.putString("key1", "test").apply();
editor.putString("key2", "test").apply();
//一次性提交
SharedPreferences sp = getSharedPreferences("test", Context.MODE_PRIVATE);
SharedPreferences.Editor editor = sp.edit();
editor.putString("key1", "test");
editor.putString("key2", "test");
editor.apply();
温馨提示：执行耗时仅供参考
都会引发ANR
斗罗小剧场
小舞：commit和apply执行耗时相差这么大，以后就用apply了。
小三：也不是这样的哦，apply也有弊端的。apply因为是使用异步队列的形式，会有一定的提交失败概率，详情请看//www.greatytc.com/p/9ae0f6842689?tdsourcetag=s_pctim_aiomsg
小舞：哥，你太厉害了
3、为什么会造成ANR？
1、SharedPreferences是轻量级存储，因为是将数据加载到内存中，如果占用内存较大容易内存溢出。
2、另外如果存储数据量较大，第一次调用getSharedPreferences时将数据加载到内存中，又立马调用了getXXX方法，如果阻塞时间较长容易造成ANR。
4、可以跨进程通信？
SharedPreferences为我们提供了Context.MODE_MULTI_PROCESS的加载模式，但在跨进程频繁读写有可能导致数据全部丢失。根据线上统计，SharedPreferences大约会有万分之一的损坏率，官方也已经废弃这种方式。所以不建议使用这种方式进行跨进程通信。
//当应用指定的targetSdkVersion小于API Level 11时，则重新从文件中加载一遍数据到内存中
//当多个进程进行数据读写时，数据有可能不同步并且丢失
if ((mode & Context.MODE_MULTI_PROCESS) != 0 ||
getApplicationInfo().targetSdkVersion < android.os.Build.VERSION_CODES.HONEYCOMB) {
sp.startReloadIfChangedUnexpectedly();
}
5、有什么优化方式和存储替代方案？
优化方式：
1、读取频繁的key和不频繁的key尽量不要放在一起(如果整个文件本身就较小则可以忽略)，尽量避免存储较大的value，这时可以考虑分文件存储。
2、替换Application的getSharedPreferences方法：
public class StartApplication extends Application {
@Override
public SharedPreferences getSharedPreferences(String name, int mode){
return SharedPreferencesImpl.getSharedPreferences(name, mode);
}
}
同时还需要替换Activity的getSharedPreferences方法：
@Override
public SharedPreferences getSharedPreferences(String name, int mode) {
return this.getApplicationContext().getSharedPreferences(name, mode);
}
温馨提示：对系统提供的SharedPreferences的小修补虽然性能有所提升，但是依然不能彻底解决问题。
3、在Application中先初始化SharedPreferences对象，避免第一次getSharedPreferences的耗时问题。
4、能一起提交的数据尽量使用一个Editor进行提交，减少IO操作，提高效率。
5、因为apply会导致ANR，也会有一定失败的概率，如果想要使用commit但是担心commit在主线程保存数据会导致ANR，其实有一种做法就是直接新建一个子线程来执行，可以考虑用一个单线程池来进行封装。
存储替代方案：
Sqlite、MMKV
