SharedPreferences真正实现的类是：SharedPreferencesImpl
构造函数中：
会创建出该XML的文件，以及一个bak的备份文件。并且调用startLoadFromDisk开启一个线程从本地文件中读取配置文件。
其中每个SharedPreferencesImpl中都会有一个mLoaded变量，它标志着是否已经从本地文件中读取过了。而对它进行同步的时候，都是通过SharedPreferencesImpl.this来上锁进行的。
在loadFromDiskLocked函数中：
- 检测.bak备份文件是否存在，如果存在的话，那么则将原来的文件删除，然后将.bak文件renameto正常文件，也就意味着，如果在写的时候，出问题了，导致中断了，就使用原来没问题的备份文件。
- 接着会通过Native检查文件是否存在，并且进行权限检查，看该文件是否可读
- 通过XmlUtils.readMapXml读取对应的XML文件，然后将数据放到Map中保存
- 读取完后，将mLoaded变量设置成true，标识已经读取完毕，并且调用notifyAll，让其他线程被唤醒
而在getString、getInt等函数中，都会调用:
public String getString(String key, String defValue) {
synchronized (this) {
awaitLoadedLocked();
String v = (String)mMap.get(key);
return v != null ? v : defValue;
}
}
首先调用awaitLoadedLocked方法，该函数体是一个while循环，一直等待mLoaded被设置成true，否则无论当前线程是否抛出了InterruptedException，都会一直处于wait状态。所以，如果SharedPreferences太大的话，读取的时间会越来越长，如果在主线程调用了getString等方法的话，会等待子线程把数据读取完之后才会返回值，建议不要让一个XML太大，可以分多个XML存储，这样不会有ANR的风险。
读取的过程比较简单，而写入的过程会非常复杂，因为需要考虑多线程，多进程，什么时候写入，同时写入等等非常规情况的处理。
等待读取完成后，创建出一个EditorImpl对象，该对象中只有一个HashMap用来保存变更的Key-Value，并且可以调用clear方法将mClear设置成true
调用apply方法
public void apply() {
final MemoryCommitResult mcr = commitToMemory();
final Runnable awaitCommit = new Runnable() {
public void run() {
try {
mcr.writtenToDiskLatch.await();
} catch (InterruptedException ignored) {
}
}
};
QueuedWork.add(awaitCommit);
Runnable postWriteRunnable = new Runnable() {
public void run() {
awaitCommit.run();
QueuedWork.remove(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);
}
从apply函数中可以看到：
调用commitToMemory方法
a) 创建一个MemoryCommitResult对象
b) 判断mDiskWritesInFlight是否大于0，如果大于0的话，说明之前已经有正在往磁盘里写的任务了，那么则将改变的值copy到一个新的Map中
c) 将map放入MemoryCommitResult，并且将mDiskWritesInFlight加1
d) 判断当前SharedPreferences是否已经注册过Listener，如果注册过的话，那么将Listener放到MemoryCommitResult中，以便后续的回调使用
e) 判断mClear是否被设置，如果被设置的话，那么就会将当前SharedPreferencesImpl中的Map清空，并将结果的changesMade设置成true，标识在内存中值已经发生改变
f) 遍历改变的Map对象，判断要改变的值与当前值是否相同，不同的话，则改变当前值。并将结果的changesMade设置成true，标识在内存中值已经发生改变
g) 判断是否有Listener，如果有，则将有改变的Key添加到MemoryCommitResult中的keysModified这个Set中，最后将EditorImpl中的Map给清空获取到了内存改变的值之后，会创建awaitCommit以及postWriteRunnable两个Runnable:
awaitCommit：该Runnable中执行CountDownlaunch的await方法进行等待，并且会被添加到QueueWork中
postWriteRunnable：该Runnable执行awaitCommit的run方法，并且将awaitCommit从QueueWork中移除调用enqueueDiskWrite方法，开始往写磁盘队列中插入。
a) 创建一个writeToDiskRunnable对象，该Runnable中完成将MemoryCommitResult写入文件的操作
b) 判断postWriteRunnable是否为空，该判断主要是用来判断当前的操作是commit还是apply，因为commit的话，是一个同步操作，需要等待写完磁盘之后，才能继续往下运行，而apply是个异步操作，当异步写完磁盘之后，会调用postWriteRunnable.run方法。
c) 如果是调用commit的话，则判断mDiskWritesInFlight是否为1，如果为1的话，那么就说明当前没有写磁盘任务，那么就直接调用writeToDiskRunnable.run方法，执行完之后返回，否则将写入文件的操作放到一个单线程池中慢慢执行。
在writeToFile中，会将每一个MemoryCommitResult都写到文件中
- 判断XML文件是否存在，如果存在的话，那么判断当前内存值是否有改变，如果没有改变的话，就调用setDiskWriteResult方法，将之前的CountDownLaunch减一，让原来等待的线程处于就绪状态，并且将写入成功的标志位设置成true，标识写入成功
- 判断.bak文件是否存在，如果不存在的话，那么则将xml文件renameTo备份文件，如果备份失败的话，那么则标记写入失败，返回。如果bak文件存在的话，那么则将原来的XML文件删除
- 得到XML对应的FileOutputStream，如果获取失败的话（如无权限，创建文件失败等等），则标记写入失败并且返回
- 将完整的Map对象写入XML中，并且调用FileUtils.sync进行文件同步，同步完之后，关闭输出流，并且设置文件权限
- 写入成功后，删除.bak文件，并且标记写入文件成功，并且返回，如果写文件过程中遇到异常，则直接将XML文件删除，并且标记写入失败。
在写完文件之后，将mDiskWritesInFlight减一，并且判断postWriteRunnable是否存在，如果有的话，则执行postWriteRunnable。
最后没有搞明白为什么要有个CountDownLaunch，因为CountDownLaunch.await是在最后被执行的，而那时候早就已经调用了CountDownLaunch.countdown了，所以貌似没什么用。
