本文共 25762 字，大约阅读时间需要 85 分钟。
对于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 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 > sSharedPrefsCache; private ArrayMap getSharedPreferencesCacheLocked() { if (sSharedPrefsCache == null) { sSharedPrefsCache = new ArrayMap<>(); } final String packageName = getPackageName(); ArrayMap 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 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 values) { synchronized (mLock) { mModified.put(key, (values == null) ? null : new HashSet (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 keysModified = null; Set listeners = null; Map 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 (mMap); } mapToWriteToDisk = mMap; mDiskWritesInFlight++; boolean hasListeners = mListeners.size() > 0; if (hasListeners) { keysModified = new ArrayList (); listeners = new HashSet (mListeners.keySet()); } synchronized (mLock) { boolean changesMade = false; if (mClear) { if (!mMap.isEmpty()) { changesMade = true; mMap.clear(); } mClear = false; } for (Map.Entry 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 keysModified = null; Set listeners = null; Map 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 (mMap); } // 将需要保存到磁盘中的数据保存到这个集合中 mapToWriteToDisk = mMap; mDiskWritesInFlight++; boolean hasListeners = mListeners.size() > 0; if (hasListeners) { keysModified = new ArrayList (); listeners = new HashSet (mListeners.keySet()); } synchronized (mLock) { boolean changesMade = false; // 如果调用了clear(),那么就会将集合中原先的数据清除掉 if (mClear) { if (!mMap.isEmpty()) { changesMade = true; mMap.clear(); } mClear = false; } // 遍历存储在临时集合中的数据，然后合并到原先的数据集合mMap中 for (Map.Entry 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 work; synchronized (sLock) { // 将前面添加的任务全部clone出来，然后清除 work = (LinkedList ) 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（）方法。
转载地址：http://ckhai.baihongyu.com/