[[199471]]

一、前言

對于 SharedPreferences(以下簡稱SP)，相信 Android 開發(fā)們，都不會陌生。無非是 Android 系統(tǒng)提供的一個以 Key-Value 鍵值對形式的存儲方式。如果需要獲取數(shù)據(jù)，SP 中提供了對應(yīng)的getXxx() 方法，如果需要存儲數(shù)據(jù)，只需要拿到 Editor 對象，在 Editor 對象中，也提供了對應(yīng)的 putXxx() 方法，在操作完成之后，調(diào)用 commit() 或者 apply() 即可。

那么 commit() 和 apply() 有什么區(qū)別?就是本篇文章的主題。

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

SharedPreferences 就是一個接口，其實現(xiàn)類是SharedPreferencesImpl 。

關(guān)于 commit() 和 apply() 的描述，在 SharedPreferences 中，下面先看看文檔中對它的說明。

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

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

獲取SP這個對象的方式，是使用：

Context.getSharedPreferences() 

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

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

雖然從文檔中，完全就可以了解清楚 SP 中，commit() 和 apply() 的具體區(qū)別和使用場景。但是作為一個有情懷的碼農(nóng)，還是需要再往深了一層挖挖，一探究竟。

之前提到，SharedPreferences 接口的實現(xiàn)類是SharedPreferencesImpl 。那么就繼續(xù)看看 apply() 和 commit() 的具體實現(xiàn)。

apply() :

commit()：

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

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

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

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

四、從效率上看問題

看了源碼更印證了之前的結(jié)論。

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

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

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

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

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

從執(zhí)行結(jié)果可以發(fā)現(xiàn)，使用 apply() 因為是異步操作，基本上是不耗費時間的，效率上都是 OK 的。從這個結(jié)論上來看，apply() 影響效率的地方，在 sp.edit() 方法。

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

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

五、結(jié)論

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

edit() 是有效率影響的，所以不要在循環(huán)中去調(diào)用此方法，***將 edit() 方法獲取的 Editor 對象方在循環(huán)之外，在循環(huán)中共用同一個 Editor() 對象進行操作。

commit() 的時候，「new-key」和「update-key」的效率是有差別的，但是有返回結(jié)果。

apply() 是異步操作，對效率的影響，基本上是 ms 級的，可以忽略不記。

【本文為51CTO專欄作者“張旸”的原創(chuàng)稿件，轉(zhuǎn)載請通過微信公眾號聯(lián)系作者獲取授權(quán)】

戳這里，看該作者更多好文