SharedPreferences(下稱SP)在平時開發應用比較多。我應用SP主要用於儲存一些影響業務的數值，比如是否第一次啟用應用，第一次啟用的時間，ABTest分組標誌等等。在開發的應用中，很多與統計資料相關的數值都是用SP進行儲存管理的，使用過程中的確因為理解不深，出現問題，影響產品決策。因此準確理解使用SP很重要。
本文參照Android-26的原始碼，分析SP的原理和需要注意的問題，主要包括以下幾部分：
- 分析實現SP功能的類及相互關係
- SP的內容的讀取、寫入
- 需要注意的問題
SP的主要類及關係：
SP的功能實現的主要介面和類有：SharedPreferences，Editor，SharedPreferencesImpl，EditorImpl以及ContextImpl，它們之間的關係下圖(UML現學現賣，歡迎指出問題)：
介面SharedPreferences定義了SP提供SP檔案的讀操作,其包含子介面EditorImpl定義了對SP檔案寫相關的操作。SharedPreferencesImpl類實現SharedPreferences介面，具體實現SP檔案的讀功能以及為保證讀準確而提供的執行緒安全等條件，其內部類EditorImpl實現了Editor介面，負責SP檔案的實際寫操作。ContextImpl類包含SharedPreferencesImpl，通過方法getSharedPreferences()對外提供SP例項供開發者使用。
SP內容的讀寫：
- 獲取SP例項
@Override
public SharedPreferences getSharedPreferences(File file, int mode) {
//檢查讀寫模式
checkMode(mode);
//檔案級別加密檢查？（待進一步研究）
if (getApplicationInfo().targetSdkVersion >= android.os.Build.VERSION_CODES.O) {
if (isCredentialProtectedStorage()
&& !getSystemService(StorageManager.class).isUserKeyUnlocked(
UserHandle.myUserId())
&& !isBuggy()) {
throw new IllegalStateException("SharedPreferences in credential encrypted "
+ "storage are not available until after user is unlocked");
}
}
SharedPreferencesImpl sp;
synchronized (ContextImpl.class) {
final ArrayMap<File, SharedPreferencesImpl> cache = getSharedPreferencesCacheLocked();
sp = cache.get(file);
if (sp == null) {
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;
}
複製程式碼首先通過checkMode()方法檢查檔案的讀寫模式，然後針對Android O 及以上版本，進行檔案加密檢查，這些檢查都沒有問題後，從快取中獲取或者建立新的SP例項並返回。先看一下checkMode方法的實現：
private void checkMode(int mode) {
if (getApplicationInfo().targetSdkVersion >= Build.VERSION_CODES.N) {
if ((mode & MODE_WORLD_READABLE) != 0) {
throw new SecurityException("MODE_WORLD_READABLE no longer supported");
}
if ((mode & MODE_WORLD_WRITEABLE) != 0) {
throw new SecurityException("MODE_WORLD_WRITEABLE no longer supported");
}
}
}
複製程式碼為安全考慮，Android在N及以上徹底禁止MODE_WORLD_READABLE和MODE_WORLD_WRITEABLE模式，checkMode方法中具體做了限制。
synchronized (ContextImpl.class) {
final ArrayMap<File, SharedPreferencesImpl> cache = getSharedPreferencesCacheLocked();
sp = cache.get(file);
if (sp == null) {
sp = new SharedPreferencesImpl(file, mode);
cache.put(file, sp);
return sp;
}
}
複製程式碼這段程式碼是從快取中根據指定的File獲取SP例項，getSharedPreferencesCacheLocked()方法的實現如下：
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;
}
複製程式碼靜態變數sSharedPrefsCache的定義是一個Key為String型別，Value的ArrayMap<File, SharedPreferencesImpl>的ArrayMap:
/**
* Map from package name, to preference name, to cached preferences.
*/
private static ArrayMap<String, ArrayMap<File, SharedPreferencesImpl>> sSharedPrefsCache;
複製程式碼它以包名為key,將每個應用下的SP例項快取在一個ArrayMap中。 其實整個獲取SP例項的邏輯很簡單：從快取中查詢，將查詢到的物件直接返回，如果沒有就呼叫SharedPreferencesImpl的構造方法，建立SP例項，新增到快取中，並返回。
SP內容的讀寫：
先看一下SharedPreferencesImpl構造方法的實現：
SharedPreferencesImpl(File file, int mode) {
mFile = file;
mBackupFile = makeBackupFile(file);
mMode = mode;
mLoaded = false;
mMap = null;
startLoadFromDisk();
}
複製程式碼構造方法主要進行了建立備份檔案例項，載入檔案到記憶體的操作，在startLoadFromDisk()方法中，通過同步枷鎖，啟動執行緒將檔案內容加入到記憶體，這裡提供了一層執行緒安全保障：
private void startLoadFromDisk() {
synchronized (mLock) {
mLoaded = false;
}
new Thread("SharedPreferencesImpl-load") {
public void run() {
loadFromDisk();
}
}.start();
}
複製程式碼具體負責檔案內容載入的loadFromDisk()方法：
rivate 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 = 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 = map;
mStatTimestamp = stat.st_mtime;
mStatSize = stat.st_size;
} else {
mMap = new HashMap<>();
}
mLock.notifyAll();
}
}
複製程式碼在這個方法中，首先是加鎖判斷當前狀態，如果已經載入完成，就直接返回，否則會重新設定備份的檔案物件。然後使用XmlUtils讀取檔案內容，並儲存到Map物件mMap中，通知所有正在等待的客戶，檔案讀取完成，可以進行鍵值對的讀寫操作了。這裡需要注意：系統會一次性把SP檔案內容讀入到記憶體並儲存在Map物件中。這就是SP檔案內容的載入過程。
下面我們看看從SP檔案中獲取值的過程，以getInt()方法為例：
public int getInt(String key, int defValue) {
synchronized (mLock) {
awaitLoadedLocked();
Integer v = (Integer)mMap.get(key);
return v != null ? v : defValue;
}
}
複製程式碼首先加鎖，避免讀取到錯誤的值，然後呼叫awaitLoadedLocked()，這個方法的作用是檢測檔案內容是否已經讀取到mMap物件中，如果沒有讀取完成，就阻塞，直到接收到讀取完成的通知之後，再從mMap物件中取出value，具體程式碼如下：
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) {
}
}
}
複製程式碼可以看到，如果檔案內容讀取完成，getInt()方法會一直阻塞。如果不知道這個細節，很容易導致應用出現ANR的問題。比如場景：程式建立的時候，會進行很多的邏輯處理，在UI程式從SP中獲取value時，如果檔案讀取時間長，UI程式被阻塞，容易發生ANR。另外由於系統是使用Map快取SP檔案中的鍵值對的，基本型別不能作為value傳入，所以想讀取基本型別的值時，要求傳入一個defaultValue，考慮到執行的安全，避免出現的情況是，客戶希望獲取一個int值，API返回一個Null的囧像。
SP的寫入操作是由EditorImpl具體實現的。對SP中鍵值對的讀寫操作，分兩步，第一步是由EditorImpl直接更改mMap的值；第二步，將mMap中的鍵值對寫入到檔案中儲存。這裡需要重點關注兩個方法：apply()和commit()，它們的實現如下：
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;
}
複製程式碼這兩個方法都做了兩件事情，呼叫commitToMemory()及時將改動提交到對應的記憶體區域，然後提交一個寫入檔案的任務，等待系統排程。唯一不同的是，apply將檔案寫入操作放到一個Runnable物件中，等待系統在工作執行緒中呼叫。commit方法則是直接在主執行緒中進行寫入操作。這一點可以從排程寫入操作的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--;
}
//使用本次寫入任務提供的Runnable物件
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);
}
複製程式碼如果在提交寫入任務時，沒有提供對應的排程Runnable物件，即此次排程任務是通過commit()方法提交，那麼會在當前的執行緒中進寫操作。這就是為什麼提倡使用apply方法的原因。其實大家根本不需要關注apply和commit兩個方法在資料一致性的差異，這兩個方法對資料的操作都是一致的，唯一區別就是寫入檔案時一個另起執行緒，一個在當前執行緒。
需要注意的問題：
- SP檔案的讀寫是一次I/O操作，儘量避開裝置資源緊張的場景操作。
- getValue方法是執行緒阻塞的
- apply方法對app效能的影響小，儘量使用apply方法。
- 儘量鏈式呼叫 Editor物件，因為每次呼叫SharedPreferencesImpl物件的edit()方法都會建立新的Editor例項
- 每個Editor例項包含一個map，包含該Editor例項操作的所有鍵值對。在呼叫apply或者commit方法之後會首先寫到mMap中。因此，不呼叫提交方法，那麼操作的鍵值對會被丟棄。