Android?SharedPreferences性能瓶頸解析
正文
想必大家對(duì)SharedPreferences都已經(jīng)很熟悉了，大型應(yīng)用使用SharedPreferences開(kāi)發(fā)很容易出現(xiàn)性能瓶頸，相信很多開(kāi)發(fā)者已經(jīng)遷移到MMKV進(jìn)行配置存儲(chǔ)
說(shuō)到MMKV我們總是會(huì)看到如下這張圖
在模擬1000次寫入的情況下，MMKV大幅度領(lǐng)先SharedPreferences，我們都知道MMKV使用了mmap方式進(jìn)行存儲(chǔ)，而SharedPreferences還是使用傳統(tǒng)的文件系統(tǒng)，以xml的方式進(jìn)行配置存儲(chǔ)，mmap確實(shí)具備較好的性能和穩(wěn)定性，但是真的兩種不同的存儲(chǔ)方式可以帶來(lái)如此巨大的性能差異嗎？
測(cè)試
因此我編寫代碼進(jìn)行了一次測(cè)試
findViewById(R.id.test5).setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
long time2 = System.currentTimeMillis();
SharedPreferences mSharedPreferences = WebTurboConfiguration.getInstance().mContext.getSharedPreferences(WebTurboConfigSp.Key.SHARED_PREFS_FILE_NAME, Context.MODE_PRIVATE);
SharedPreferences.Editor editor = mSharedPreferences.edit();
for (int i = 0; i < 1000; i++) {
editor.putString(i + "", 1000 + "");
editor.apply();
}
long time3 = System.currentTimeMillis();
Log.e("模擬寫入", "sp存儲(chǔ)耗時(shí) = " + (time3 - time2));
MMKV mmkv = MMKV.defaultMMKV();
for (int i = 0; i < 1000; i++) {
mmkv.putString(i + "", 1000 + "");
}
long time4 = System.currentTimeMillis();
Log.e("模擬寫入", "mmkv 存儲(chǔ)耗時(shí) = " + (time4 - time3));
}
});
輸出如下
E/模擬寫入: sp存儲(chǔ)耗時(shí) = 82ms
E/模擬寫入: mmkv 存儲(chǔ)耗時(shí) = 6ms
MMKV確實(shí)性能顯著強(qiáng)于SharedPreferences
apply方法的注釋
SharedPreferences在使用的時(shí)候是推薦使用apply進(jìn)行保存，我們來(lái)看一下apply方法的注釋
注釋中明確說(shuō)明apply方法是先將存儲(chǔ)數(shù)據(jù)提交到內(nèi)存，然后異步進(jìn)行磁盤寫入，既然是異步寫入，理論上IO不會(huì)拖后腿，我們可以認(rèn)為時(shí)間都被消耗在了將數(shù)據(jù)提交到內(nèi)存上，在寫入內(nèi)存上面SharedPreferences與MMKV會(huì)有這么大的性能差距嗎？
這激起了我的興趣
我使用AS自帶的性能分析工具對(duì)SharedPreferences存儲(chǔ)過(guò)程進(jìn)行一次trace分析 分析圖如下
可以輕松的從圖中看到
數(shù)據(jù)存儲(chǔ)put方法的主要耗時(shí)在puMapEntries上
代碼調(diào)用如下
SharedPreferences的實(shí)際實(shí)現(xiàn)代碼在SharedPreferencesImpl中
@Override
public void apply() {
final long startTime = System.currentTimeMillis();
final MemoryCommitResult mcr = commitToMemory();
final Runnable awaitCommit = new Runnable() {
@Override
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() {
@Override
public void run() {
awaitCommit.run();
QueuedWork.removeFinisher(awaitCommit);
}
};
SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);
notifyListeners(mcr);
}
主要看
final MemoryCommitResult mcr = commitToMemory();
代碼比較長(zhǎng)
private MemoryCommitResult commitToMemory() {
long memoryStateGeneration;
boolean keysCleared = false;
List<String> keysModified = null;
Set<OnSharedPreferenceChangeListener> listeners = null;
Map<String, Object> mapToWriteToDisk;
synchronized (SharedPreferencesImpl.this.mLock) {
if (mDiskWritesInFlight > 0) {
mMap = new HashMap<String, Object>(mMap);
}
mapToWriteToDisk = mMap;
mDiskWritesInFlight++;
boolean hasListeners = mListeners.size() > 0;
if (hasListeners) {
keysModified = new ArrayList<String>();
listeners = new HashSet<OnSharedPreferenceChangeListener>(mListeners.keySet());
}
synchronized (mEditorLock) {
boolean changesMade = false;
if (mClear) {
if (!mapToWriteToDisk.isEmpty()) {
changesMade = true;
mapToWriteToDisk.clear();
}
keysCleared = true;
mClear = false;
}
for (Map.Entry<String, Object> e : mModified.entrySet()) {
String k = e.getKey();
Object v = e.getValue();
if (v == this || v == null) {
if (!mapToWriteToDisk.containsKey(k)) {
continue;
}
mapToWriteToDisk.remove(k);
} else {
if (mapToWriteToDisk.containsKey(k)) {
Object existingValue = mapToWriteToDisk.get(k);
if (existingValue != null && existingValue.equals(v)) {
continue;
}
}
mapToWriteToDisk.put(k, v);
}
changesMade = true;
if (hasListeners) {
keysModified.add(k);
}
}
mModified.clear();
if (changesMade) {
mCurrentMemoryStateGeneration++;
}
memoryStateGeneration = mCurrentMemoryStateGeneration;
}
}
return new MemoryCommitResult(memoryStateGeneration, keysCleared, keysModified,
listeners, mapToWriteToDisk);
}
執(zhí)行邏輯
step1：可能需要對(duì)現(xiàn)有的數(shù)據(jù)mMap進(jìn)行一次深度拷貝，生成新的mMap對(duì)象
step2：對(duì)存儲(chǔ)了已修改數(shù)據(jù)的map（mModified）進(jìn)行遍歷，寫入mMap
step3：返回包含了全部數(shù)據(jù)的map用于存入文件系統(tǒng)
上文提到的大量耗時(shí)的puMapEntries方法就發(fā)生在step1中map的深度拷貝代碼中
if (mDiskWritesInFlight > 0) {
mMap = new HashMap<String, Object>(mMap);
}
public HashMap(Map<? extends K, ? extends V> m) {
this.loadFactor = DEFAULT_LOAD_FACTOR;
putMapEntries(m, false);
}
為什么step1中說(shuō)可能需要進(jìn)行一次深度拷貝呢，因?yàn)閙DiskWritesInFlight的值，在有配置需要寫入時(shí)，他就會(huì)+1，只有完全寫入磁盤，也就是此次配置已經(jīng)被持久化，mDiskWritesInFlight才會(huì)-1，也就是說(shuō)深度拷貝在上文提到的1000次寫入的場(chǎng)景下是一定會(huì)發(fā)生的，除了第一次可能不需要深度拷貝，后面999次大概率會(huì)發(fā)生深度拷貝，因?yàn)樵谡麄€(gè)1000次的寫入過(guò)程中，線程一直在不斷的將配置寫入磁盤，一直到1000次apply完成，數(shù)據(jù)可能還需要一段時(shí)間才能往磁盤里面寫完
我們代碼來(lái)模擬深度拷貝的場(chǎng)景，看深度拷貝map到底有多耗時(shí)，在代碼中我們模擬了1000次深度拷貝
E/模擬寫入: map深度拷貝耗時(shí) = 52ms
E/模擬寫入: sp存儲(chǔ)耗時(shí) = 59ms
E/模擬寫入: mmkv 存儲(chǔ)耗時(shí) = 4ms
可以看到1000次深度拷貝的耗時(shí)已經(jīng)接近SP1000次寫入的耗時(shí)
因此我們得到如下結(jié)論 在開(kāi)發(fā)者使用SharedPreferences的apply方法進(jìn)行存儲(chǔ)時(shí)，高頻次的apply調(diào)用會(huì)導(dǎo)致每次apply時(shí)進(jìn)行map的深度拷貝，導(dǎo)致耗時(shí)，如果只是一次調(diào)用，或者低頻次的調(diào)用，那么SharedPreferences依然可以具備較好的性能
下面是一次調(diào)用的模擬,可以看到單次場(chǎng)景下與MMKV的性能差距不明顯
E/模擬寫入: sp存儲(chǔ)耗時(shí) = 231192ns
E/模擬寫入: mmkv 存儲(chǔ)耗時(shí) = 229154ns
那么如果需要高頻次寫入SharedPreferences，如何保證較好的性能呢，比如在一個(gè)循環(huán)中寫入SharedPreferences，那就要想辦法避免map被頻繁的深度拷貝，解決辦法就是多次put完成后再apply
示例代碼如下
findViewById(R.id.test5).setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
long time1 = System.currentTimeMillis();
HashMap<String, String> map = new HashMap<>();
for (int i = 0; i < 1000; i++) {
map.put(i + "", 1000 + "");
new HashMap<>(map);
}
long time2 = System.currentTimeMillis();
Log.e("模擬寫入", "map深度拷貝耗時(shí) = " + (time2 - time1));
SharedPreferences mSharedPreferences = WebTurboConfiguration.getInstance().mContext.getSharedPreferences(WebTurboConfigSp.Key.SHARED_PREFS_FILE_NAME, Context.MODE_PRIVATE);
SharedPreferences.Editor editor = mSharedPreferences.edit();
for (int i = 0; i < 1000; i++) {
editor.putString(i + "", 1000 + "");
}
editor.apply();
long time3 = System.currentTimeMillis();
Log.e("模擬寫入", "sp存儲(chǔ)耗時(shí) = " + (time3 - time2));
MMKV mmkv = MMKV.defaultMMKV();
for (int i = 0; i < 1000; i++) {
mmkv.putString(i + "", 1000 + "");
}
long time4 = System.currentTimeMillis();
Log.e("模擬寫入", "mmkv 存儲(chǔ)耗時(shí) = " + (time4 - time3));
}
});
輸出結(jié)果如下，SharedPreferences的存儲(chǔ)耗時(shí)甚至低于MMKV
E/模擬寫入: map深度拷貝耗時(shí) = 55
E/模擬寫入: sp存儲(chǔ)耗時(shí) = 1
E/模擬寫入: mmkv 存儲(chǔ)耗時(shí) = 4
本文只針對(duì)循環(huán)保存配置這一種場(chǎng)景進(jìn)行分析，無(wú)論如何使用，MMKV性能強(qiáng)于SharedPreferences是不爭(zhēng)的事實(shí)，如果開(kāi)發(fā)者開(kāi)發(fā)的只是一個(gè)小工具，小應(yīng)用，推薦使用SharedPreferences，他足夠的輕量，如果開(kāi)發(fā)商用中大型應(yīng)用，MMKV依然是最好的選擇，至于jetpack中的DataStore，并未使用過(guò)，不做評(píng)價(jià)
以上就是Android SharedPreferences性能瓶頸解析的詳細(xì)內(nèi)容，更多關(guān)于Android SharedPreferences性能瓶頸的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
Android 日常開(kāi)發(fā)總結(jié)的60條技術(shù)經(jīng)驗(yàn)
這篇文章主要介紹了Android日常開(kāi)發(fā)總結(jié)的技術(shù)經(jīng)驗(yàn)60條,需要的朋友可以參考下2016-03-03
這篇文章主要為大家詳細(xì)介紹了Android Service綁定完整過(guò)程,具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2016-10-10
Android編程四大組件之Activity用法實(shí)例分析
這篇文章主要介紹了Android編程四大組件之Activity用法,實(shí)例分析了Activity的創(chuàng)建,生命周期,內(nèi)存管理及啟動(dòng)模式等,具有一定參考借鑒價(jià)值,需要的朋友可以參考下2016-01-01
Android實(shí)現(xiàn)淘寶購(gòu)物車
這篇文章主要為大家詳細(xì)介紹了Android實(shí)現(xiàn)淘寶購(gòu)物車，文中示例代碼介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2021-05-05
Android響應(yīng)事件onClick方法的五種實(shí)現(xiàn)方式小結(jié)
本篇文章主要介紹了Android響應(yīng)onClick方法的五種實(shí)現(xiàn)方式小結(jié)，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下。2017-03-03
這篇文章主要幫助大家理解Android菜單Menu操作，引入Android菜單Menu操作的知識(shí)，感興趣的小伙伴們可以參考一下2016-04-04
Android開(kāi)發(fā)使用HttpURLConnection進(jìn)行網(wǎng)絡(luò)編程詳解【附源碼下載】
這篇文章主要介紹了Android開(kāi)發(fā)使用HttpURLConnection進(jìn)行網(wǎng)絡(luò)編程的方法,結(jié)合實(shí)例形式分析了Android基于HttpURLConnection實(shí)現(xiàn)顯示圖片與文本功能,涉及Android布局、文本解析、數(shù)據(jù)傳輸、權(quán)限控制等相關(guān)操作技巧,需要的朋友可以參考下2018-01-01
詳細(xì)分析Android中onTouch事件傳遞機(jī)制
相信不少朋友在剛開(kāi)始學(xué)習(xí)Android的時(shí)候，對(duì)于onTouch相關(guān)的事件一頭霧水。分不清onTouch()，onTouchEvent()和OnClick()之間的關(guān)系和先后順序，所以覺(jué)得有必要搞清onTouch事件傳遞的原理。經(jīng)過(guò)一段時(shí)間的琢磨以及相關(guān)博客的介紹，這篇文章就給大家詳細(xì)的分析介紹下。2016-10-10
Android 動(dòng)態(tài)改變布局實(shí)例詳解
這篇文章主要介紹了Android 動(dòng)態(tài)改變布局實(shí)例詳解的相關(guān)資料,這里舉例說(shuō)明如何實(shí)現(xiàn)動(dòng)態(tài)改變布局的例子，幫助大家學(xué)習(xí)理解，需要的朋友可以參考下2016-11-11
Android自定義控件（實(shí)現(xiàn)狀態(tài)提示圖表）
本篇文章主要介紹了android實(shí)現(xiàn)狀態(tài)提示圖表的功能，實(shí)現(xiàn)了動(dòng)態(tài)圖表的顯示，有需要的朋友可以了解一下。2016-11-11