版權(quán)聲明:
本賬號(hào)發(fā)布文章均來(lái)自公眾號(hào),承香墨影(cxmyDev)逻谦,版權(quán)歸承香墨影所有陪蜻。
允許有條件轉(zhuǎn)載邦马,轉(zhuǎn)載請(qǐng)附帶底部二維碼宴卖。
一、前言
對(duì)于SharedPreferences(以下簡(jiǎn)稱SP)嘱腥,相信做過(guò)Android開(kāi)發(fā)的同學(xué)耕渴,都不會(huì)陌生。無(wú)非是Android系統(tǒng)提供的一個(gè)以Key-value鍵值對(duì)形式的存儲(chǔ)方式齿兔。如果需要獲取數(shù)據(jù)橱脸,SP中提供了對(duì)應(yīng)的getXxx()方法,如果需要存儲(chǔ)數(shù)據(jù)分苇,只需要拿到Editor對(duì)象添诉,在Editor對(duì)象中,也提供了對(duì)應(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中扩劝,下面先看看文檔中對(duì)它的說(shuō)明。
從文檔中可以看出一些區(qū)別:
- apply()沒(méi)有返回值,而commit()是有返回值的棒呛,返回值標(biāo)識(shí)著是否執(zhí)行成功聂示。
- apply()的操作是原子提交到內(nèi)存中,然后以異步的方式保存到磁盤上簇秒,而commit()完全是以同步的方式將數(shù)據(jù)保存到磁盤上鱼喉。
- apply()因?yàn)闆](méi)有返回值,所以不會(huì)提示任何失敗宰睡。只需要調(diào)用即可蒲凶。
- 無(wú)論是apply()還是commit()气筋,如果同時(shí)被操作了拆内,以最后一次操作為準(zhǔn)。
獲取SP這個(gè)對(duì)象的方式宠默,是使用:
Context.getSharedPreferences()
所以在同一進(jìn)程中麸恍,SP對(duì)象是以單例的形式存在的,所以不需要考慮有沖突的問(wèn)題搀矫。但是因?yàn)閍pply()和commit()的差異性抹沪,如果對(duì)提交結(jié)果不關(guān)心的話,推薦使用apply()瓤球,如果需要確保保存成功之后融欧,才繼續(xù)進(jìn)行后續(xù)的操作,推薦使用commit()卦羡。
三噪馏、從代碼中看區(qū)別
雖然從文檔中,完全就可以了解清楚SP中绿饵,commit和apply的具體區(qū)別和使用場(chǎng)景欠肾。但是作為一個(gè)有情懷的碼農(nóng),還是需要再往深了一層挖挖拟赊,一探究竟刺桃。
之前提到,SharedPreferences.java接口的實(shí)現(xiàn)類是SharedPreferencesImpl.java吸祟。那么就繼續(xù)看看apply和commit的具體實(shí)現(xiàn)瑟慈。
apply():
commit():
對(duì)比發(fā)現(xiàn)commit的實(shí)現(xiàn)非常的簡(jiǎn)單,并且在SP中屋匕,是通過(guò)enqueueDiskWrite()方法來(lái)控制是否是異步操作的葛碧。
下面看看enqueueDiskWrite()方法的實(shí)現(xiàn)。
從注釋里可以看到炒瘟,如果enqueueDiskWrite()的第二個(gè)參數(shù)為null的話吹埠,則會(huì)變成同步操作。而正是因?yàn)樵赾ommit()中是同步操作,commit()才可以拿到操作是否正確的結(jié)果缘琅。
具體將數(shù)據(jù)持久化到硬盤上的操作粘都,是調(diào)用了writeToFile()方法,無(wú)非就是一些對(duì)文件讀寫(xiě)的操作和XML的處理刷袍,這個(gè)就不再這里繼續(xù)探討了翩隧,有興趣的可以自己看看源碼。
四呻纹、從效率上看問(wèn)題
看了源碼更印證了之前的結(jié)論堆生。
再?gòu)男噬峡纯碨P,從SP提供的接口上看雷酪,get操作應(yīng)該只是去獲取淑仆,這個(gè)就像從一個(gè)單例的對(duì)象中,獲取一個(gè)數(shù)據(jù)一樣哥力,從效率上看應(yīng)該是不存在什么損耗的蔗怠。那么從存儲(chǔ)的角度,去分析一下效率的問(wèn)題吩跋。
這個(gè)先上結(jié)論寞射,再來(lái)分析一下問(wèn)題。寫(xiě)了一個(gè)簡(jiǎn)單的demo:
A操作和B操作锌钮,在代碼邏輯上應(yīng)該是一樣的桥温,都是想SP中寫(xiě)入100次不同字段的數(shù)據(jù),區(qū)別只是在于梁丘,A操作每次都去獲取新的Editor侵浸,而B(niǎo)操作是只使用一個(gè)Eidtor去存儲(chǔ)。兩個(gè)操作都分別執(zhí)行兩次兰吟。
可以看出來(lái)通惫,使用commit()的方式,如果每次都使用sp.edit()方法獲取一個(gè)新的Editor的話混蔼,新建和修改的執(zhí)行效率差了非常的大履腋。也就是說(shuō),存儲(chǔ)一個(gè)從來(lái)沒(méi)有用過(guò)的Key惭嚣,和修改一個(gè)已經(jīng)存在的Key遵湖,在效率上是有差別的。
然后把之前的例子中晚吞,commit修改成apply延旧,這里就不貼代碼了。再來(lái)看看執(zhí)行結(jié)果槽地,當(dāng)然在運(yùn)行前需要先清空數(shù)據(jù)迁沫。這里把A操作和B操作分別執(zhí)行了4次芦瘾。
從執(zhí)行結(jié)果可以發(fā)現(xiàn),使用apply因?yàn)槭钱惒讲僮骷旧鲜遣缓馁M(fèi)時(shí)間的近弟,效率上都是OK的。從這個(gè)結(jié)論上來(lái)看挺智,apply影響效率的地方祷愉,在sp.edit()方法。
那么赦颇,再看看edit()方法是如何實(shí)現(xiàn)的:
可以看出來(lái)二鳄,在edit()中是有synchronized 這個(gè)同步鎖來(lái)保證線程安全的,縱觀EditorImpl.java的實(shí)現(xiàn)媒怯,可以看到大部分操作都是有同步鎖的订讼,但是只鎖了(this),也就是只對(duì)當(dāng)前對(duì)象有效沪摄,而edit()方法是每次都會(huì)去重新new一個(gè)EditorImpl()這個(gè)Eidtor接口的實(shí)現(xiàn)類躯嫉。所以效率就應(yīng)該是被這里影響到了。
四杨拐、結(jié)論
既然已經(jīng)分析了SP的文檔說(shuō)明和代碼實(shí)現(xiàn),那么就可以分析出一些SP效率相關(guān)的結(jié)論擂啥。
- edit()是有效率影響的哄陶,所以不要在循環(huán)中去調(diào)用吃方法,最好將edit()方法獲取的Editor對(duì)象方在循環(huán)之外哺壶,在循環(huán)中共用同一個(gè)Editor()對(duì)象進(jìn)行操作屋吨。
- commit()的時(shí)候,「new-key」和「update-key」的效率是有差別的山宾,但是有返回結(jié)果至扰。
- apply()是異步操作,對(duì)效率的影響资锰,基本上是ms級(jí)的敢课,可以忽略不記。