一、SharedPreferences简略应用
1、创立
第一个参数是贮存的xml文件名称，第二个是打开方式，个别就用
Context.MODE_PRIVATE；SharedPreferences sp=context.getSharedPreferences("名称", Context.MODE_PRIVATE);2、写入
//能够创立一个新的SharedPreference来对贮存的文件进行操作SharedPreferences sp=context.getSharedPreferences("名称", Context.MODE_PRIVATE);//像SharedPreference中写入数据须要应用EditorSharedPreference.Editor editor = sp.edit();//相似键值对editor.putString("name", "string");editor.putInt("age", 0);editor.putBoolean("read", true);//editor.apply();editor.commit();- apply和commit都是提交保留，区别在于apply是异步执行的，不须要期待。不管删除，批改，减少都必须调用apply或者commit提交保留；
- 对于更新：如果曾经插入的key曾经存在。那么将更新原来的key；
- 应用程序一旦卸载，SharedPreference也会被删除；
3、读取
SharedPreference sp=context.getSharedPreferences("名称", Context.MODE_PRIVATE);//第一个参数是键名，第二个是默认值String name=sp.getString("name", "暂无");int age=sp.getInt("age", 0);boolean read=sp.getBoolean("isRead", false);4、检索
SharedPreferences sp=context.getSharedPreferences("名称", Context.MODE_PRIVATE);//查看以后键是否存在boolean isContains=sp.contains("key");//应用getAll能够返回所有可用的键值//Map<String,?> allMaps=sp.getAll();5、删除
当咱们要革除SharedPreferences中的数据的时候肯定要先clear()、再commit()，不能间接删除xml文件；
SharedPreference sp=getSharedPreferences("名称", Context.MODE_PRIVATE);SharedPrefence.Editor editor=sp.edit();editor.clear();editor.commit();- getSharedPreference() 不会生成文件，这个大家都晓得；
- 删除掉文件后，再次执行commit()，删除的文件会新生，新生文件的数据和删除之前的数据雷同；
- 删除掉文件后，程序在没有齐全退出进行运行的状况下，Preferences对象所存储的内容是不变的，尽管文件没有了，但数据仍然存在；程序齐全退出进行之后，数据才会失落；
革除SharedPreferences数据肯定要执行editor.clear()，editor.commit()，不能只是简略的删除文件，这也就是最初的论断，须要留神的中央
二、SharedPreferences源码剖析
1、创立
SharedPreferences preferences = getSharedPreferences("test", Context.MODE_PRIVATE);实际上context的真正实现类是ContextImp，所以进入到ContextImp的getSharedPreferences办法查看：
@Override public SharedPreferences getSharedPreferences(String name, int mode) { ...... File file; synchronized (ContextImpl.class) { if (mSharedPrefsPaths == null) { //定义类型：ArrayMap<String, File> mSharedPrefsPaths; mSharedPrefsPaths = new ArrayMap<>(); } //从mSharedPrefsPaths中是否可能失去file文件 file = mSharedPrefsPaths.get(name); if (file == null) {//如果文件为null //就创立file文件 file = getSharedPreferencesPath(name); 将name，file键值对存入汇合中 mSharedPrefsPaths.put(name, file); } } return getSharedPreferences(file, mode); }ArrayMap<String, File> mSharedPrefsPaths;对象是用来存储SharedPreference文件名称和对应的门路，获取门路是在下列办法中，就是获取data/data/包名/shared_prefs/目录下的
@Overridepublic File getSharedPreferencesPath(String name) { return makeFilename(getPreferencesDir(), name + ".xml");}private File getPreferencesDir() { synchronized (mSync) { if (mPreferencesDir == null) { mPreferencesDir = new File(getDataDir(), "shared_prefs"); } return ensurePrivateDirExists(mPreferencesDir); }}门路之后才开始创建对象
@Override public SharedPreferences getSharedPreferences(File file, int mode) { //重点1 checkMode(mode); ....... SharedPreferencesImpl sp; synchronized (ContextImpl.class) { //获取缓存对象（或者创立缓存对象） final ArrayMap<File, SharedPreferencesImpl> cache = getSharedPreferencesCacheLocked(); //通过键file从缓存对象中获取Sp对象 sp = cache.get(file); //如果是null，就阐明缓存中还没后该文件的sp对象 if (sp == null) { //重点2：从磁盘读取文件 sp = new SharedPreferencesImpl(file, mode); //增加到内存中 cache.put(file, sp); //返回sp return sp; } } //如果设置为MODE_MULTI_PROCESS模式，那么将执行SP的startReloadIfChangedUnexpectedly办法。 if ((mode & Context.MODE_MULTI_PROCESS) != 0 || getApplicationInfo().targetSdkVersion < android.os.Build.VERSION_CODES.HONEYCOMB) { sp.startReloadIfChangedUnexpectedly(); } return sp; }就是重载之前的办法，只是入参由文件名改为File了，给创立过程加锁了synchronized ，通过办法getSharedPreferencesCacheLocked()获取零碎中存储的所有包名以及对应的文件，这就是每个sp文件只有一个对应的SharedPreferencesImpl实现对象起因
流程：
- 获取缓存区，从缓存区中获取数据，看是否存在sp对象，如果存在就间接返回
- 如果不存在，那么就从磁盘获取数据，
- 从磁盘获取的数据之后，增加到内存中，
- 返回sp；
getSharedPreferencesCacheLocked
private ArrayMap<File, SharedPreferencesImpl> getSharedPreferencesCacheLocked() { if (sSharedPrefsCache == null) { sSharedPrefsCache = new ArrayMap<>(); } final String packageName = getPackageName(); ArrayMap<File, SharedPreferencesImpl> packagePrefs = sSharedPrefsCache.get(packageName); if (packagePrefs == null) { packagePrefs = new ArrayMap<>(); sSharedPrefsCache.put(packageName, packagePrefs); } return packagePrefs; }- getSharedPreferences(File file, int mode)办法中，从下面的零碎缓存中分局File获取- SharedPreferencesImpl对象，如果之前没有应用过，就须要创立一个对象了，通过办法checkMode(mode);
- 先查看mode是否是三种模式，而后通过sp = new SharedPreferencesImpl(file, mode);
创建对象，并将创立的对象放到零碎的packagePrefs中，不便当前间接获取；
SharedPreferencesImpl(File file, int mode) { mFile = file; //存储文件 //备份文件（灾备文件） mBackupFile = makeBackupFile(file); //模式 mMode = mode; //是否加载过了 mLoaded = false; // 存储文件内的键值对信息 mMap = null; //从名字能够晓得是：开始加载数据从磁盘 startLoadFromDisk(); }- 次要是设置了几个参数，mFile 是原始文件；mBackupFile 是后缀.bak的备份文件；
- mLoaded标识是否正在加载批改文件；
- mMap用来存储sp文件中的数据，存储时候也是键值对模式，获取时候也是通过这个获取，这就是示意每次应用sp的时候，都是将数据写入内存，也就是sp数据存储数据快的起因，所以sp文件不能存储大量数据，否则执行时候很容易会导致OOM；
- mThrowable加载文件时候报的谬误；
- 上面就是加载数据的办法startLoadFromDisk();从sp文件中加载数据到mMap中
2、startLoadFromDisk()
private void startLoadFromDisk() { synchronized (mLock) { mLoaded = false; } //开启子线程加载磁盘数据 new Thread("SharedPreferencesImpl-load") { public void run() { loadFromDisk(); } }.start(); } private void loadFromDisk() { synchronized (mLock) { //如果加载过了 间接返回 if (mLoaded) { return; } //备份文件是否存在， if (mBackupFile.exists()) { //删除file原文件 mFile.delete(); //将备份文件命名为：xml文件 mBackupFile.renameTo(mFile); } } ....... 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; //数据不是null if (map != null) { //将map赋值给全局的存储文件键值对的mMap对象 mMap = map; //更新内存的批改工夫以及文件大小 mStatTimestamp = stat.st_mtime; mStatSize = stat.st_size; } else { mMap = new HashMap<>(); } //重点：唤醒所有以mLock锁的期待线程 mLock.notifyAll(); } }- 首先判断备份文件是否存在，如果存在，就更该备份文件的后缀名；接着就开始读取数据，而后将读取的数据赋值给全局变量存储文件键值对的mMap对象，并且更新批改工夫以及文件大小变量；
- 唤醒所有以mLock为锁的期待线程；
- 到此为止，初始化SP对象就算实现了，其实能够看进去就是一个二级缓存流程：磁盘到内存；
3、get获取SP中的键值对
@Nullable public String getString(String key, @Nullable String defValue) { synchronized (mLock) { 锁判断 awaitLoadedLocked(); //期待机制 String v = (String)mMap.get(key); //从键值对中获取数据 return v != null ? v : defValue; } } private void awaitLoadedLocked() { ....... while (!mLoaded) { //在加载数据结束的时候，值为true try { //线程期待 mLock.wait(); } catch (InterruptedException unused) { } } }如果数据没有加载结束（也就是说mLoaded=false），此时将线程期待；
4、putXXX以及apply源码
public Editor edit() { //跟getXXX原理一样 synchronized (mLock) { awaitLoadedLocked(); } //返回EditorImp对象 return new EditorImpl(); } public Editor putBoolean(String key, boolean value) { synchronized (mLock) { mModified.put(key, value); return this; } } public void apply() { final long startTime = System.currentTimeMillis(); //依据名字能够晓得：提交数据到内存 final MemoryCommitResult mcr = commitToMemory(); ........//提交数据到磁盘中 SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable); //重点：调用listener notifyListeners(mcr); }- 先执行了commitToMemory，提交数据到内存；而后提交数据到磁盘中；
- 紧接着调用了listener；
5、commitToMemory
private MemoryCommitResult commitToMemory() { long memoryStateGeneration; List<String> keysModified = null; Set<OnSharedPreferenceChangeListener> listeners = null; //写到磁盘的数据汇合 Map<String, Object> mapToWriteToDisk; synchronized (SharedPreferencesImpl.this.mLock) { if (mDiskWritesInFlight > 0) { mMap = new HashMap<String, Object>(mMap); } //赋值此时缓存汇合给mapToWriteToDisk mapToWriteToDisk = mMap; ....... synchronized (mLock) { boolean changesMade = false; //重点：是否清空数据 if (mClear) { if (!mMap.isEmpty()) { changesMade = true; //清空缓存中键值对信息 mMap.clear(); } mClear = false; } //循环mModified，将mModified中的数据更新到mMap中 for (Map.Entry<String, Object> e : mModified.entrySet()) { String k = e.getKey(); Object v = e.getValue(); // "this" is the magic value for a removal mutation. In addition, // setting a value to "null" for a given key is specified to be // equivalent to calling remove on that key. 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); }......... } //清空长期汇合 mModified.clear(); ...... } } return new MemoryCommitResult(memoryStateGeneration, keysModified, listeners, mapToWriteToDisk); }- mModified就是咱们本次要更新增加的键值对汇合；
- mClear是咱们调用clear()办法的时候赋值的；
- 大抵流程就是：首先判断是否须要清空内存数据，而后循环mModified汇合，增加更新数据到内存的键值对汇合中；
6、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 { if (DEBUG) { Log.d(TAG, mFile.getName() + ":" + mcr.memoryStateGeneration + " committed after " + (System.currentTimeMillis() - startTime) + " ms"); } } //执行listener回调 notifyListeners(mcr); return mcr.writeToDiskResult; }- 首先apply没有返回值，commit有返回值；
- 其实apply执行回调是和数据写入磁盘并行执行的，而commit办法执行回调是期待磁盘写入数据实现之后；
二、QueuedWork详解
1、QueuedWork
QueuedWork这个类，因为sp的初始化之后就是应用，后面看到，无论是apply还是commit办法都是通过QueuedWork来实现的；
QueuedWork是一个治理类，顾名思义，其中有一个队列，对所有入队的work进行治理调度；
其中最重要的就是有一个HandlerThread
private static Handler getHandler() { synchronized (sLock) { if (sHandler == null) { HandlerThread handlerThread = new HandlerThread("queued-work-looper", Process.THREAD_PRIORITY_FOREGROUND); handlerThread.start(); sHandler = new QueuedWorkHandler(handlerThread.getLooper()); } return sHandler; } }2、入队queue
// 如果是commit，则不能delay，如果是apply，则能够delay public static void queue(Runnable work, boolean shouldDelay) { Handler handler = getHandler(); synchronized (sLock) { sWork.add(work); if (shouldDelay && sCanDelay) { // 默认delay的工夫是100ms handler.sendEmptyMessageDelayed(QueuedWorkHandler.MSG_RUN, DELAY); } else { handler.sendEmptyMessage(QueuedWorkHandler.MSG_RUN); } } }3、音讯的解决
private static class QueuedWorkHandler extends Handler { static final int MSG_RUN = 1; QueuedWorkHandler(Looper looper) { super(looper); } public void handleMessage(Message msg) { if (msg.what == MSG_RUN) { processPendingWork(); } } } private static void processPendingWork() { synchronized (sProcessingWork) { LinkedList<Runnable> work; synchronized (sLock) { work = (LinkedList<Runnable>) sWork.clone(); sWork.clear(); getHandler().removeMessages(QueuedWorkHandler.MSG_RUN); } if (work.size() > 0) { for (Runnable w : work) { w.run(); } } } }- 能够看到，调度非常简单，外部有一个sWork，须要执行的时候遍历所有的runnable执行；
- 对于apply操作，会有肯定的提早再去执行work，然而对于commit操作，则会马上触发调度，而且并不仅仅是调度commit传过来的那个工作，而是马上就调度队列中所有的work；
4、waitToFinish
零碎中很多中央会期待sp的写入文件实现，期待形式是通过调用QueuedWork.waitToFinish();
public static void waitToFinish() { Handler handler = getHandler(); synchronized (sLock) { // 移除所有音讯，间接开始调度所有work if (handler.hasMessages(QueuedWorkHandler.MSG_RUN)) { handler.removeMessages(QueuedWorkHandler.MSG_RUN); } sCanDelay = false; } StrictMode.ThreadPolicy oldPolicy = StrictMode.allowThreadDiskWrites(); try { // 如果是waitToFinish调用过去，则马上执行所有的work processPendingWork(); } finally { StrictMode.setThreadPolicy(oldPolicy); } try { // 在所有的work执行结束之后，还须要执行Finisher // 后面在apply的时候有一步是QueuedWork.addFinisher(awaitCommit); // 其中的实现是期待sp文件的写入实现 // 如果没有通过msg去调度而是通过waitToFinish，则那个runnable就会在这里被执行 while (true) { Runnable finisher; synchronized (sLock) { finisher = sFinishers.poll(); } if (finisher == null) { break; } finisher.run(); } } finally { sCanDelay = true; } ... }零碎中对于四大组件的解决逻辑都在ActivityThread中实现，在service/activity的生命周期的执行中都会期待sp的写入实现，正是通过调用QueuedWork.waitToFinish()，确保app的数据正确的写入到disk；
5、sp应用的倡议
- 对数据实时性要求不高，尽量应用apply
- 如果业务要求必须数据胜利写入，应用commit
- 缩小sp操作频次，尽量一次commit把所有的数据都写入结束
- 能够适当思考不要在主线程拜访sp
写入sp的数据尽量轻量级
总结：
SharedPreferences的自身实现就是分为两步，一步是内存，一部是磁盘，而主线程又依赖SharedPreferences的写入，所以可能当io成为瓶颈的时候，App会因为SharedPreferences变的卡顿，重大状况下会ANR，总结下来有以下几点：
- 寄存在xml文件中的数据会被装在到内存中，所以获取数据很快
- apply是异步操作，提交数据到内存，并不会马上提交到磁盘
- commit是同步操作，会期待数据写入到磁盘，并返回后果
- 如果有同一个线程屡次commit，则前面的要期待后面执行完结
- 如果多个线程对同一个sp并发commit，前面的所有工作会进入到QueuedWork中排队执行，且都要等第一个执行结束