提起SharedPreferences
鹿榜,應(yīng)該所有的開(kāi)發(fā)者都覺(jué)得很簡(jiǎn)單吧,會(huì)不會(huì)想:這個(gè)有啥好說(shuō)的曹傀,還寫(xiě)博客?是不是裝X八峭稹皆愉?
其實(shí)我也覺(jué)得SharedPreferences
很簡(jiǎn)單,除非你要用它實(shí)現(xiàn)多進(jìn)程之間的數(shù)據(jù)共享艇抠。說(shuō)到多進(jìn)程之間使用SharedPreferences
幕庐,會(huì)不會(huì)有人想說(shuō):創(chuàng)建它的時(shí)候不是有個(gè)參數(shù)Context.MODE_MULTI_PROCESS
,這不是android官方提供的多進(jìn)程支持嗎练链?呵呵翔脱,少年,too young too simple懊焦摹!
Note: currently this class does not support use across multiple processes. This will be added later.
MODE_MULTI_PROCESS does not work reliably in some versions of Android, and furthermore does not provide any mechanism for reconciling concurrent modifications across processes. Applications should not attempt to use it. Instead, they should use an explicit cross-process data management approach such asContentProvider.
以上摘自android官方文檔SharedPreferences和Context介紹部分
拋開(kāi)多進(jìn)程之間使用错妖,在自己的App中使用SharedPreferences
還是很簡(jiǎn)單的绿鸣。當(dāng)然這篇文章我不是說(shuō)開(kāi)發(fā)中如何使用它,而是記錄自己在優(yōu)化我們的App啟動(dòng)過(guò)程中發(fā)現(xiàn)的一些問(wèn)題--SharedPreferences
導(dǎo)致的問(wèn)題暂氯。
進(jìn)入正題
引子
SharedPreferences
是Android SDK提供的工具潮模,可以存儲(chǔ)應(yīng)用的一些配置信息,這些信息會(huì)以鍵值對(duì)的形式保存在/sdcard/data/data/packageName/shared_prefs/
路徑下的一個(gè)xml
文件中痴施。它提供了多種數(shù)據(jù)類型的存儲(chǔ)擎厢,包括:int
、long
辣吃、boolean
动遭、float
、String
以及Set<String>
神得。
我真正想記錄的
獲取SharedPreferences
的實(shí)例一般會(huì)有兩種方式:
context.getSharedPreference(name, mode);
-
PreferenceManager.getDefaultSharedPreferences(context);
這兩種方式其實(shí)具體實(shí)現(xiàn)是一樣的厘惦,只不過(guò)一個(gè)是開(kāi)發(fā)者自己定義名字,另一個(gè)是使用包名+"_preference"作為存儲(chǔ)文件名哩簿。
getSharedPreference(name, mode)
public SharedPreferences getSharedPreferences(String name, int mode) {
return mBase.getSharedPreferences(name, mode);
}
PreferenceManager.getDefaultSharedPreferences(context)
public static SharedPreferences getDefaultSharedPreferences(Context context) {
return
context.getSharedPreferences(getDefaultSharedPreferencesName(context),
getDefaultSharedPreferencesMode());
}
private static String getDefaultSharedPreferencesName(Context context) {
return context.getPackageName() + "_preferences";
}
private static int getDefaultSharedPreferencesMode() {
return Context.MODE_PRIVATE;
}
我們的App中充斥著大量的PreferenceManager.getDefaultSharedPreferences(context)
使用方式宵蕉,可能是大家覺(jué)得方便,又是API級(jí)的Manager管理节榜,所以使用起來(lái)很放心羡玛,然而這也正是問(wèn)題的根本所在。問(wèn)題在哪里呢宗苍?接下來(lái)便告訴你稼稿。
因?yàn)樵谧鯝pp的優(yōu)化薄榛,自然少不了使用MethodTrace,在分析啟動(dòng)流程時(shí)發(fā)現(xiàn)一個(gè)很詭異的點(diǎn)渺杉,那就是一個(gè)讀取配置操作竟然耗時(shí)400+ms的時(shí)間(有圖為證)蛇数,
我當(dāng)時(shí)就被震驚了,這里竟然耗時(shí)這么久是越!作為一個(gè)碼農(nóng)耳舅,這時(shí)必須要看源碼呀,可惜通過(guò)AS并不能直接看到實(shí)現(xiàn)邏輯倚评,不過(guò)通過(guò)Google還是可以輕松找到的浦徊,有興趣的看這里。
SharedPreferences
是一個(gè)抽象類天梧,所以具體實(shí)現(xiàn)的邏輯便在其子類SharedPreferencesImpl
中盔性,先看下它的構(gòu)造方法:
SharedPreferencesImpl(File file, int mode) {
mFile = file;
mBackupFile = makeBackupFile(file);
mMode = mode;
mLoaded = false;
mMap = null;
startLoadFromDisk();//可以看到,當(dāng)你使用時(shí)呢岗,這里變開(kāi)始從sdcard讀取xml文件
}
startLoadFromDisk()
具體實(shí)現(xiàn)代碼如下:
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();
}
再看看get方法:
public String getString(String key, String defValue) {
synchronized (this) {
awaitLoadedLocked();
String v = (String)mMap.get(key);
return v != null ? v : defValue;
}
}
從代碼可以看到冕香,在get之前是要調(diào)用awaitLoadedLocked ()
方法的,那這個(gè)方法具體做了什么呢后豫?看代碼:
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 {
wait();
} catch (InterruptedException unused) {
}
}
}
也許你已經(jīng)看出來(lái)了悉尾,在真正get數(shù)據(jù)之前是要判斷文件加載狀態(tài)的。如果此時(shí)沒(méi)加載出來(lái)挫酿,那就要等待构眯。這時(shí)你有沒(méi)有理解為什么第一次調(diào)用要花費(fèi)400+ms的時(shí)間(就是MethodTrace圖上顯示的時(shí)間,雖然MethodTrace方法本身會(huì)增加方法的調(diào)用時(shí)間早龟,但基本上還是可以反應(yīng)出實(shí)際調(diào)用時(shí)間長(zhǎng)短的)了嗎惫霸?是不是心里在想:你的App中使用大量PreferenceManger獲取SharedPreferences對(duì)象來(lái)存儲(chǔ)配置信息,導(dǎo)致該文件變得很大葱弟,文件大肯定加載時(shí)間要長(zhǎng)嘛壹店。Bingo,you get it翘悉。前面鋪墊那么多茫打,就是為了這一點(diǎn),文件大自然要等待很久妖混,所以如果你的App對(duì)初始化時(shí)間敏感老赤,并且你配置文件中存了太多的東西,那么你應(yīng)該考慮把初始化所需要的配置放在單獨(dú)的文件中(自然是使用context.getSharedPreferences()
方法制市,傳入單獨(dú)的名稱)抬旺,而不是所有的配置放一起了。
后記:SharedPreferencesImpl
的實(shí)例是有緩存的祥楣,cache在ContextImpl
類中开财,所以在load之后汉柒,下次再調(diào)用SharedPreferences.getXXX()
方法時(shí)你將看不到漫長(zhǎng)的wait時(shí)間了。