目录

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因为是使用异步队列的形式，会有一定的提交失败概率，详情请看https://www.jianshu.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