今天看到一個有趣的現(xiàn)象，比較好奇，由于這個是好幾億用戶的大項目，所以我相信這里面代碼有一定權(quán)威性，由于很好奇為什么不用原生的SharedPreferences，而是用ContentProvider的方式代替。究竟是為什么呢？要知道這個原因，那就必須要看看原生SharedPreferences有什么相對于ContentProvider的缺點了。
好神奇，不知道谷歌什么時候有一個看源碼的鏈接哈哈。
image.png
使用
SharedPreferences sharedPreferences = getSharedPreferences("xxx", Context.MODE_PRIVATE);
Editor editor = sharedPreferences.edit();
editor.putString("aaa", "xxx");
editor.putInt("bbb", 10);
editor.commit();
生成的文件如下：
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
<string name="aaa">xxx</string>
<int name="bbb" value="10" />
</map>
源碼解析
會有兩種方式使用SharedPreferences 但是最終原理一樣。
Activity.java
public SharedPreferences getPreferences(int mode) {
return getSharedPreferences(getLocalClassName(), mode);
}
PreferenceManager.java
public static SharedPreferences getDefaultSharedPreferences(Context context) {
return context.getSharedPreferences(getDefaultSharedPreferencesName(context),
getDefaultSharedPreferencesMode());
}
第二種方式以包名加上_preferences作為文件名, 以MODE_PRIVATE模式創(chuàng)建SP文件. 即packgeName_preferences.xml.
最終都會調(diào)到：
ContextImpl.java
class ContextImpl extends Context {
private ArrayMap<String, File> mSharedPrefsPaths;
public SharedPreferences getSharedPreferences(String name, int mode) {
File file;
synchronized (ContextImpl.class) {
if (mSharedPrefsPaths == null) {
mSharedPrefsPaths = new ArrayMap<>();
}
//先從mSharedPrefsPaths查詢是否存在相應(yīng)文件
file = mSharedPrefsPaths.get(name);
if (file == null) {
//如果文件不存在, 則創(chuàng)建新的文件，文件的路徑是/data/data/package name/shared_prefs/
file = getSharedPreferencesPath(name);
mSharedPrefsPaths.put(name, file);
}
}
return getSharedPreferences(file, mode);
}
}
public File getSharedPreferencesPath(String name) {
return makeFilename(getPreferencesDir(), name + ".xml");
}
private File getPreferencesDir() {
synchronized (mSync) {
if (mPreferencesDir == null) {
//創(chuàng)建目錄/data/data/package name/shared_prefs/
mPreferencesDir = new File(getDataDir(), "shared_prefs");
}
return ensurePrivateDirExists(mPreferencesDir);
}
}
最后會調(diào)用到重載函數(shù)中
public SharedPreferences getSharedPreferences(File file, int mode) {
checkMode(mode);
SharedPreferencesImpl sp;
synchronized (ContextImpl.class) {
final ArrayMap<File, SharedPreferencesImpl> cache = getSharedPreferencesCacheLocked();
sp = cache.get(file);
if (sp == null) {
//創(chuàng)建SharedPreferencesImpl
sp = new SharedPreferencesImpl(file, mode);
cache.put(file, sp);
return sp;
}
}
//指定多進程模式, 則當(dāng)文件被其他進程改變時,則會重新加載
if ((mode & Context.MODE_MULTI_PROCESS) != 0 ||
getApplicationInfo().targetSdkVersion < android.os.Build.VERSION_CODES.HONEYCOMB) {
sp.startReloadIfChangedUnexpectedly();
}
return sp;
}
關(guān)于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");
}
}
}
可以看出來N包括N以上的版本都不支持MODE_WORLD_READABLE，MODE_WORLD_WRITEABLE這兩種模式了。
上面getSharedPreferences是把文件緩存起來，這次又要緩存啥？我們看看
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;
}
ArrayMap<packageName,<ArrayMap<File,SharedPreferencesImpl>>>
形成了上面這種結(jié)構(gòu)
第一次肯定是空，所以我們要創(chuàng)建SharedPreferencesImpl。
SharedPreferencesImpl(File file, int mode) {
mFile = file;
//創(chuàng)建為.bak為后綴的備份文件
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();
}
private void loadFromDisk() {
synchronized (SharedPreferencesImpl.this) {
if (mLoaded) {
return;
}
if (mBackupFile.exists()) {
mFile.delete();
mBackupFile.renameTo(mFile);
}
}
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 | IOException e) {
...
} finally {
IoUtils.closeQuietly(str);
}
}
} catch (ErrnoException e) {
...
}
synchronized (SharedPreferencesImpl.this) {
mLoaded = true;
if (map != null) {
mMap = map; //從文件讀取的信息保存到mMap
mStatTimestamp = stat.st_mtime; //更新修改時間
mStatSize = stat.st_size; //更新文件大小
} else {
mMap = new HashMap<>();
}
notifyAll(); //喚醒處于等待狀態(tài)的線程
}
}
我們看整體流程就是，首次會創(chuàng)建xml文件，然后會把整個文件在子線程中加載到內(nèi)存中，但是要注意的是此時異步是加鎖的就是沒加載完成要是讀取文件內(nèi)容的話，會一直等待，所以我們就可以想象，如果一個文件很大，是不是我們就得等很長時間才可以讀內(nèi)容。而且我們看到緩存是根據(jù)文件緩存，當(dāng)每個文件都比較大的時候就悲劇了。這也就是不能用SharedPreferences存儲大量信息的原因。
繼續(xù)說查詢
SharedPreferencesImpl.java
public String getString(String key, @Nullable String defValue) {
synchronized (this) {
//檢查是否加載完成
awaitLoadedLocked();
String v = (String)mMap.get(key);
return v != null ? v : defValue;
}
}
private void awaitLoadedLocked() {
if (!mLoaded) {
BlockGuard.getThreadPolicy().onReadFromDisk();
}
while (!mLoaded) {
try {
wait(); //當(dāng)沒有加載完成,則進入等待狀態(tài)
} catch (InterruptedException unused) {
}
}
}
當(dāng)xml文件沒有加載到內(nèi)存中時就等待。
根據(jù)我們的用法我們要存儲就得先有Editor
public Editor edit() {
synchronized (this) {
awaitLoadedLocked();
}
return new EditorImpl(); //創(chuàng)建EditorImpl
}
我去還要等待，其實也對等待加載完成才能寫入
public final class EditorImpl implements Editor {
private final Map<String, Object> mModified = Maps.newHashMap();
private boolean mClear = false;
//插入數(shù)據(jù)
public Editor putString(String key, @Nullable String value) {
synchronized (this) {
//插入數(shù)據(jù), 先暫存到mModified對象
mModified.put(key, value);
return this;
}
}
//移除數(shù)據(jù)
public Editor remove(String key) {
synchronized (this) {
mModified.put(key, this);
return this;
}
}
//清空全部數(shù)據(jù)
public Editor clear() {
synchronized (this) {
mClear = true;
return this;
}
}
}
我們添加數(shù)據(jù)移除數(shù)據(jù)清空數(shù)據(jù)，僅僅只是操作mModified 這個在內(nèi)存中的Map而已。
最后一步提交
EditorImpl.java
public boolean commit() {
//將數(shù)據(jù)更新到內(nèi)存
MemoryCommitResult mcr = commitToMemory();
//將內(nèi)存數(shù)據(jù)同步到文件
SharedPreferencesImpl.this.enqueueDiskWrite(mcr, null);
try {
//進入等待狀態(tài), 直到寫入文件的操作完成
mcr.writtenToDiskLatch.await();
} catch (InterruptedException e) {
return false;
}
//通知監(jiān)聽則, 并在主線程回調(diào)onSharedPreferenceChanged()方法
notifyListeners(mcr);
// 返回文件操作的結(jié)果數(shù)據(jù)
return mcr.writeToDiskResult;
}
提交就比較有水平了我們一個個分析對應(yīng)的方法:
private MemoryCommitResult commitToMemory() {
MemoryCommitResult mcr = new MemoryCommitResult();
synchronized (SharedPreferencesImpl.this) {
if (mDiskWritesInFlight > 0) {
mMap = new HashMap<String, Object>(mMap);
}
mcr.mapToWriteToDisk = mMap;
mDiskWritesInFlight++;
//是否有監(jiān)聽key改變的監(jiān)聽者
boolean hasListeners = mListeners.size() > 0;
if (hasListeners) {
mcr.keysModified = new ArrayList<String>();
mcr.listeners = new HashSet<OnSharedPreferenceChangeListener>(mListeners.keySet());
}
synchronized (this) {
//當(dāng)mClear為true, 則直接清空mMap
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是個特殊值, 用于移除相應(yīng)的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; // changesMade代表數(shù)據(jù)是否有改變
if (hasListeners) {
mcr.keysModified.add(k); //記錄發(fā)生改變的key
}
}
mModified.clear(); //清空EditorImpl中的mModified數(shù)據(jù)
}
}
return mcr;
}
我們上面如果設(shè)置清空，則真正清空的地方是在這里。我們把mModified對應(yīng)的數(shù)據(jù)都拿出來，這個是添加數(shù)據(jù)，移除數(shù)據(jù)等操作的內(nèi)存數(shù)據(jù)映射，然后在mMap這個是讀入文件的內(nèi)存數(shù)據(jù)映射。然后過濾包含的等操作，如果發(fā)生變化，則記錄這個發(fā)生變化的key，因為已經(jīng)將數(shù)據(jù)轉(zhuǎn)移到了mMap中，所以此時清空mModified在內(nèi)存中的數(shù)據(jù)。
哦對了，這里還有mDiskWritesInFlight++操作
private void enqueueDiskWrite(final MemoryCommitResult mcr,
final Runnable postWriteRunnable) {
final Runnable writeToDiskRunnable = new Runnable() {
public void run() {
synchronized (mWritingToDiskLock) {
//執(zhí)行文件寫入操作
writeToFile(mcr);
}
synchronized (SharedPreferencesImpl.this) {
mDiskWritesInFlight--;
}
//此時postWriteRunnable為null不執(zhí)行該方法
if (postWriteRunnable != null) {
postWriteRunnable.run();
}
}
};
final boolean isFromSyncCommit = (postWriteRunnable == null);
if (isFromSyncCommit) { //commit方法會進入該分支
boolean wasEmpty = false;
synchronized (SharedPreferencesImpl.this) {
//commitToMemory過程會加1,則wasEmpty=true
wasEmpty = mDiskWritesInFlight == 1;
}
if (wasEmpty) {
//跳轉(zhuǎn)到上面
writeToDiskRunnable.run();
return;
}
}
//不執(zhí)行該方法
QueuedWork.singleThreadExecutor().execute(writeToDiskRunnable);
}
首先映入眼簾的是我們的中國夢之隊跳水運動員...額跑的有點偏，mDiskWritesInFlight--操作，在run里面。說明寫成功了這個值就成0了。
這里wasEmpty = mDiskWritesInFlight == 1;由于上面操作此時為true，所以執(zhí)行writeToDiskRunnable.run();
private void writeToFile(MemoryCommitResult mcr) {
if (mFile.exists()) {
if (!mcr.changesMade) { //沒有key發(fā)生改變, 則直接返回
mcr.setDiskWriteResult(true);
return;
}
if (!mBackupFile.exists()) {
//當(dāng)備份文件不存在, 則把mFile重命名為備份文件
if (!mFile.renameTo(mBackupFile)) {
mcr.setDiskWriteResult(false);
return;
}
} else {
mFile.delete(); //否則,直接刪除mFile
}
}
try {
FileOutputStream str = createFileOutputStream(mFile);
if (str == null) {
mcr.setDiskWriteResult(false);
return;
}
//將mMap全部信息寫入文件
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) {
...
}
//寫入成功, 則刪除備份文件
mBackupFile.delete();
//返回寫入成功, 喚醒等待線程
mcr.setDiskWriteResult(true);
return;
} catch (XmlPullParserException e) {
...
} catch (IOException e) {
...
}
//如果寫入文件的操作失敗, 則刪除未成功寫入的文件
if (mFile.exists()) {
if (!mFile.delete()) {
...
}
}
//返回寫入失敗, 喚醒等待線程
mcr.setDiskWriteResult(false);
}
mcr.changesMade這個只有在數(shù)據(jù)更新有變化的時候才會為true。
其次當(dāng)備份文件不存在了，把mFile重命名成備份文件，所以寫之前一定有一份備份文件，這也類似于我們寫一句代碼按下Ctrl+S哈哈，下來才是寫的過程，將mMap的全部信息寫入到文件按照XML格式。寫成功了，刪除備份，并且喚醒等待線程。
所以我們每一次commit都是將全部文件進行寫入操作。所以耗時耗時耗時啊。
我們還有一種提交方式
image.png
那我們就看看這個操作:
public void apply() {
//把數(shù)據(jù)更新到內(nèi)存
final MemoryCommitResult mcr = commitToMemory();
final Runnable awaitCommit = new Runnable() {
public void run() {
try {
//進入等待狀態(tài)
mcr.writtenToDiskLatch.await();
} catch (InterruptedException ignored) {
}
}
};
//將awaitCommit添加到QueuedWork
QueuedWork.add(awaitCommit);
Runnable postWriteRunnable = new Runnable() {
public void run() {
awaitCommit.run();
//從QueuedWork移除
QueuedWork.remove(awaitCommit);
}
};
SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);
notifyListeners(mcr);
}
private void enqueueDiskWrite(final MemoryCommitResult mcr,
final Runnable postWriteRunnable) {
final Runnable writeToDiskRunnable = new Runnable() {
public void run() {
synchronized (mWritingToDiskLock) {
//執(zhí)行文件寫入操作
writeToFile(mcr);
}
synchronized (SharedPreferencesImpl.this) {
mDiskWritesInFlight--;
}
if (postWriteRunnable != null) {
postWriteRunnable.run();
}
}
};
final boolean isFromSyncCommit = (postWriteRunnable == null);
if (isFromSyncCommit) {
... //postWriteRunnable不為空
}
//將任務(wù)放入單線程的線程池來執(zhí)行
QueuedWork.singleThreadExecutor().execute(writeToDiskRunnable);
}
首先我們的postWriteRunnable參數(shù)不為null了，其次我們看到線程池了。
public class QueuedWork {
private static final ConcurrentLinkedQueue<Runnable> sPendingWorkFinishers =
new ConcurrentLinkedQueue<Runnable>();
public static void add(Runnable finisher) {
sPendingWorkFinishers.add(finisher);
}
public static void remove(Runnable finisher) {
sPendingWorkFinishers.remove(finisher);
}
public static void waitToFinish() {
Runnable toFinish;
while ((toFinish = sPendingWorkFinishers.poll()) != null) {
toFinish.run();
}
}
public static boolean hasPendingWork() {
return !sPendingWorkFinishers.isEmpty();
}
}
所以區(qū)別就是，我們第二種方式用線程池來管理寫的過程，這個過程首先會將awaitCommit放入QueuedWork隊列當(dāng)寫執(zhí)行完之后就會移除。
這個QueuedWork存在的意義是什么呢？具體這里我也不清楚，只是看網(wǎng)上的大蝦，說用于在Stop Service, finish BroadcastReceiver過程用于 判定是否處理完所有的異步SP操作.
對比一下提交的兩種方式：
| apply | commit |
|---|---|
| 沒有返回值 | 有返回值可判斷是否寫入成功 |
| apply是將修改提交到內(nèi)存再異步提交到磁盤文件 | 同步的提交到磁盤文件 |
| 只是原子更新到內(nèi)存，后調(diào)用apply函數(shù)會直接覆蓋前面內(nèi)存數(shù)據(jù) | 多并發(fā)的提交commit時，需等待正在處理的commit數(shù)據(jù)更新到磁盤文件后才會繼續(xù)往下執(zhí)行 |
從對比中我們可以看出來一些合理的方式：
- 盡量不要在sp里面存儲特別大的key/value, 有助于減少卡頓/anr
- 盡量批量apply與commit，不要頻繁
- 不要使用MODE_MULTI_PROCESS模式
- 因為key是文件，所以可以拆分成多個文件，減少同步鎖的競爭
- 不要連續(xù)多次edit(), 應(yīng)該獲取一次獲取edit(),然后多次執(zhí)行putxxx(), 減少內(nèi)存波動; 經(jīng)?？吹酱蠹蚁矚g封裝方法, 結(jié)果就導(dǎo)致anr這種情況的出現(xiàn).
- 每次commit時會把全部的數(shù)據(jù)更新的文件, 所以整個文件是不應(yīng)該過大的, 影響整體性能;
- 不要一上來就執(zhí)行g(shù)etSharedPreferences().edit(), 應(yīng)該分成兩大步驟來做, 中間可以執(zhí)行其他代碼.
參考：輝輝大神的建議。
