本篇將從源碼角度帶大家分析一下Android中常用的輕量級(jí)數(shù)據(jù)存儲(chǔ)工具SharedPreferences，以及SharedPreferences在多進(jìn)程下的一些坑。
閱讀本文大概需要5分鐘。
本文已授權(quán)微信公眾號(hào)：鴻洋（hongyangAndroid）原創(chuàng)首發(fā)。
SharedPreferences踩坑
在日常開發(fā)中SharedPreferences想必肯定是經(jīng)常被我們使用的了，通常情況下使用它并不會(huì)發(fā)生什么問(wèn)題，但是假如遇到了在不同進(jìn)程中使用SharedPreferences（例如指定了process的activity/service），那坑就來(lái)了。
這里我們可以實(shí)驗(yàn)一下，創(chuàng)建兩個(gè)Activity，在AndroidManifest其中一個(gè)將其process指定為second進(jìn)程
<activity android:name=".MainActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
<activity android:name=".SecondActivity"
android:process=":second"/>
public class MainActivity extends AppCompatActivity {
private TextView tvResult;
private EditText etInput;
private Button btnChange;
private Button btnJump;
private SharedPreferences sharedPreferences;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
sharedPreferences = PreferenceManager.getDefaultSharedPreferences(this);
setContentView(R.layout.activity_main);
tvResult = (TextView) findViewById(R.id.tv_result);
tvResult.setText(sharedPreferences.getString("test", "I am default"));
etInput = (EditText) findViewById(R.id.et_input);
btnChange = (Button) findViewById(R.id.btn_change);
btnChange.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
sharedPreferences.edit().putString("test", etInput.getText().toString()).commit();
tvResult.setText(sharedPreferences.getString("test", "I am default"));
}
});
btnJump = (Button) findViewById(R.id.btn_jump);
btnJump.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
startActivity(new Intent(MainActivity.this, SecondActivity.class));
}
});
}
}
代碼比較簡(jiǎn)單，就是將輸入框的內(nèi)容存入到SharedPreferences中，并顯示到TextView上，點(diǎn)擊跳轉(zhuǎn)按鈕跳轉(zhuǎn)到SecondActivity
public class SecondActivity extends AppCompatActivity {
private TextView tvResult;
private Button btnGetResult;
private SharedPreferences sharedPreferences;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_second);
sharedPreferences = PreferenceManager.getDefaultSharedPreferences(this);
tvResult = (TextView) findViewById(R.id.tv_result);
btnGetResult = (Button) findViewById(R.id.btn_getResult);
btnGetResult.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
tvResult.setText(sharedPreferences.getString("test", "I am default"));
}
});
}
}
SecondActivity就是點(diǎn)擊按鈕獲取SharedPreferences的值并顯示到TextView，不過(guò)這里要注意它是運(yùn)行在不同的進(jìn)程中的。
這里我們將值改為hello，然后點(diǎn)擊修改，可以看到SharedPreferences的值已經(jīng)改成功了。然后我們跳轉(zhuǎn)到SecondActivity并獲取值，
一切正常，好現(xiàn)在我們回到MainActivity，并再次修改SharedPreferences中的值，
可以看到SharedPreferences的值已經(jīng)再次被修改成功，這時(shí)我們?cè)偬D(zhuǎn)到SecondActivity并獲取值，
不管怎么獲取都是之前的值，然后重啟app，再進(jìn)入SecondActivity，便又能獲取到正確的值了。
這里我們先總結(jié)一下結(jié)論
- 先啟動(dòng)主進(jìn)程并獲取SharedPreferences對(duì)象，然后啟動(dòng)其他進(jìn)程并獲取SharedPreferences對(duì)象，那么此時(shí)對(duì)SharedPreferences的數(shù)值進(jìn)行修改均不能對(duì)其他進(jìn)程產(chǎn)生作用。
- 先啟動(dòng)主進(jìn)程并獲取SharedPreferences對(duì)象，然后對(duì)值進(jìn)行修改，然后啟動(dòng)其他進(jìn)程并獲取SharedPreferences對(duì)象，能取得修改后的值，但此時(shí)如果再對(duì)此值進(jìn)行修改，均不能對(duì)其他進(jìn)程產(chǎn)生作用。
總結(jié)下來(lái)就是，其他進(jìn)程在啟動(dòng)時(shí)獲取到的SharedPreferences的值只能是這個(gè)進(jìn)程啟動(dòng)前這個(gè)值的最后值，即在進(jìn)程啟動(dòng)后對(duì)值的修改只對(duì)當(dāng)前進(jìn)程有效，須等到進(jìn)程重啟或者app重啟才能與其他進(jìn)程進(jìn)行“同步”。這里即使把獲取SharedPreferences對(duì)象的模式改為MODE_MULTI_PROCESS，或者系統(tǒng)版本是Android 3.0以下，也僅僅是在重新獲取SharedPreferences對(duì)象時(shí)能夠得到正確的值，即每次不同進(jìn)程間對(duì)SharedPreferences的值進(jìn)行修改，均需要重新獲取SharedPreferences對(duì)象才能夠使其正常。
那么為什么會(huì)這樣子呢，筆者帶大家從源碼的角度來(lái)分析一下，我們來(lái)看一下關(guān)于SharedPreferences的源碼
源碼分析
通常我們獲取SharedPreferences對(duì)象一般是這樣
SharedPreferences sharedPreferences = PreferenceManager.getDefaultSharedPreferences(this);
//或者這樣
SharedPreferences sharedPreferences = getSharedPreferences("name", Context.MODE_PRIVATE);
實(shí)際上PreferenceManager.getDefaultSharedPreferences(context)方法也是對(duì)getSharedPreferences做了封裝
public static SharedPreferences getDefaultSharedPreferences(Context context) {
return context.getSharedPreferences(getDefaultSharedPreferencesName(context),
getDefaultSharedPreferencesMode());
}
所以不管通過(guò)哪種方式，最終都是通過(guò)Context中的getSharedPreferences方法來(lái)獲取SharedPreferences對(duì)象，在Context中，getSharedPreferences方法是一個(gè)抽象方法，沒(méi)有具體實(shí)現(xiàn)。
public abstract SharedPreferences getSharedPreferences(String name, int mode);
我們知道Context的實(shí)現(xiàn)類其實(shí)就是ContextImpl，所以這里我們直接去到ContextImpl的getSharedPreferences方法中，
@Override
public SharedPreferences getSharedPreferences(String name, int mode) {
// 如果傳入null，將文件名給為"null"，即最后會(huì)是null.xml
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);
}
@Override
public File getSharedPreferencesPath(String name) {
return makeFilename(getPreferencesDir(), name + ".xml");
}
這里比較簡(jiǎn)單，先判斷了ArrayMap中是否存在該File對(duì)象，不存在則創(chuàng)建一個(gè)并放入ArrayMap，然后調(diào)用getSharedPreferences的重載方法getSharedPreferences(file, mode)，我們看一下這個(gè)方法的源碼
@Override
public SharedPreferences getSharedPreferences(File file, int mode) {
checkMode(mode);
SharedPreferencesImpl sp;
synchronized (ContextImpl.class) {
//查看緩存中是否存在SharedPreferencesImpl對(duì)象，若存在直接返回
final ArrayMap<File, SharedPreferencesImpl> cache = getSharedPreferencesCacheLocked();
sp = cache.get(file);
if (sp == null) {
sp = new SharedPreferencesImpl(file, mode);
cache.put(file, sp);
return sp;
}
}
//若Android版本小于3.0或者mode為MODE_MULTI_PROCESS，則調(diào)用startReloadIfChangedUnexpectedly方法重新讀取磁盤文件
if ((mode & Context.MODE_MULTI_PROCESS) != 0 ||
getApplicationInfo().targetSdkVersion < android.os.Build.VERSION_CODES.HONEYCOMB) {
sp.startReloadIfChangedUnexpectedly();
}
return sp;
}
private ArrayMap<File, SharedPreferencesImpl> getSharedPreferencesCacheLocked() {
//以包名為key進(jìn)行緩存ArrayMap，存在則直接return
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;
}
private void checkMode(int mode) {
//在Android 7.0以上若允許外部讀寫將直接拋出異常
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");
}
}
}
可以看到，這里將SharedPreferences的實(shí)例對(duì)象SharedPreferencesImpl緩存起來(lái)，以后每次獲取如果內(nèi)存中已經(jīng)存在那么直接返回，如果不存在才會(huì)進(jìn)行重新創(chuàng)建，那么這里我們可以有個(gè)猜想，即是否只有在創(chuàng)建SharedPreferences對(duì)象的時(shí)候才會(huì)從磁盤中進(jìn)行讀取，讀取后的值保存在了內(nèi)存中，獲取SharedPreferences對(duì)象優(yōu)先從緩存中獲取，再次創(chuàng)建時(shí)才會(huì)重新從磁盤中再次讀取文件。
我們直接看一下SharedPreferencesImpl的源碼，驗(yàn)證一下我們的猜想。
//SharedPreferencesImpl的構(gòu)造方法
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() {
loadFromDisk();
}
}.start();
}
可以看到，在SharedPreferencesImpl的構(gòu)造方法中調(diào)用了startLoadFromDisk，startLoadFromDisk方法中開啟了一個(gè)線程加載磁盤中的文件，loadFromDisk源碼如下
private void loadFromDisk() {
//若已經(jīng)在加載，直接return
synchronized (SharedPreferencesImpl.this) {
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);
//使用XmlUtils將xml文件讀取后轉(zhuǎn)成一個(gè)map對(duì)象
map = XmlUtils.readMapXml(str);
} catch (XmlPullParserException | IOException e) {
Log.w(TAG, "getSharedPreferences", e);
} finally {
IoUtils.closeQuietly(str);
}
}
} catch (ErrnoException e) {
/* ignore */
}
synchronized (SharedPreferencesImpl.this) {
//加載完成，狀態(tài)更新
mLoaded = true;
if (map != null) {
//將map對(duì)象賦值給成員變量mMap
mMap = map;
mStatTimestamp = stat.st_mtime;
mStatSize = stat.st_size;
} else {
mMap = new HashMap<>();
}
notifyAll();
}
}
看到這里，已經(jīng)逐步驗(yàn)證了我們之前的猜想，在構(gòu)造方法中讀取了磁盤文件的內(nèi)容并賦值給了成員變量mMap集合，我們只需要看看所有的get方法是不是從mMap成員變量中獲取值就能完全驗(yàn)證我們的猜想是否正確，因?yàn)間et方法都大同小異，所以我們就只分析一下getString方法就可以了。
@Nullable
public String getString(String key, @Nullable String defValue) {
synchronized (this) {
//這個(gè)方法只要判斷是否加載xml文件完畢，防止加載未完成就調(diào)用了getString方法
awaitLoadedLocked();
String v = (String)mMap.get(key);
return v != null ? v : defValue;
}
}
可以看到，果然是這樣的，從mMap集合中直接取出值進(jìn)行返回，那么看到這里肯定會(huì)有個(gè)疑問(wèn)，為什么在同個(gè)進(jìn)程卻又沒(méi)有問(wèn)題呢，或者其他進(jìn)程對(duì)SharedPreferences的獲取在值修改完畢之后也沒(méi)有問(wèn)題，這里我們看一下SharedPreferencesImpl的內(nèi)部類EditorImpl的源碼，EditorImpl是Editor的實(shí)現(xiàn)類。
public final class EditorImpl implements Editor {
private final Map<String, Object> mModified = Maps.newHashMap();
private boolean mClear = false;
public Editor putString(String key, @Nullable String value) {
synchronized (this) {
mModified.put(key, value);
return this;
}
}
...
public void apply() {
final MemoryCommitResult mcr = commitToMemory();
final Runnable awaitCommit = new Runnable() {
public void run() {
try {
mcr.writtenToDiskLatch.await();
} catch (InterruptedException ignored) {
}
}
};
QueuedWork.add(awaitCommit);
Runnable postWriteRunnable = new Runnable() {
public void run() {
awaitCommit.run();
QueuedWork.remove(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() {
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;
}
...
可以看到，EditorImpl內(nèi)部有一個(gè)mModified的Map成員變量，我們所有的修改在調(diào)用了commit或者apply方法后才會(huì)執(zhí)行保存，可以看到，不管調(diào)用哪個(gè)方法都會(huì)調(diào)用commitToMemory()和enqueueDiskWrite方法，那么我們看一下這兩個(gè)方法的源碼
private MemoryCommitResult commitToMemory() {
MemoryCommitResult mcr = new MemoryCommitResult();
synchronized (SharedPreferencesImpl.this) {
if (mDiskWritesInFlight > 0) {
//對(duì)mMap進(jìn)行擴(kuò)容
mMap = new HashMap<String, Object>(mMap);
}
mcr.mapToWriteToDisk = mMap;
mDiskWritesInFlight++;
//判斷是否有注冊(cè)監(jiān)聽者
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()) {
//將值添加到SharedPreferences的成員變量mMap中去
String k = e.getKey();
Object v = e.getValue();
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;
}
其實(shí)通過(guò)方法名我們也可以猜到，就是將值提交到內(nèi)存，從代碼上也可以看出來(lái)，就是將Editor的所有put進(jìn)去的值添加到SharedPreferences的mMap成員變量中。
那么最后將內(nèi)容寫入磁盤的方法就是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);
}
源碼比較簡(jiǎn)單，其中最主要的就是區(qū)分了apply方法調(diào)用和commit的調(diào)用,apply調(diào)用的話會(huì)將寫入磁盤的任務(wù)加入到一個(gè)線程池中在后臺(tái)運(yùn)行，直接commit的話則會(huì)在當(dāng)前線程進(jìn)行寫入。
總結(jié)
整個(gè)獲取SharedPreferences對(duì)象過(guò)程的流程圖如下
Android的SharedPreferences采用了這種模式，主要還是為了防止頻繁通過(guò)IO讀取磁盤帶來(lái)的性能開銷，畢竟SharedPreferences還是比較常用的，如果實(shí)時(shí)去磁盤文件進(jìn)行讀取，那么在性能上肯定有不容忽視的影響。同時(shí)，MODE_MULTI_PROCESS的模式也已經(jīng)被Google棄用，多進(jìn)程之間的數(shù)據(jù)共享Google不推薦我們使用SharedPreferences，而是使用例如ContentProvider這種方式。因?yàn)槎鄠€(gè)進(jìn)程同時(shí)對(duì)一個(gè)文件進(jìn)行修改，也有可能導(dǎo)致文件丟失等異常情況，同時(shí)，通過(guò)源碼我們發(fā)現(xiàn)，如果對(duì)存儲(chǔ)的成功與否的結(jié)果并不關(guān)心的話，使用apply方法進(jìn)行提交可以在性能上有一定的優(yōu)化，因?yàn)閍pply方法是在線程池進(jìn)行文件的寫入，而commit方法則是直接在當(dāng)前線程進(jìn)行文件的寫入的。
如果覺(jué)得對(duì)你有所幫助，請(qǐng)點(diǎn)個(gè)贊，謝謝。你的鼓勵(lì)是我最大的動(dòng)力。
歡迎關(guān)注EoniJJ的簡(jiǎn)書
不定期與你分享關(guān)于Android開發(fā)的點(diǎn)點(diǎn)滴滴。
