前言：
SharedPreferences很早就用过，但也只限于会用，隔了一段时间再用发现有点生疏，还是要去网上找用法，对其运行原理和不同方法间的区别也知之甚少，决定写一篇文章来总结一下，加深下印象和理解。
概述：
SharedPreferences是Android提供的几种常用的数据存储解决方案之一，应用可以通过它来访问和修改一些他们所关注的数据，常被用来存储少量的、格式简单的配置信息。其本质上是以键值（key-value）对的方式把用户设置信息存储在xml文件中的一种轻量级的数据存储方法。个人更愿意把它理解为是对文件数据存储方法的一个封装，开发者可以通过这个类更简便、更高效的去完成轻量级数据的存储。下面将围绕该存储方式所涉及到的两个主要类——SharedPreferences和SharedPreferencesImpl来逐步深入学习。
正文
SharedPreferences
从SharedPreferences的源码来看，SharedPreferences其实是一个接口类，里面定义了一系列对数据访问、修改和监听数据变化的方法。在数据访问方面，开发者可以通过其提供的getXXX方法来访问其存储的数据，通过contains方法来查询是否存储了你所关注的数据。在数据修改方面，SharedPreferences内部定义了一个内部类Editor，用来对数据进行添加（putXXX）、移除（remove，clear）、提交（commit，apply）等修改操作。SharedPreferences还提供了监听数据变化的监听器（OnSharedPreferenceChangeListener），开发者可以通过registerOnSharedPreferenceChangeListener方法来注册监听器，时刻关注感兴趣数据的变化，当不再需要监听时，可以通过unregisterOnSharedPreferenceChangeListener方法来注销监听器释放相关的资源。
SharedPreferencesImpl
SharedPreferencesImpl作为SharedPreferences的实现类，其内部结构大致跟SharedPreferences类差不多。下面对其内部源码进行逐一分解。
首先，来看一下SharedPreferencesImpl的构造方法：
SharedPreferencesImpl(File file, int mode) {
mFile = file;
mBackupFile = makeBackupFile(file);
mMode = mode;
mLoaded = false;
mMap = null;
startLoadFromDisk();
}
private void loadFromDisk() {
...
str = new BufferedInputStream(
new FileInputStream(mFile), 16*1024);
map = XmlUtils.readMapXml(str);
...
}
在SharedPreferencesImpl的构造方法中一共要传递两个参数，file和mode。其中，file是SharedPreferences用来存储数据的文件，mode决定了可以对这个file文件所做的操作。SharedPreferencesImpl首先会对file文件进行一个备份和相关的一些初始化，在构造函数的最后从传递过来的xml文件中读取数据并存储到内部的HashMap以便后续的操作。这里我们能很直观的看出SharedPreferences其本质就是对xml文件的操作，是对文件数据存储的一个封装。
其次，看一下SharedPreferencesImpl是如何实现读取数据的。以getString方法为例，可以看到getXXX方法的实现都比较简单，最外层是一个同步锁，内层awaitLoadedLocked相当于一个线程锁，如果数据加载没有完成就会一直死循环等待加载完成，通过这两个锁来保证数据读取的线程安全和准确性。这两个锁都顺利执行完就会从之前加载好的HashMap里面读取出对应key的值，如果值为空则返回之前约定的缺省值。
@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() {
if (!mLoaded) {
// Raise an explicit StrictMode onReadFromDisk for this
// thread, since the real read will be in a different
// thread and otherwise ignored by StrictMode.
BlockGuard.getThreadPolicy().onReadFromDisk();
}
while (!mLoaded) {
try {
mLock.wait();
} catch (InterruptedException unused) {
}
}
}
再次，看一下数据是如何修改的。与SharedPreferences代码结构类似，SharedPreferencesImpl内部也实现了一个Editor的实现类EditorImpl，用来提供相应的数据存储、修改和删除等操作。还是以putString方法为例，发现与getString相比，putString的实现更为简单，紧使用了一个同步锁来保证线程安全，如果校验没有被锁的情况下就会把数据直接写入HashMap中。
public Editor putString(String key, @Nullable String value) {
synchronized (mLock) {
mModified.put(key, value);
return this;
}
}
使用putXXX或是remove等方法操作的都是读取到HashMap中的数据，只有调用了EditorImpl中的apply或是commit方法才会真正的把值写入xml文件永久的保存。 接下来通过源码来分析一下这两个方法的区别。
public void apply() {
final long startTime = System.currentTimeMillis();
final MemoryCommitResult mcr = commitToMemory();
final Runnable awaitCommit = new Runnable() {
public void run() {
try {
mcr.writtenToDiskLatch.await();
} catch (InterruptedException ignored) {
}
if (DEBUG && mcr.wasWritten) {
Log.d(TAG, mFile.getName() + ":" + mcr.memoryStateGeneration
+ " applied after " + (System.currentTimeMillis() - startTime)
+ " ms");
}
}
};
QueuedWork.addFinisher(awaitCommit);
Runnable postWriteRunnable = new Runnable() {
public void run() {
awaitCommit.run();
QueuedWork.removeFinisher(awaitCommit);
}
};
SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);
// Okay to notify the listeners before it's hit disk
// because the listeners should always get the same
// SharedPreferences instance back, which has the
// changes reflected in memory.
notifyListeners(mcr);
}
public boolean commit() {
long startTime = 0;
if (DEBUG) {
startTime = System.currentTimeMillis();
}
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");
}
}
notifyListeners(mcr);
return mcr.writeToDiskResult;
}
从源码上看，可以明显的看出有两个不同点：
1、commit方法有返回值，而apply方法没有。
2、apply方法在执行 SharedPreferencesImpl的enqueueDiskWrite方法进行排队时多传递了一个Runnable（postWriteRunnable）参数，这个参数传与不传有什么区别呢，我们接着来看enqueueDiskWrite方法的实现。
/**
* Enqueue an already-committed-to-memory result to be written
* to disk.
*
* They will be written to disk one-at-a-time in the order
* that they're enqueued.
*
* @param postWriteRunnable if non-null, we're being called
* from apply() and this is the runnable to run after
* the write proceeds. if null (from a regular commit()),
* then we're allowed to do this disk write on the main
* thread (which in addition to reducing allocations and
* creating a background thread, this has the advantage that
* we catch them in userdebug StrictMode reports to convert
* them where possible to apply() ...)
*/
private void enqueueDiskWrite(final MemoryCommitResult mcr,
final Runnable postWriteRunnable) {
final boolean isFromSyncCommit = (postWriteRunnable == null);
final Runnable writeToDiskRunnable = new Runnable() {
public void run() {
synchronized (mWritingToDiskLock) {
writeToFile(mcr, isFromSyncCommit);
}
synchronized (mLock) {
mDiskWritesInFlight--;
}
if (postWriteRunnable != null) {
postWriteRunnable.run();
}
}
};
// Typical #commit() path with fewer allocations, doing a write on
// the current thread.
if (isFromSyncCommit) {
boolean wasEmpty = false;
synchronized (mLock) {
wasEmpty = mDiskWritesInFlight == 1;
}
if (wasEmpty) {
writeToDiskRunnable.run();
return;
}
}
QueuedWork.queue(writeToDiskRunnable, !isFromSyncCommit);
}
从enqueueDiskWrite源码可以看出，如果通过commit方法提交修改，postWriteRunnable 不为空，在执行enqueueDiskWrite方法时会直接执行writeToDiskRunnable把数据写入磁盘。而通过apply方法提交的修改请求，则会把writeToDiskRunnable加入到排队序列中顺序执行。
小结：
通过上面的分析，通过commit和apply两种方法提交数据修改有两点不同：
1、commit方法有返回值，而apply方法没有。使用commit方法能够明确的知道你的提交是否成功，而在不关心提交结果的情况下可以使用apply方法。
2、commit方法是同步的，apply方法是异步的。在多个commit方法并发执行的时候，他们会等待正在处理的commit方法保存到磁盘后再操作，降低了效率。而apply不关心提交是否成功，不必等待返回结果，他们只需要把提交写到内存然后异步的顺序执行，最后提交的磁盘。
在大多数情况下，我们对commit的成功与否并不感兴趣，而且在数据并发处理时基于上述原因使用commit要比apply效率低，所以推荐使用apply。
总结
本文通过解读Android 8.0源码分析了SharedPreferences是如何实现数据的读写操作以及两种提交修改方法的区别和优缺点。关于SharedPreferences的具体使用方法可以参考Android 浅析 SharedPreferences (一) 使用。
参考文献：
https://developer.android.google.cn/reference/android/content/SharedPreferences.html
http://androidxref.com/8.0.0_r4/xref/frameworks/base/core/java/android/content/SharedPreferences.java
http://androidxref.com/8.0.0_r4/xref/frameworks/base/core/java/android/app/SharedPreferencesImpl.java
