版權(quán)聲明：

本賬號發(fā)布文章均來自公眾號，承香墨影（cxmyDev），版權(quán)歸承香墨影所有。

允許有條件轉(zhuǎn)載，轉(zhuǎn)載請附帶底部二維碼。

一、前言

對于SharedPreferences（以下簡稱SP），相信做過Android開發(fā)的同學(xué)，都不會陌生。無非是Android系統(tǒng)提供的一個(gè)以Key-value鍵值對形式的存儲方式。如果需要獲取數(shù)據(jù)，SP中提供了對應(yīng)的getXxx()方法，如果需要存儲數(shù)據(jù)，只需要拿到Editor對象，在Editor對象中，也提供了對應(yīng)的putXxx()方法，在操作完成之后，調(diào)用commit()或者apply即可。
那么commit()和apply()有什么區(qū)別？就是本篇博客的主題。

二、從文檔上看區(qū)別

SharedPreferences.java其實(shí)是一個(gè)接口，其實(shí)現(xiàn)類是SharedPreferencesImpl.java。
關(guān)于commit()和apply()的描述，在SharedPreferences.java中，下面先看看文檔中對它的說明。

sp-api.png

從文檔中可以看出一些區(qū)別：

1. apply()沒有返回值，而commit()是有返回值的，返回值標(biāo)識著是否執(zhí)行成功。
2. apply()的操作是原子提交到內(nèi)存中，然后以異步的方式保存到磁盤上，而commit()完全是以同步的方式將數(shù)據(jù)保存到磁盤上。
3. apply()因?yàn)闆]有返回值，所以不會提示任何失敗。只需要調(diào)用即可。
4. 無論是apply()還是commit()，如果同時(shí)被操作了，以最后一次操作為準(zhǔn)。

獲取SP這個(gè)對象的方式，是使用：

  Context.getSharedPreferences()

所以在同一進(jìn)程中，SP對象是以單例的形式存在的，所以不需要考慮有沖突的問題。但是因?yàn)閍pply()和commit()的差異性，如果對提交結(jié)果不關(guān)心的話，推薦使用apply()，如果需要確保保存成功之后，才繼續(xù)進(jìn)行后續(xù)的操作，推薦使用commit()。

三、從代碼中看區(qū)別

雖然從文檔中，完全就可以了解清楚SP中，commit和apply的具體區(qū)別和使用場景。但是作為一個(gè)有情懷的碼農(nóng)，還是需要再往深了一層挖挖，一探究竟。
之前提到，SharedPreferences.java接口的實(shí)現(xiàn)類是SharedPreferencesImpl.java。那么就繼續(xù)看看apply和commit的具體實(shí)現(xiàn)。
apply():

sp-apply.png

commit()：

sp-commit.png

對比發(fā)現(xiàn)commit的實(shí)現(xiàn)非常的簡單，并且在SP中，是通過enqueueDiskWrite()方法來控制是否是異步操作的。

下面看看enqueueDiskWrite()方法的實(shí)現(xiàn)。

sp-dr.png

從注釋里可以看到，如果enqueueDiskWrite()的第二個(gè)參數(shù)為null的話，則會變成同步操作。而正是因?yàn)樵赾ommit()中是同步操作，commit()才可以拿到操作是否正確的結(jié)果。

具體將數(shù)據(jù)持久化到硬盤上的操作，是調(diào)用了writeToFile()方法，無非就是一些對文件讀寫的操作和XML的處理，這個(gè)就不再這里繼續(xù)探討了，有興趣的可以自己看看源碼。

四、從效率上看問題

看了源碼更印證了之前的結(jié)論。
再從效率上看看SP，從SP提供的接口上看，get操作應(yīng)該只是去獲取，這個(gè)就像從一個(gè)單例的對象中，獲取一個(gè)數(shù)據(jù)一樣，從效率上看應(yīng)該是不存在什么損耗的。那么從存儲的角度，去分析一下效率的問題。

這個(gè)先上結(jié)論，再來分析一下問題。寫了一個(gè)簡單的demo：

sp-demo1.png

A操作和B操作，在代碼邏輯上應(yīng)該是一樣的，都是想SP中寫入100次不同字段的數(shù)據(jù)，區(qū)別只是在于，A操作每次都去獲取新的Editor，而B操作是只使用一個(gè)Eidtor去存儲。兩個(gè)操作都分別執(zhí)行兩次。

sp-d-re.png

可以看出來，使用commit()的方式，如果每次都使用sp.edit()方法獲取一個(gè)新的Editor的話，新建和修改的執(zhí)行效率差了非常的大。也就是說，存儲一個(gè)從來沒有用過的Key，和修改一個(gè)已經(jīng)存在的Key，在效率上是有差別的。

然后把之前的例子中，commit修改成apply，這里就不貼代碼了。再來看看執(zhí)行結(jié)果，當(dāng)然在運(yùn)行前需要先清空數(shù)據(jù)。這里把A操作和B操作分別執(zhí)行了4次。

sp-re-demo2.png

從執(zhí)行結(jié)果可以發(fā)現(xiàn)，使用apply因?yàn)槭钱惒讲僮?，基本上是不耗費(fèi)時(shí)間的，效率上都是OK的。從這個(gè)結(jié)論上來看，apply影響效率的地方，在sp.edit()方法。

那么，再看看edit()方法是如何實(shí)現(xiàn)的：

sp-edit.png

可以看出來，在edit()中是有synchronized 這個(gè)同步鎖來保證線程安全的，縱觀EditorImpl.java的實(shí)現(xiàn)，可以看到大部分操作都是有同步鎖的，但是只鎖了(this)，也就是只對當(dāng)前對象有效，而edit()方法是每次都會去重新new一個(gè)EditorImpl()這個(gè)Eidtor接口的實(shí)現(xiàn)類。所以效率就應(yīng)該是被這里影響到了。

四、結(jié)論

既然已經(jīng)分析了SP的文檔說明和代碼實(shí)現(xiàn)，那么就可以分析出一些SP效率相關(guān)的結(jié)論。

• edit()是有效率影響的，所以不要在循環(huán)中去調(diào)用吃方法，最好將edit()方法獲取的Editor對象方在循環(huán)之外，在循環(huán)中共用同一個(gè)Editor()對象進(jìn)行操作。
• commit()的時(shí)候，「new-key」和「update-key」的效率是有差別的，但是有返回結(jié)果。
• apply()是異步操作，對效率的影響，基本上是ms級的，可以忽略不記。

公眾號二維碼.jpg