对于SharedPreferences使用大家肯定都很熟悉，毕竟使用非常的简单，但是使用的过程中应该注意什么问题，这对于大部分人来说可能就不太清楚了。
这里先说下需要注意的几点：
1、SharedPreferences一经加载，它内部存储的数据就会以Map的形式一直保存在内存中，所以，对于SharedPreferences的使用，应该要分清哪些数据是常用的，哪些是不常用的，常用的保存在一起，不常用的保存在一起；
2、获取SharedPreferences时，如果是初次加载，那么需要从文件中去加载数据，这是一个耗时操作，所以加载数据的这个过程是在子线程中完成的，但是，注意重点，当我们对SharedPreferences进行操作，而SharedPreferences加载数据又还没有结束，这时会导致线程等待，直到数据加载完后在开始操作数据，所以，对于要用到SharedPreferences，应该提前去获取，以确保使用时已经将数据加载完毕，这里说的是首次，如果加载过一次，那么之后的获取就是直接从内存中获取了；
3、保存数据时，apply（）是先将数据保存到内存中，然后在子线程中将数据保存到磁盘，commit（）也是先将数据保存到内存中，之后立即将数据同步到磁盘，这个操作是在当前线程中完成，所以会阻塞线程，所以现在android建议使用apply（），但是使用apply（）时也有需要注意的地方，如果保存数据时这个过程还没有结束，但是这时退出了activity，这时activity会先确保数据是否已经全部同步到磁盘了，如果没有，这时会两种情况，一是保存的过程正在子线中执行，这时等待就好，如果这时还没分发给子线程，那么就直接切换到主线程执行了，所以这时提交数据时也有需要注意的地方，使用SharedPreferences.Editor提交数据时，尽量在所有数据都提交后再调用apply（）方法；
现在在从源码中看是如何体现这几点的，先看SharedPreferences的获取：
SharedPreferences currentSP = context.getSharedPreferences(spName, Context.MODE_PRIVATE);这里context可能是Application的也可能是Activity的，但不管是谁的，它的实现都是ContextImpl，所以这里入口就是ContextImpl的getSharedPreferences（）了，在看源码之前，我们先思考一个问题：
Activity和Application的context获取是否有什么区别（答案是没区别，一样的）？
这里先看ContextImpl的getSharedPreferences（）方法：
public SharedPreferences getSharedPreferences(String name, int mode) {
// At least one application in the world actually passes in a null
// name. This happened to work because when we generated the file name
// we would stringify it to "null.xml". Nice.
if (mPackageInfo.getApplicationInfo().targetSdkVersion <
Build.VERSION_CODES.KITKAT) {
if (name == null) {
name = "null";
}
}
File file;
synchronized (ContextImpl.class) {
if (mSharedPrefsPaths == null) {
mSharedPrefsPaths = new ArrayMap<>();
}
file = mSharedPrefsPaths.get(name);
if (file == null) {
file = getSharedPreferencesPath(name);
mSharedPrefsPaths.put(name, file);
}
}
return getSharedPreferences(file, mode);
}方法还是挺简单的，这里主要做到了两个处理：
1、在api 19之前，如果name为null，那默认就将文件取名为null.xml，但是之后就会报NullPointerException；
2、这里先看下ArrayMap，它是Android中提供的，它的作用类似HashMap，但是在内存方面ArrayMap比HashMap更有效率，所以在android中推荐使用ArrayMap，这里使用的就是ArrayMap，他用于根据名字保存文件，这个文件就是保存内容的地方，接下来调用的就是getSharedPreferences(file, mode)，如果你不想使用默认保存文件的地方，那就可以使用这个方法；
接下来看getSharedPreferences(file, mode)：
public SharedPreferences getSharedPreferences(File file, int mode) {
SharedPreferencesImpl sp;
synchronized (ContextImpl.class) {
final ArrayMap<File, SharedPreferencesImpl> cache = getSharedPreferencesCacheLocked();
sp = cache.get(file);
if (sp == null) {
checkMode(mode);
if (getApplicationInfo().targetSdkVersion >= android.os.Build.VERSION_CODES.O) {
if (isCredentialProtectedStorage()
&& !getSystemService(UserManager.class)
.isUserUnlockingOrUnlocked(UserHandle.myUserId())) {
throw new IllegalStateException("SharedPreferences in credential encrypted "
+ "storage are not available until after user is unlocked");
}
}
sp = new SharedPreferencesImpl(file, mode);
cache.put(file, sp);
return sp;
}
}
if ((mode & Context.MODE_MULTI_PROCESS) != 0 ||
getApplicationInfo().targetSdkVersion < android.os.Build.VERSION_CODES.HONEYCOMB) {
// If somebody else (some other process) changed the prefs
// file behind our back, we reload it. This has been the
// historical (if undocumented) behavior.
sp.startReloadIfChangedUnexpectedly();
}
return sp;
}这个方法主要的逻辑就是先获取缓存，根据文件查看缓存中是否存在，如果存在就直接返回，如果不存在，那么就新建一个SharedPreferences，然后保存到缓存中，再返回，这里获取缓存使用的是getSharedPreferencesCacheLocked()，这里先去看下它的缓存是怎样设计的；
getSharedPreferencesCacheLocked()方法：
private static ArrayMap<String, ArrayMap<File, SharedPreferencesImpl>> sSharedPrefsCache;
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;
}这里用的也是ArrayMap，并且还是static的，这也就是说这个是一直保存在内存中的，这也就是为什么说在第一次加载后，在这之后就一直在内存中获取了，接下来就去看下初次加载是怎样的一个执行逻辑，对于初次加载，是创建sp = new SharedPreferencesImpl(file, mode)这样一个对象并返回，那我们就去看看它的构造方法到底做了些什么事情：
SharedPreferencesImpl(file, mode)的构造方法：
SharedPreferencesImpl(File file, int mode) {
mFile = file;
mBackupFile = makeBackupFile(file);
mMode = mode;
mLoaded = false;
mMap = null;
startLoadFromDisk();
}咋一看没什么啊，都是初始化一些变量，但这里有一个重点需要注意，那就是startLoadFromDisk（），看名字就知道是去磁盘中加载数据，也就是说只有在创建实例的时候才会去加载数据，前面的有说到，一旦创建一个实例后就会保存到缓存中，这也就是说只在第一次获取的时候才会去磁盘中加载数据；
接下来就去看看startLoadFromDisk（）方法：
private void startLoadFromDisk() {
synchronized (mLock) {
mLoaded = false;
}
new Thread("SharedPreferencesImpl-load") {
public void run() {
loadFromDisk();
}
}.start();
}没做什么操作，就是开了一个线程去执行loadFromDisk（），这也就是说加载数据是在子线程中执行的，接着往下看loadFromDisk（）：
private void loadFromDisk() {
synchronized (mLock) {
if (mLoaded) {
return;
}
if (mBackupFile.exists()) {
mFile.delete();
mBackupFile.renameTo(mFile);
}
}
// Debugging
if (mFile.exists() && !mFile.canRead()) {
Log.w(TAG, "Attempt to read preferences file " + mFile + " without permission");
}
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中
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;
if (map != null) {
// 真正保存数据的mMap，后面数据的保存和获取都会用到
mMap = map;
mStatTimestamp = stat.st_mtim;
mStatSize = stat.st_size;
} else {
mMap = new HashMap<>();
}
mLock.notifyAll();
}
}这里有一个mLock锁，这个锁很重要，这里获取到了锁，当SharedPreferences去操作数据的时候就会先去判断这个锁是否释放了，如果没有，那么就会等待锁释放了在执行，执行到就将数据加载到了内存中，最终保存在mMap中，那么接下来看他是怎样获取数据的，这里就看下它的getString（）方法：
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) {
}
}
}这里一进来就加了一个锁，这个锁是为了防止数据还没加载就执行到这里，那这时就需要将锁释放掉，但又不对数据进行操作，那这个awaitLoadedLocked（）就起到了这个作用，这也就是说，数据没加载完是不能对数据进行操作的，这时就阻塞在这里，到这，一开始说到的第一点和第二点就可以解释了，那么接下来就来看看数据是如何修改的；
对于数据的修改都是使用它的Editor（）方法，那就来看下这个方法：
public Editor edit() {
// TODO: remove the need to call awaitLoadedLocked() when
// requesting an editor. will require some work on the
// Editor, but then we should be able to do:
//
// context.getSharedPreferences(..).edit().putString(..).apply()
//
// ... all without blocking.
synchronized (mLock) {
awaitLoadedLocked();
}
return new EditorImpl();
}这里也是要等数据加载完才能对数据进行操作，但实际上对数据进行修改使用的是EditorImpl这个类，每调用一次这个方法就会新建一个EditorImpl实例，所以不要每修改一次就调用一次，可以尽量将所有需要修改的数据放一起进行操作，接下来看看这个类：
public final class EditorImpl implements Editor {
private final Object mLock = new Object();
@GuardedBy("mLock")
private final Map<String, Object> mModified = Maps.newHashMap();
@GuardedBy("mLock")
private boolean mClear = false;
public Editor putString(String key, @Nullable String value) {
synchronized (mLock) {
mModified.put(key, value);
return this;
}
}
public Editor putStringSet(String key, @Nullable Set<String> values) {
synchronized (mLock) {
mModified.put(key,
(values == null) ? null : new HashSet<String>(values));
return this;
}
}
public Editor putInt(String key, int value) {
synchronized (mLock) {
mModified.put(key, value);
return this;
}
}
public Editor putLong(String key, long value) {
synchronized (mLock) {
mModified.put(key, value);
return this;
}
}
public Editor putFloat(String key, float value) {
synchronized (mLock) {
mModified.put(key, value);
return this;
}
}
public Editor putBoolean(String key, boolean value) {
synchronized (mLock) {
mModified.put(key, value);
return this;
}
}
public Editor remove(String key) {
synchronized (mLock) {
mModified.put(key, this);
return this;
}
}
public Editor clear() {
synchronized (mLock) {
mClear = true;
return this;
}
}
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);
}
// Returns true if any changes were made
private MemoryCommitResult commitToMemory() {
long memoryStateGeneration;
List<String> keysModified = null;
Set<OnSharedPreferenceChangeListener> listeners = null;
Map<String, Object> mapToWriteToDisk;
synchronized (SharedPreferencesImpl.this.mLock) {
// We optimistically don't make a deep copy until
// a memory commit comes in when we're already
// writing to disk.
if (mDiskWritesInFlight > 0) {
// We can't modify our mMap as a currently
// in-flight write owns it. Clone it before
// modifying it.
// noinspection unchecked
mMap = new HashMap<String, Object>(mMap);
}
mapToWriteToDisk = mMap;
mDiskWritesInFlight++;
boolean hasListeners = mListeners.size() > 0;
if (hasListeners) {
keysModified = new ArrayList<String>();
listeners = new HashSet<OnSharedPreferenceChangeListener>(mListeners.keySet());
}
synchronized (mLock) {
boolean changesMade = false;
if (mClear) {
if (!mMap.isEmpty()) {
changesMade = true;
mMap.clear();
}
mClear = false;
}
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);
}
changesMade = true;
if (hasListeners) {
keysModified.add(k);
}
}
mModified.clear();
if (changesMade) {
mCurrentMemoryStateGeneration++;
}
memoryStateGeneration = mCurrentMemoryStateGeneration;
}
}
return new MemoryCommitResult(memoryStateGeneration, keysModified, listeners,
mapToWriteToDisk);
}
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;
}
private void notifyListeners(final MemoryCommitResult mcr) {
if (mcr.listeners == null || mcr.keysModified == null ||
mcr.keysModified.size() == 0) {
return;
}
if (Looper.myLooper() == Looper.getMainLooper()) {
for (int i = mcr.keysModified.size() - 1; i >= 0; i--) {
final String key = mcr.keysModified.get(i);
for (OnSharedPreferenceChangeListener listener : mcr.listeners) {
if (listener != null) {
listener.onSharedPreferenceChanged(SharedPreferencesImpl.this, key);
}
}
}
} else {
// Run this function on the main thread.
ActivityThread.sMainThreadHandler.post(new Runnable() {
public void run() {
notifyListeners(mcr);
}
});
}
}
}这里逻辑可以分为两点：
1、调用putXXX（）方法，将所有需要修改的数据先保存在一个临时的集合中；
2、调用apply（）或commit（）方法将临时集合中的数据合并到mMap集合中并同步到磁盘中；
再看apply（）方法前，这里先来看下commitToMemory（）方法：
private MemoryCommitResult commitToMemory() {
long memoryStateGeneration;
List<String> keysModified = null;
Set<OnSharedPreferenceChangeListener> listeners = null;
Map<String, Object> mapToWriteToDisk;
synchronized (SharedPreferencesImpl.this.mLock) {
// We optimistically don't make a deep copy until
// a memory commit comes in when we're already
// writing to disk.
if (mDiskWritesInFlight > 0) {
// We can't modify our mMap as a currently
// in-flight write owns it. Clone it before
// modifying it.
// noinspection unchecked
mMap = new HashMap<String, Object>(mMap);
}
// 将需要保存到磁盘中的数据保存到这个集合中
mapToWriteToDisk = mMap;
mDiskWritesInFlight++;
boolean hasListeners = mListeners.size() > 0;
if (hasListeners) {
keysModified = new ArrayList<String>();
listeners = new HashSet<OnSharedPreferenceChangeListener>(mListeners.keySet());
}
synchronized (mLock) {
boolean changesMade = false;
// 如果调用了clear(),那么就会将集合中原先的数据清除掉
if (mClear) {
if (!mMap.isEmpty()) {
changesMade = true;
mMap.clear();
}
mClear = false;
}
// 遍历存储在临时集合中的数据，然后合并到原先的数据集合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);
}
changesMade = true;
if (hasListeners) {
keysModified.add(k);
}
}
mModified.clear();
if (changesMade) {
mCurrentMemoryStateGeneration++;
}
memoryStateGeneration = mCurrentMemoryStateGeneration;
}
}
return new MemoryCommitResult(memoryStateGeneration, keysModified, listeners,
mapToWriteToDisk);
}这个方法主要做的就是将保存在临时集合中的数据合并到mMap（之前的数据集合）中，同时返回一个MemoryCommitResult对象，将数据保存到磁盘中用到的就是这个类；
接下来就该看看apply（）方法了：
public void apply() {
final long startTime = System.currentTimeMillis();
// 先将数据同步到内存中
final MemoryCommitResult mcr = commitToMemory();
final Runnable awaitCommit = new Runnable() {
public void run() {
try {
// writtenToDiskLatch是一个CountDownLatch对象，除非数据全部同步到磁盘，否则这里就一直阻塞
mcr.writtenToDiskLatch.await();
} catch (InterruptedException ignored) {
}
if (DEBUG && mcr.wasWritten) {
Log.d(TAG, mFile.getName() + ":" + mcr.memoryStateGeneration
+ " applied after " + (System.currentTimeMillis() - startTime)
+ " ms");
}
}
};
// 这里将awaitCommit添加到QueuedWork中的目的是为了退出activity时，确保所有数据已经全部同步到磁盘中了
QueuedWork.addFinisher(awaitCommit);
Runnable postWriteRunnable = new Runnable() {
public void run() {
awaitCommit.run();
// 数据同步完这里就会将awaitCommit从QueuedWork移除
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.
// 这里是唤醒回调，前提是你注册了registerOnSharedPreferenceChangeListener()回调
// 还有一个条件就是这个key是新添加的才会触发
notifyListeners(mcr);
}在这个方法中真正将数据同步到磁盘中是queueDiskWrite（），其中传了两个参数，第一个参数其内部保存的是需要同步的相关数据，第二个参数是为了确保退出activity时数据全部同步到了磁盘中，来看下这个方法的内部实现：
private void enqueueDiskWrite(final MemoryCommitResult mcr, final Runnable postWriteRunnable) {
// 注意这里的postWriterRunnable，如果是apply()方法，传进来的参数是不为null的，如果是commit(),
// 这里传进来的为null，isFromSyncCommit的值决定了是立即同步还是稍后再同步
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.
// 如果是commit(),那么就会执行到这里，在当前线程中同步数据
if (isFromSyncCommit) {
boolean wasEmpty = false;
synchronized (mLock) {
wasEmpty = mDiskWritesInFlight == 1;
}
if (wasEmpty) {
writeToDiskRunnable.run();
return;
}
}
// 如果是apply()，那么就会执行到这里，看来还得继续跟下去
QueuedWork.queue(writeToDiskRunnable, !isFromSyncCommit);
}这里会先判断是不是commit（）执行的，如果是commit（），那么就在当前线程中同步数据，这也就是为什么android现在不推荐使用这个方法了，如果是apply（）方法，那就还得往下看了，这里调用的是QueueWork这个类queue（），并将同步数据的任务传递进去，这里同步数据的工作就封装在writerDiskRunnable中，接下来看看queue（）里面是如何做的处理：
public static void queue(Runnable work, boolean shouldDelay) {
Handler handler = getHandler();
synchronized (sLock) {
sWork.add(work);
if (shouldDelay && sCanDelay) {
handler.sendEmptyMessageDelayed(QueuedWorkHandler.MSG_RUN, DELAY);
} else {
handler.sendEmptyMessage(QueuedWorkHandler.MSG_RUN);
}
}
}先获取到一个handler，然后将同步数据的任务添加到了sWork这个集合中，那后面处理肯定也是去这个集合里面拿了，根据上面的分析，这里的shouldDelay是为false的，所以执行的是下面这个方法，看来重点是这个handler了，那就去看看这个getHandler（）了：
private static Handler getHandler() {
synchronized (sLock) {
if (sHandler == null) {
// 这里使用HandlerThread是为了获取子线程的looper对象，handler中处理消息就是通过这个looper
HandlerThread handlerThread = new HandlerThread("queued-work-looper",
Process.THREAD_PRIORITY_FOREGROUND);
handlerThread.start();
sHandler = new QueuedWorkHandler(handlerThread.getLooper());
}
return sHandler;
}
}
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();
}
}
}这里就是构建一个handler，如果已经存在就直接返回了，不过这个handler处理消息是在子线程中执行的，要看明白这里，首先你得知道Handler和HadlerThread的原理，构建Handler在子线中处理消息时，一定要为他准备一个looper对象，否则是会有异常的，看这里的handleMessage()，将执行的逻辑交给了processPendingWork（），来看看：
private static void processPendingWork() {
long startTime = 0;
if (DEBUG) {
startTime = System.currentTimeMillis();
}
synchronized (sProcessingWork) {
LinkedList<Runnable> work;
synchronized (sLock) {
// 将前面添加的任务全部clone出来，然后清除
work = (LinkedList<Runnable>) sWork.clone();
sWork.clear();
// Remove all msg-s as all work will be processed now
// 将任务取出来后，就可以取消后面执行任务的消息了，这里取消的只是上面clone出来的任务
getHandler().removeMessages(QueuedWorkHandler.MSG_RUN);
}
// 这里就是开始将数据同步到内存中
if (work.size() > 0) {
for (Runnable w : work) {
w.run();
}
if (DEBUG) {
Log.d(LOG_TAG, "processing " + work.size() + " items took " +
+(System.currentTimeMillis() - startTime) + " ms");
}
}
}
}这里执行的逻辑就是将前面添加的数据clone出来作为局部变量，然后将clone的集合清空，再移除发送任务的消息（这个任务已经添加到集合中了），这样数据同步就在子线程中完成了。到这，主要的逻辑都捋了一遍，但是还有一个点，就是一开始说的第三点，退出activity时，数据没同步完是会阻塞线程的，现在就看看为什么会阻塞线程？这里要先知道一点，Activity生命周期都是通过ActivityThread来控制的，在ActivityThread的handleStopActivity方法中，这里控制的就是Activity的stop，在这个方法中有调用到：
QueuedWork.waitToFinish();这里就是查看QueuedWork中的任务是否都执行完了，如果没有执行完，那么就会处于等待状态，看下它里面是一个怎样的逻辑：
public static void waitToFinish() {
long startTime = System.currentTimeMillis();
boolean hadMessages = false;
Handler handler = getHandler();
// 先看下Handler中是否还有等待的消息，如果有那么就移除
synchronized (sLock) {
if (handler.hasMessages(QueuedWorkHandler.MSG_RUN)) {
// Delayed work will be processed at processPendingWork() below
handler.removeMessages(QueuedWorkHandler.MSG_RUN);
if (DEBUG) {
hadMessages = true;
Log.d(LOG_TAG, "waiting");
}
}
// We should not delay any work as this might delay the finishers
sCanDelay = false;
}
StrictMode.ThreadPolicy oldPolicy = StrictMode.allowThreadDiskWrites();
try {
// 这里就是将本该在子线程中执行的任务直接拿到主线程中来执行了
processPendingWork();
} finally {
StrictMode.setThreadPolicy(oldPolicy);
}
try {
// 这里是为了确保所有的任务确实已经执行完了
while (true) {
Runnable finisher;
synchronized (sLock) {
finisher = sFinishers.poll();
}
if (finisher == null) {
break;
}
finisher.run();
}
} finally {
sCanDelay = true;
}
synchronized (sLock) {
long waitTime = System.currentTimeMillis() - startTime;
if (waitTime > 0 || hadMessages) {
mWaitTimes.add(Long.valueOf(waitTime).intValue());
mNumWaits++;
if (DEBUG || mNumWaits % 1024 == 0 || waitTime > MAX_WAIT_TIME_MILLIS) {
mWaitTimes.log(LOG_TAG, "waited: ");
}
}
}
}这里会判断添加的任务是否全部执行完了，如果没有执行完，那么就会将本该在子线程中执行的任务全部移到主线程中来执行。
到这，才算是该注意的地方都分析到了，这里再把前面该注意的点说下：
1、SharedPreferences一经加载，它内部存储的数据就会以Map的形式一直保存在内存中，所以，对于SharedPreferences的使用，应该要分清哪些数据是常用的，哪些是不常用的，常用的保存在一起，不常用的保存在一起；
2、获取SharedPreferences时，如果是初次加载，那么需要从文件中去加载数据，这是一个耗时操作，所以加载数据的这个过程是在子线程中完成的，但是，注意重点，当我们对SharedPreferences进行操作，而SharedPreferences加载数据又还没有结束，这时会导致线程等待，直到数据加载完后在开始操作数据，所以，对于要用到SharedPreferences，应该提前去获取，以确保使用时已经将数据加载完毕，这里说的是首次，如果加载过一次，那么之后的获取就是直接从内存中获取了；
3、保存数据时，apply（）是先将数据保存到内存中，然后在子线程中将数据保存到磁盘，commit（）也是先将数据保存到内存中，之后立即将数据同步到磁盘，这个操作是在当前线程中完成，所以会阻塞线程，所以现在android建议使用apply（），但是使用apply（）时也有需要注意的地方，如果保存数据时这个过程还没有结束，但是这时退出了activity，这时activity会先确保数据是否已经全部同步到磁盘了，如果没有，这时会两种情况，一是保存的过程正在子线中执行，这时等待就好，如果这时还没分发给子线程，那么就直接切换到主线程执行了，所以这时提交数据时也有需要注意的地方，使用SharedPreferences.Editor提交数据时，尽量在所有数据都提交后再调用apply（）方法。