SP

❝

轻量级储存

以键值对（key-value）的方式保存数据的xml文件，其保存在/data/data/shared_prefs目录下

❞

项目中已迁移使用MMKV或者DataStore,为什么还热衷于SP的源码呢？

❝
有没有可能知道我不会MMKV或者DataStore源码呢，我想大概是的
TODO MMKV或者DataStore原理
❞

读操作

❝
当SharedPreferences对象第一次通过Context.getSharedPreferences()进行初始化时，对xml文件进行一次读取，并将文件内所有内容（即所有的键值对）缓到内存的一个Map中
❞

    final class SharedPreferencesImpl implements SharedPreferences {
     private final File mFile;             // 对应的xml文件
     private Map<String, Object> mMap;     // Map中缓存了xml文件中所有的键值对
}

备注：详细的过程，ANR部分再解析

写操作

❝
抽象出了一个Editor类，不管某次操作通过若干次调用putXXX()方法，更新了xml中的几个键值对，只有调用了commit()方法，最终才会真正写入文件
❞

commit 调用线程写操作

**commit 源码**：

   @Override
   public boolean commit() {
       ```
       MemoryCommitResult mcr = commitToMemory();//内存保存
       SharedPreferencesImpl.this.enqueueDiskWrite(mcr, null /* sync write on this thread okay */);//第二个参数为null
        ```
       return mcr.writeToDiskResult;
   }

可以看到enqueueDiskWrite的第二个参数为null

    private void enqueueDiskWrite(final MemoryCommitResult mcr,
                                      final Runnable postWriteRunnable) {
            final boolean isFromSyncCommit = (postWriteRunnable == null);//此时postWriteRunnable为null，isFromSyncCommit 则为true
    
            final Runnable writeToDiskRunnable = new Runnable() {
                    @Override
                    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) {  //当调用commit方法时，isFromSyncCommit则为true
                boolean wasEmpty = false;
                synchronized (mLock) {
                    wasEmpty = mDiskWritesInFlight == 1;
                }
                if (wasEmpty) {
                    writeToDiskRunnable.run();//主线程回调writeToDiskRunnable的run方法，进行writeToFile文件的存储
                    return;
                }
            }
    
            QueuedWork.queue(writeToDiskRunnable, !isFromSyncCommit);
        }

postWriteRunnable为null，则isFromSyncCommit为true，代码会在主线程回调writeToDiskRunnable的run方法，进行writeToFile文件的存储。这部分动作直接在主线程执行，如果文件较大，则主线程也会因为IO时间长造成ANR的。

apply 异步线程写操作

❝
apply()方法设计的初衷是为了规避主线程的I/O操作导致ANR问题的产生，那么ANR的问题真得到了有效的解决吗？
❞

「apply 源码」：

   public void apply() {
      ```
         final Runnable awaitCommit = new Runnable() {
                 public void run() {
                     try {
                         mcr.writtenToDiskLatch.await();
                     } catch (InterruptedException ignored) {
                     }
                     
             };
      // 将 awaitCommit 添加到队列 QueuedWork 中
         QueuedWork.addFinisher(awaitCommit);

         Runnable postWriteRunnable = new Runnable() {
                 public void run() {
                     awaitCommit.run();
                     QueuedWork.removeFinisher(awaitCommit);// 将 awaitCommit 从队列 QueuedWork 中移除
                 }
             };
         SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);
      ```
   }

apply方法最后调用了SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable)

enqueueDiskWrite方法会把存储文件的动作放到子线程,这个方法的第二个参数postWriteRunnable做了两件事：

让awaitCommit执行及执行 mcr.writtenToDiskLatch.await();
执行QueuedWork.remove(awaitCommit);

CountDownLatch

❝
writtenToDiskLatch的类型是CountDownLatch，CountDownLatch是一个同步工具类，通过一个计数器来实现的同步。当一个线程完成了自己的任务调用countDown()，则计数器的值就相应得减1。当计数器到达0时,表示所有的线程都已执行完毕,然后在等待的线程await()就可以恢复执行任务。
❞

countDown(): 对计数器进行递减1操作，当计数器递减至0时，当前线程会去唤醒阻塞队列里的所有线程。
await(): 阻塞当前线程，将当前线程加入阻塞队列。

可以看到如果postWriteRunnable方法被触发执行的话，由于 mcr.writtenToDiskLatch.await()的缘故，UI线程会被一直阻塞住，等待计数器减至0才能被唤醒。

enqueueDiskWrite源码如下所示：

    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);
        }

很明显postWriteRunnable不为null，程序会执行QueuedWork.queue(writeToDiskRunnable, !isFromSyncCommit);

writeToDiskRunnable:

writeToFile(): 内容存储到文件
postWriteRunnable.run()

QueuedWork.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);
                }
            }
        }
    
    
    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();
              }
          }
      }

就是把writeToDiskRunnable这个任务放到sWork这个list中，并且执行handler，根据HandlerThread的知识点，我们知道handlermessage里面就是子线程了。接下来我们继续看handleMessage里面的processPendingWork()方法：

     private static void processPendingWork() {
            long startTime = 0;
    
            if (DEBUG) {
                startTime = System.currentTimeMillis();
            }
    
            synchronized (sProcessingWork) {
                LinkedList<Runnable> work;
    
                synchronized (sLock) {
                    work = (LinkedList<Runnable>) sWork.clone();
                    sWork.clear();
    
                    // Remove all msg-s as all work will be processed now
                    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");
                    }
                }
            }
        }

是把sWork克隆给work，然后开启循环，执行work对象的run方法，及调用writeToDiskRunnable的run方法。上面讲过了，他里面做了两件事：

内容存储到文件
postWriteRunnable方法回调

执行run方法的代码：

     final Runnable writeToDiskRunnable = new Runnable() {
                   public void run() {
                       synchronized (mWritingToDiskLock) {
                           writeToFile(mcr, isFromSyncCommit);//由于handlermessage在子线程，则writeToFile也在子线程中
                       }
                       synchronized (mLock) {
                           mDiskWritesInFlight--;
                       }
                       if (postWriteRunnable != null) {
                           postWriteRunnable.run();
                       }
                   }
               };

writeToFile方法我们不深入去看，但是要关注，里面有个setDiskWriteResult方法，在该方法里面做了如下的事情：

      void setDiskWriteResult(boolean wasWritten, boolean result) {
                this.wasWritten = wasWritten;
                writeToDiskResult = result;
                writtenToDiskLatch.countDown();//计数器-1
            }

当调用countDown()方法时，会对计数器进行递减1操作，当计数器递减至0时，当前线程会去唤醒阻塞队列里的所有线程。

问题：子线程为什么要去执行postWriteRunnable呢？子线程为什么需要await? 也没有看到会出现ANR的情况

数据的更新

❝
xml文件中的数据会缓存到内存的mMap中，每次在调用editor.putXXX()时，实际上会将新的数据存入在mMap，当调用commit()或apply()时，最终会将mMap的所有数据全量更新到xml文件里。
❞

   @Override
   public SharedPreferences getSharedPreferences(String name, int mode) {
     // name参数就是文件名，通过不同文件名，获取指定的SharedPreferences对象
   }

线程安全 ^^3把锁^^

   final class SharedPreferencesImpl implements SharedPreferences {
     // 1、使用注释标记锁的顺序
     // Lock ordering rules:
     //  - acquire SharedPreferencesImpl.mLock before EditorImpl.mLock
     //  - acquire mWritingToDiskLock before EditorImpl.mLock
   
     // 2、通过注解标记持有的是哪把锁
     @GuardedBy("mLock")
     private Map<String, Object> mMap;
   
     @GuardedBy("mWritingToDiskLock")
     private long mDiskStateGeneration;
   
     public final class EditorImpl implements Editor {
       @GuardedBy("mEditorLock")
       private final Map<String, Object> mModified = new HashMap<>();
     }
   }

「第一把锁」对于简单的读操作而言，我们知道其原理是读取内存中mMap的值并返回，那么为了保证线程安全，只需要加一把锁保证mMap的线程安全即可：

    public String getString(String key, @Nullable String defValue) {
        synchronized (mLock) {
            String v = (String)mMap.get(key);
            return v != null ? v : defValue;
        }
    }

「保证写操作的线程安全」

❝
对于写操作而言，每次putXXX()并不能立即更新在mMap中 ,如果开发者没有调用apply()方法，那么这些数据的更新理所当然应该被抛弃掉，但是如果直接更新在mMap中，那么数据就难以恢复。
因此，Editor本身也应该持有一个mEditorMap对象，用于存储数据的更新；只有当调用apply()时，才尝试将mEditorMap与mMap进行合并，以达到数据更新的目的。
因此，这里我们还需要另外一把锁保证mEditorMap的线程安全，不和mMap公用同一把锁的原因是，在apply()被调用之前，getXXX和putXXX理应是没有冲突的。
❞

    public final class EditorImpl implements Editor {
      @Override
      public Editor putString(String key, String value) {
          synchronized (mEditorLock) {
              mEditorMap.put(key, value);
              return this;
          }
      }

❝
而当真正需要执行apply()进行写操作时，mEditorMap与mMap进行合并，这时必须通过2把锁保证mEditorMap与mMap的线程安全，保证mMap最终能够更新成功，最终向对应的xml文件中进行更新。
❞

「文件的更新理所当然也需要加一把锁：」

    // SharedPreferencesImpl.EditorImpl.enqueueDiskWrite()
    synchronized (mWritingToDiskLock) {
        writeToFile(mcr, isFromSyncCommit);
    }

文件损坏 & 备份机制

由于不可预知的原因（比如内核崩溃或者系统突然断电），xml文件的写操作异常中止，Android系统本身的文件系统虽然有很多保护措施，但依然会有数据丢失或者文件损坏的情况。

对文件进行备份，SharedPreferences的写入操作正式执行之前，首先会对文件进行备份，将初始文件重命名为增加了一个.bak后缀的备份文件：

    // 尝试写入文件
    private void writeToFile(...) {
      if (!backupFileExists) {
          !mFile.renameTo(mBackupFile);
      }
    }

尝试对文件进行写入操作，写入成功时，则将备份文件删除：

    // 写入成功，立即删除存在的备份文件
    // Writing was successful, delete the backup file if there is one.
    mBackupFile.delete();

若因异常情况（比如进程被杀）导致写入失败，进程再次启动后，若发现存在备份文件，则将备份文件重名为源文件，原本未完成写入的文件就直接丢弃：

   // 从磁盘初始化加载时执行
   private void loadFromDisk() {
       synchronized (mLock) {
           if (mBackupFile.exists()) {
               mFile.delete();
               mBackupFile.renameTo(mFile);
           }
       }
     }

通过文件备份机制，我们能够保证数据只会丢失最后的更新，而之前成功保存的数据依然能够有效。

进程不安全

没有使用跨进程的锁，SharedPreferences是进程不安全的，在跨进程频繁读写会有数据丢失的可能问题：这里如何解决？

ANR

写操作时ANR

❝
Android系统在页面切换前，将数据写入文件。在ActivityThread的handlePauseActivity和handleStopActivity时会通过waitToFinish保证这些异步任务都已经被执行完成。如果这个时候过渡使用apply方法，则可能导致onpause，onStop执行时间较长，从而导致ANR。
❞

   private void handlePauseActivity(IBinder token, boolean finished,
               boolean userLeaving, int configChanges, boolean dontReport, int seq) {
          ......
               r.activity.mConfigChangeFlags |= configChanges;
               performPauseActivity(token, finished, r.isPreHoneycomb(), "handlePauseActivity");
   
               // Make sure any pending writes are now committed.
               if (r.isPreHoneycomb()) {
                   QueuedWork.waitToFinish();
               }
              ......
       }

      public static void waitToFinish() {
             Handler handler = getHandler();
             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;
             }
     
            
         }

主线程执行processPendingWork（）方法，把之前未执行完的内容存储到文件的操作执行完，这部分动作直接在主线程执行，如果有未执行的文件操作并且文件较大，则主线程会因为IO时间长造成ANR。
循环取出sFinishers数组，执行他的run方法。如果这时候有多个异步线程或者异步线程时间过长，同样会造成阻塞产生ANR。

sFinishers数组是在什么时候add数据的？ sFinishers的addFinisher方法是在apply（）方法里面调用的，代码如下：

     @Override
     public void apply() {
         ......
           // 将 awaitCommit 添加到队列 QueuedWork 中
           QueuedWork.addFinisher(awaitCommit);
     
         Runnable postWriteRunnable = new Runnable() {
           @Override
           public void run() {
             awaitCommit.run();
             QueuedWork.removeFinisher(awaitCommit);// 将 awaitCommit 从队列 QueuedWork 中移除
           }
         };
         ......
      }

由于UI线程循环取出sFinishers数组，执行他的run方法造成阻塞产生ANR addFinisher刚刚上面提到是在apply方法中调用，入参awaitCommit，他的run方法如下：

        final Runnable awaitCommit = new Runnable() {
            @Override
            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");
              }
            }
        };

不难看出，就是调用CountDownLatch对象的await方法，阻塞当前线程，将当前线程加入阻塞队列。所以如果过渡使用apply方法，则可能导致onpause，onStop执行时间较长从而导致ANR。

首次读操作时ANR

❝
sp 文件创建以后，会单独的使用一个线程来加载解析对应的 sp 文件。但是当 UI 线程尝试访问 sp 中内容时，如果 sp 文件还未被完全加载解析到内存，此时 UI 线程会被 block，直到 SP 文件被完全加载到内存中为止
❞

sp 被创建的时候会同时启动一个线程加载对应的 sp 文件，执行 startLoadFromDisk(); 在 startLoadFromDisk()时，标记 sp 不可使用状态，后期无论是尝试读数据或者写数据，读写线程都会被 block，直到 sp 文件被全部加载解析完毕。

  源码
   @UnsupportedAppUsage
    SharedPreferencesImpl(File file, int mode) {
        mFile = file;
        mBackupFile = makeBackupFile(file);
        mMode = mode;
        mLoaded = false;
        mMap = null;
        mThrowable = null;
        startLoadFromDisk();
    }

    @UnsupportedAppUsage
    private void startLoadFromDisk() {
        synchronized (mLock) {
            mLoaded = false;
        }
        new Thread("SharedPreferencesImpl-load") {
            public void run() {
                loadFromDisk();
            }
        }.start();
    }

sp 文件完全加载解析到内存中，直接唤起所有在等待在当前 sp 的读写线程。

   private void loadFromDisk() {
        synchronized (mLock) {
           
        try {
            stat = Os.stat(mFile.getPath());
            if (mFile.canRead()) {
                BufferedInputStream str = null;
                try {
                    str = new BufferedInputStream(
                            new FileInputStream(mFile), 16 * 1024);
                    map = (Map<String, Object>) XmlUtils.readMapXml(str);
                } 
              }
        } 

        synchronized (mLock) {
            mLoaded = true;
            mLock.notifyAll();
            
        }
    }

当UI线程读取SP的值时，可能会发生ANR；

    @Override
    @Nullable
    public String getString(String key, @Nullable String defValue) {
        synchronized (mLock) {
            awaitLoadedLocked();
            String v = (String)mMap.get(key);
            return v != null ? v : defValue;
        }
    }

   @GuardedBy("mLock")
    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) {
            }
        }
        if (mThrowable != null) {
            throw new IllegalStateException(mThrowable);
        }
    }