SharePreferences原始碼分析（SharedPreferencesImpl）
#SharePreferences的基本使用
在Android提供的幾種資料儲存方式中SharePreference屬於輕量級的鍵值儲存方式，以XML檔案方式儲存資料，通常用來儲存一些使用者行為開關狀態等，一般的儲存一些常見的資料型別。
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
SharedPreferences sp=getSharedPreferences("data",MODE_PRIVATE);
SharedPreferences.Editor editor=sp.edit();
editor.putString("name","xjj");
editor.commit();
String s=sp.getString("name","");
}
}
然而，當我們對其實現原理有點興趣，用"Control+左鍵"點選看原始碼時，我們可以發現SharePreferences其實只是一個介面，如下：
public interface SharedPreferences {
Map<String, ?> getAll();
String getString(String var1, String var2);
Set<String> getStringSet(String var1, Set<String> var2);
int getInt(String var1, int var2);
long getLong(String var1, long var2);
float getFloat(String var1, float var2);
boolean getBoolean(String var1, boolean var2);
boolean contains(String var1);
SharedPreferences.Editor edit();
void registerOnSharedPreferenceChangeListener(SharedPreferences.OnSharedPreferenceChangeListener var1);
void unregisterOnSharedPreferenceChangeListener(SharedPreferences.OnSharedPreferenceChangeListener var1);
public interface Editor {
SharedPreferences.Editor putString(String var1, String var2);
SharedPreferences.Editor putStringSet(String var1, Set<String> var2);
SharedPreferences.Editor putInt(String var1, int var2);
SharedPreferences.Editor putLong(String var1, long var2);
SharedPreferences.Editor putFloat(String var1, float var2);
SharedPreferences.Editor putBoolean(String var1, boolean var2);
SharedPreferences.Editor remove(String var1);
SharedPreferences.Editor clear();
boolean commit();
void apply();
}
public interface OnSharedPreferenceChangeListener {
void onSharedPreferenceChanged(SharedPreferences var1, String var2);
}
}
當我們查閱一定的資料，很容易可以發現其實SharedPreferencesImpl才是SharePreferences原理實現的地方。
然而由於SharedPreferencesImpl不是public的類，所以我們無法直接在Android Studio中找到並檢視。
但是通過以下方法，我們可以把SharedPreferencesImpl類匯入Android Studio。
#匯入SharedPreferencesImpl原始碼
前往以下路徑可以找到SharedPreferencesImpl.java檔案，然後直接把檔案拖拽到Android Studio中就可以進行檢視了。
android-sdk\sources\android-21\android\app
#getSharedPreferences()
首先我們要從SharePreferences的獲取分析，我們一般使用getSharedPreferences()方法，檢視該方法後，程式碼如下：
@Override
public SharedPreferences getSharedPreferences(String name, int mode) {
return mBase.getSharedPreferences(name, mode);
}
public abstract SharedPreferences getSharedPreferences(String name,
int mode);
我們可以發現在Context中的getSharedPreferences（）並沒有具體實現，那是因為Context也僅僅是一個介面，它的具體實現是在ContextImpl中。
ContextImpl的匯入方法就不多說了，與SharedPreferencesImpl一樣，我們直接跳轉到ContextImpl中的getSharedPreferences（）方法：
private static ArrayMap<String, ArrayMap<String, SharedPreferencesImpl>> sSharedPrefs;
/*
此處省略很多程式碼
*/
@Override
public SharedPreferences getSharedPreferences(String name, int mode) {
SharedPreferencesImpl sp;
synchronized (ContextImpl.class) {
if (sSharedPrefs == null) {
sSharedPrefs = new ArrayMap<String, ArrayMap<String, SharedPreferencesImpl>>();
}
final String packageName = getPackageName();
ArrayMap<String, SharedPreferencesImpl> packagePrefs = sSharedPrefs.get(packageName);
if (packagePrefs == null) {
packagePrefs = new ArrayMap<String, SharedPreferencesImpl>();
sSharedPrefs.put(packageName, packagePrefs);
}
// 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";
}
}
sp = packagePrefs.get(name);
if (sp == null) {
File prefsFile = getSharedPrefsFile(name);
sp = new SharedPreferencesImpl(prefsFile, mode);
packagePrefs.put(name, 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;
}
我們可以看到getSharedPreferences通過ContextImpl保證同步操作，所以無論你在一個Context中執行多少次getSharedPreferences（）方法，他們也總是會排序執行，是執行緒安全的。
另外我們可以看到，SharedPreferencesImpl通過getSharedPrefsFile（）這個方法獲取路徑，於是對其進行檢視如下：
public File getSharedPrefsFile(String name) {
return makeFilename(getPreferencesDir(), name + ".xml");
}
private File getPreferencesDir() {
synchronized (mSync) {
if (mPreferencesDir == null) {
mPreferencesDir = new File(getDataDirFile(), "shared_prefs");
}
return mPreferencesDir;
}
}
於是我們可以知道我們使用SharePreferences時所儲存的路徑：
路徑=當前app的data目錄下的shared_prefs目錄+"/"+SharePreferences的name+“.xml”
根據如上程式碼又可以發現ContextImpl中有一個靜態的ArrayMap變數sSharedPrefs：
private static ArrayMap<String, ArrayMap<String, SharedPreferencesImpl>> sSharedPrefs;
因此無論有多少個ContextImpl物件例項，系統都共享這一個sSharedPrefs的Map，應用啟動以後首次使用SharePreference時建立，系統結束時才可能會被垃圾回收器回收，所以如果我們一個App中頻繁的使用不同檔名的SharedPreferences很多時這個Map就會很大，也即會佔用移動裝置寶貴的記憶體空間，所以說我們應用中應該儘可能少的使用不同檔名的SharedPreferences，減小記憶體使用。
#SharedPreferencesImpl的實現
知道了SharedPreferences是如何獲取的，我們就要開始思考SharedPreferencesImpl是如何實現的了。
主要為以下三個部分：
- SharedPreferencesImpl的構造
- 資料的get和put
- 資料的commit
##SharedPreferencesImpl的構造：
SharedPreferencesImpl(File file, int mode) {
mFile = file;
mBackupFile = makeBackupFile(file);
mMode = mode;
mLoaded = false;
mMap = null;
startLoadFromDisk();
}
private void startLoadFromDisk() {
synchronized (this) {
mLoaded = false;
}
new Thread("SharedPreferencesImpl-load") {
public void run() {
synchronized (SharedPreferencesImpl.this) {
loadFromDiskLocked();
}
}
}.start();
}
private void loadFromDiskLocked() {
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 (XmlPullParserException e) {
Log.w(TAG, "getSharedPreferences", e);
} catch (FileNotFoundException e) {
Log.w(TAG, "getSharedPreferences", e);
} catch (IOException e) {
Log.w(TAG, "getSharedPreferences", e);
} finally {
IoUtils.closeQuietly(str);
}
}
} catch (ErrnoException e) {
}
mLoaded = true;
if (map != null) {
mMap = map;
mStatTimestamp = stat.st_mtime;
mStatSize = stat.st_size;
} else {
mMap = new HashMap<String, Object>();
}
notifyAll();
}
我們可以看到此處新建了一個執行緒，根據我們輸入的地址查詢是否存在xml的檔案，如果可以找到，那就讓我這個SharedPreferencesImpl中的mMap等於這個xml中的map。
##資料的get和put:
###(此處就已getString和putString為例子)
private Map<String, Object> mMap; // guarded by 'this'
public String getString(String key, String defValue) {
synchronized (this) {
awaitLoadedLocked();
String v = (String)mMap.get(key);
return v != null ? v : defValue;
}
private final Map<String, Object> mModified = Maps.newHashMap();
public Editor putString(String key, String value) {
synchronized (this) {
mModified.put(key, value);
return this;
}
}
這裡要說一下，get和put使用的是物件的同步鎖，就是能保證一個物件在不同執行緒中進行操作是安全。
##Editor.commit()：
public boolean commit() {
MemoryCommitResult mcr = commitToMemory();
SharedPreferencesImpl.this.enqueueDiskWrite(
mcr, null /* sync write on this thread okay */);
try {
mcr.writtenToDiskLatch.await();
} catch (InterruptedException e) {
return false;
}
notifyListeners(mcr);
return mcr.writeToDiskResult;
}
進來後，我們發現第一個物件MemoryCommitResult我們就不瞭解，於是我們看一下它的程式碼：
// Return value from EditorImpl#commitToMemory()
private static class MemoryCommitResult {
public boolean changesMade; // any keys different?
public List<String> keysModified; // may be null
public Set<OnSharedPreferenceChangeListener> listeners; // may be null
public Map<?, ?> mapToWriteToDisk;
public final CountDownLatch writtenToDiskLatch = new CountDownLatch(1);
public volatile boolean writeToDiskResult = false;
public void setDiskWriteResult(boolean result) {
writeToDiskResult = result;
writtenToDiskLatch.countDown();
}
}
我們發現這個類其實很簡單，就是儲存了一些與EditorImpl有關的值。但是這些值到底是什麼呢？我們就要看一下這些值的獲取方式了，於是，我們跳轉到commitToMemory()方法中：
// Returns true if any changes were made
private MemoryCommitResult commitToMemory() {
MemoryCommitResult mcr = new MemoryCommitResult();
synchronized (SharedPreferencesImpl.this) {
// 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);
}
mcr.mapToWriteToDisk = mMap;
mDiskWritesInFlight++;
boolean hasListeners = mListeners.size() > 0;
if (hasListeners) {
mcr.keysModified = new ArrayList<String>();
mcr.listeners =
new HashSet<OnSharedPreferenceChangeListener>(mListeners.keySet());
}
synchronized (this) {
if (mClear) {
if (!mMap.isEmpty()) {
mcr.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);
}
mcr.changesMade = true;
if (hasListeners) {
mcr.keysModified.add(k);
}
}
mModified.clear();
}
}
return mcr;
}
首先我們要清楚兩個Map：
**mMap：**是SharedPreferencesImpl構造的時候從xml檔案中直接獲取到的HashMap。（如果檔案中沒有，mMap就為一個沒有資料的HashMap）
**mModified：**是Editor中臨時的用於存放提交資料的HashMap。
我們可以看到這裡的邏輯首先讓mcr.mapToWriteToDisk=mMap。
然後我們遍歷mModified中的物件（包括key與value兩個值），有三種情況：
1、如果value為null，並且mMap中包含這個物件，那麼就remove。
2、如果value不為null，並且mMap中包含這個物件，並且這個物件的value與原來檔案中的value相同。直接continue，跳過。
3、
如果value不為null，並且mMap中包含這個物件，並且這個物件的value與原來檔案中的value 不相同。
或者，如果value不為null，並且mMap中不包含這個物件。
這個時候，就需要把這個值加入到mMap中，也就是加入到mcr.mapToWriteToDisk中。
另外，這裡我們可以看到commit（）使用的鎖和SharedPreferencesImpl的構造是同一把，如下：
private void startLoadFromDisk() {
synchronized (this) {
mLoaded = false;
}
new Thread("SharedPreferencesImpl-load") {
public void run() {
synchronized (SharedPreferencesImpl.this) {
loadFromDiskLocked();
}
}
}.start();
}
private MemoryCommitResult commitToMemory() {
MemoryCommitResult mcr = new MemoryCommitResult();
synchronized (SharedPreferencesImpl.this) {
我們再回憶一下：
get的內容來自mMap，而mMap是構造的時候從檔案讀取的。
put的內容只有在commit之後，改變mMap的值，並且寫入檔案。
然後我們就可以開始後面寫入邏輯的分析了，進入enqueueDiskWrite()這個函式：
private void enqueueDiskWrite(final MemoryCommitResult mcr,
final Runnable postWriteRunnable) {
final Runnable writeToDiskRunnable = new Runnable() {
public void run() {
synchronized (mWritingToDiskLock) {
writeToFile(mcr);
}
synchronized (SharedPreferencesImpl.this) {
mDiskWritesInFlight--;
}
if (postWriteRunnable != null) {
postWriteRunnable.run();
}
}
};
final boolean isFromSyncCommit = (postWriteRunnable == null);
// Typical #commit() path with fewer allocations, doing a write on
// the current thread.
if (isFromSyncCommit) {
boolean wasEmpty = false;
synchronized (SharedPreferencesImpl.this) {
wasEmpty = mDiskWritesInFlight == 1;
}
if (wasEmpty) {
writeToDiskRunnable.run();
return;
}
}
QueuedWork.singleThreadExecutor().execute(writeToDiskRunnable);
}
分析一下，很容易知道主要邏輯就在writeToFile()這個函式中：
// Note: must hold mWritingToDiskLock
private void writeToFile(MemoryCommitResult mcr) {
// Rename the current file so it may be used as a backup during the next read
if (mFile.exists()) {
if (!mcr.changesMade) {
// If the file already exists, but no changes were
// made to the underlying map, it's wasteful to
// re-write the file. Return as if we wrote it
// out.
mcr.setDiskWriteResult(true);
return;
}
if (!mBackupFile.exists()) {
if (!mFile.renameTo(mBackupFile)) {
Log.e(TAG, "Couldn't rename file " + mFile
+ " to backup file " + mBackupFile);
mcr.setDiskWriteResult(false);
return;
}
} else {
mFile.delete();
}
}
// Attempt to write the file, delete the backup and return true as atomically as
// possible. If any exception occurs, delete the new file; next time we will restore
// from the backup.
try {
FileOutputStream str = createFileOutputStream(mFile);
if (str == null) {
mcr.setDiskWriteResult(false);
return;
}
XmlUtils.writeMapXml(mcr.mapToWriteToDisk, str);
FileUtils.sync(str);
str.close();
ContextImpl.setFilePermissionsFromMode(mFile.getPath(), mMode, 0);
try {
final StructStat stat = Os.stat(mFile.getPath());
synchronized (this) {
mStatTimestamp = stat.st_mtime;
mStatSize = stat.st_size;
}
} catch (ErrnoException e) {
// Do nothing
}
// Writing was successful, delete the backup file if there is one.
mBackupFile.delete();
mcr.setDiskWriteResult(true);
return;
} catch (XmlPullParserException e) {
Log.w(TAG, "writeToFile: Got exception:", e);
} catch (IOException e) {
Log.w(TAG, "writeToFile: Got exception:", e);
}
// Clean up an unsuccessfully written file
if (mFile.exists()) {
if (!mFile.delete()) {
Log.e(TAG, "Couldn't clean up partially-written file " + mFile);
}
}
mcr.setDiskWriteResult(false);
}
然後就很簡單了，首先先檢視原來的地址有沒有檔案存在，如果已經有了，那麼就刪除。然後把mcr.mapToWriteToDisk這個HashMap物件轉化為xml格式儲存到檔案放到改路徑下。
#總結
1、SharePreferences的xml檔案儲存路徑=當前app的data目錄下的shared_prefs目錄+SharePreferences的name+“.xml”
2、SharedPreferencesImpl構造中主要是建立mMap物件，會建立一個執行緒去檔案中查詢是否存在該xml，如果存在就把xml轉化為HashMap，讓mMap等於它。如果不存在，就讓mMap等於一個空的HashMap。
3、
SharedPreferencesImpl的構造，和commit中使用的是都是SharedPreferencesImpl.class的類的鎖，說明這個類建立的所有的物件，同一時間也只能有一個物件在初始化或者commit。
get的內容來自mMap，而mMap是構造的時候從檔案讀取的。
put的內容只有在commit之後，改變mMap的值，並且寫入檔案。
get和put都是使用的物件鎖。
4、Editor中建立了一個臨時的HashMap用於存放要提交的資料。
5、commit中會先獲取到mMap物件，然後遍歷Editor中臨時的用於存放資料的HashMap，發現有改變的資料，就放入mMap物件。同時也會刪除value為空的資料。
6、最後writeToFile（）中先會檢視原路徑是否有檔案存在，如果存在就刪除。然後把改變後的mMap物件轉化為xml格式寫入該路徑下的檔案。
#擴充
有讀者提出想了解一下apply（）與commit（）的區別，由於此篇文章已經發布，就不加長篇幅了。
兩者原理文章地址如下：
SharePreferences原始碼分析（commit與apply的區別以及原理）
相關文章
- SharePreferences原始碼分析（commit與apply的區別以及原理）原始碼MITAPP
- Retrofit原始碼分析三 原始碼分析原始碼
- 集合原始碼分析[2]-AbstractList 原始碼分析原始碼
- 集合原始碼分析[1]-Collection 原始碼分析原始碼
- 集合原始碼分析[3]-ArrayList 原始碼分析原始碼
- Guava 原始碼分析之 EventBus 原始碼分析Guava原始碼
- Android 原始碼分析之 AsyncTask 原始碼分析Android原始碼
- 【JDK原始碼分析系列】ArrayBlockingQueue原始碼分析JDK原始碼BloC
- 以太坊原始碼分析(36)ethdb原始碼分析原始碼
- 以太坊原始碼分析(38）event原始碼分析原始碼
- 以太坊原始碼分析(41）hashimoto原始碼分析原始碼
- 以太坊原始碼分析(43）node原始碼分析原始碼
- 以太坊原始碼分析(52）trie原始碼分析原始碼
- 深度 Mybatis 3 原始碼分析（一）SqlSessionFactoryBuilder原始碼分析MyBatis原始碼SQLSessionUI
- 以太坊原始碼分析(51）rpc原始碼分析原始碼RPC
- 【Android原始碼】Fragment 原始碼分析Android原始碼Fragment
- 【Android原始碼】Intent 原始碼分析Android原始碼Intent
- k8s client-go原始碼分析 informer原始碼分析(6)-Indexer原始碼分析K8SclientGo原始碼ORMIndex
- k8s client-go原始碼分析 informer原始碼分析(4)-DeltaFIFO原始碼分析K8SclientGo原始碼ORM
- 以太坊原始碼分析(20)core-bloombits原始碼分析原始碼OOM
- 以太坊原始碼分析(24)core-state原始碼分析原始碼
- 以太坊原始碼分析(29)core-vm原始碼分析原始碼
- 【MyBatis原始碼分析】select原始碼分析及小結MyBatis原始碼
- redis原始碼分析（二）、redis原始碼分析之sds字串Redis原始碼字串
- ArrayList 原始碼分析原始碼
- kubeproxy原始碼分析原始碼
- [原始碼分析]ArrayList原始碼
- redux原始碼分析Redux原始碼
- preact原始碼分析React原始碼
- Snackbar原始碼分析原始碼
- React原始碼分析React原始碼
- CAS原始碼分析原始碼
- Redux 原始碼分析Redux原始碼
- SDWebImage 原始碼分析Web原始碼
- Aspects原始碼分析原始碼
- httprouter 原始碼分析HTTP原始碼
- PowerManagerService原始碼分析原始碼
- HashSet原始碼分析原始碼