SharedPreferences的原理及使用
全面剖析SharedPreferences
全面剖析SharedPreferences
1.原理和概述
1.储存于硬盘上的xml键值对。
2.轻量级数据储存，数据多了容易引起性能问题
3.xml文件所在目录位于/data/data//shared_prefs/，可以有多个文件。
2.初始化
1.ContextImpl记录着SharedPreferences的重要数据
1.sSharedPrefsCache:以包名为key, 二级key是以SP文件, 以SharedPreferencesImpl为value的嵌套map结构. 这里需要sSharedPrefsCache是静态类成员变量, 每个进程是保存唯一一份, 且由ContextImpl.class锁保护.
2.mSharedPrefsPaths:记录所有的SP文件, 以文件名为key, 具体文件为value的map结构
3.mPreferencesDir:是指SP所在目录, 是指/data/data//shared_prefs/
2.Context.getSharedPreferences(name, mode)获取SharedPreferences，只要是Context都能获取
1.先从mSharedPrefsPaths查询是否存在相应文
2.如果文件不存在, 则创建新的xml文件; 如果目录也不存在, 则先创建目录创建目录/data/data/package name/shared_prefs/
3.检查mode
1.MODE_WORLD_READABLE和MODE_WORLD_WRITEABLE 在android N开始就会抛出异常，防止外部应用读写该文件
2.MODE_MULTI_PROCESS 是多进程方式使用文件，由于有内存缓存的缘故这种模式下不怎么能保证进程安全，后续google不再支持。代替的方式有ContentProvider。
4.创建同名的.bak备份文件用于发生异常时, 可通过备份文件来恢复数据.
5.将xml文件加载到内存中，这个操作的线程是新开的，但是会阻塞getXXX()和setxxx()以及edit()方法。
6.一旦完全加载到内存, 后续的getXXX()则是直接访问内存
3.读取
1.在xml文件全部内加载到内存中之前，读取操作是阻塞的
2.在xml文件全部内加载到内存中之后，是直接读取内存中的数据
4.写入
1.获取一个Editor
2.putXXX的时候，只是将数据写入到内存中的一个mModified Map中
3.执行commit 或 apply操作
1.commit：
1.将mModified的数据更新到SPI的mMap中
2.当没有key发生改变, 则直接返回; 否则将mMap全部信息写入文件, 如果写入成功则删除备份文件,如果写入失败则删除mFile
3.每次commit是把全部数据更新到文件, 所以每个文件的数据量必须保证足够精简
2.apply：
1.apply跟commit的最大区别 在于apply的写入文件操作是在单线程的线程池来完成.而commit是在当前线程阻塞运行的。
2.apply方法开始的时候, 会把一个任务awaitCommit，放入一个任务队列中QueuedWork
3.单线程池会不断从QueuedWork取任务然后执行。
QueuedWork在这里存在的价值主要是用于在Stop Service, finish BroadcastReceiver过程用于 判定是否处理完所有的异步SP操作.
4.总结
1.apply因为是异步的没有返回值, commit是同步的有返回值能知道修改是否提交成功
2.多并发的提交commit时，需等待正在处理的commit数据更新到磁盘文件后才会继续往下执行，从而降低效率; 而apply只是原子更新到内存，后调用apply函数会直接覆盖前面内存数据，从一定程度上提高很多效率。 3.edit()每次都是创建新的EditorImpl对象.
5.优化
1.sp里面存储特别大的key/value, 有助于减少卡顿/anr
2.不要高频地使用apply和commit, 尽可能地批量提交。因为每次提交就是xml文件的全部重写
3.commit直接在主线程操作, 要注意
4.不要使用MODE_MULTI_PROCESS，多线程不应该使用SPI
5.高频写操作的key与高频读操作的key可以适当地拆分文件, 由于减少同步锁竞争
6.不要一上来就执行getSharedPreferences().edit()，因为getSharedPreferences()是在其他线程进行但是会阻塞.edit()。
7.不要连续多次edit(), 应该获取一次获取edit(),然后多次执行putxxx(), 减少内存波动。
