Android源码之SharedPreferences
0. 前言
SharedPreferences能够说是Android中最经常使用的一种存数据到文件的方式。他的数据是以键值对的方式存储在 ~/data/data/包名/shared_prefs 这个文件夹中的。java
这个存储框架是很是轻量级的，若是咱们须要存一些小数据或者是一个小型的可序列化的Bean实体类的，使用SharedPreferences是最明智的选择。android
1. 使用方法
1.1 获取SharedPreferences
在使用SharedPreferences前，咱们得先获取到它。缓存
因为SharedPreferences是Android内置的一个框架，因此咱们想要获取到它很是的简单，不须要导入任何依赖，直接写代码就行。下面咱们就来介绍下获取对象的三个方式：安全
1.1.1 Context # getSharedPreferences()
首先就是能够说是最经常使用的方法，经过Context的getSharedPreferences() 方法去获取到SharedPreferences对象。因为是经过Context获取的，因此基本上Android的全部场景咱们均可以经过这个方法获取到。并发
public abstract SharedPreferences getSharedPreferences (String name, int mode) 复制代码
这个方法接收两个参数，分别是name和mode：app
name：name就是咱们要存储的SharedPreferences本地文件的名字，这个能够自定义。可是若是使用一样的name的话，永远只能获取到同一个SharedPreferences的对象。mode：mode就是咱们要获取的这个SharedPreferences的访问模式，Android给咱们提供了挺多的模式的，可是因为其他的模式或多或少存在着安全隐患(由于其余应用也能够直接获取到)，因此就所有都弃用了，如今就只有一个MODE_PRIVATE模式。
此外，这个方法是线程安全的。框架
Mode的可选参数：异步
MODE_PRIVATE：私有模式，该SharedPreferences只会被调用他的APP去使用，其余的APP没法获取到这个SharedPreferences。MODE_WORLD_READABLEContentProvider、BroadcastReceiver和Service。MODE_WORLD_WRITEABLEMODE_MULTI_PROCESSContentProvider去操做。在后面咱们会说为啥多进程下不可靠。
1.1.2 Activity # getPreferences()
这个方法只能在Activity中或者经过Activity对象去使用。ide
public SharedPreferences getPreferences (int mode) 复制代码
这个方法须要传入一个mode参数，这个参数和上面的context#getSharedPreferences()的mode参数是同样的。其实这个方法和上面Context的那个方法是同样的，他两都是调用的SharedPreferences getSharedPreferences(String name, int mode)。只不过Context的须要你去指定文件名，而这个方法你不须要手动去指定，而是会自动将当前Activity的类名做为了文件名。函数
1.1.3 PreferencesManager # getDefaultSharedPreferences()
这个通常用在Android的设置页面上，或者说，咱们也只有在构建设置页面的时候才会去使用这个。
public static SharedPreferences getDefaultSharedPreferences (Context context) 复制代码
他承接一个context参数，并自动将当前应用的报名做为前缀来命名文件。
1.2 存数据
若是须要往SharedPreferences中存储数据的话，咱们并不能直接对SharedPreferences对象进行操做，由于SharedPreferences没有提供存储或者修改数据的接口。
若是想要对SharedPreferences存储的数据进行修改，须要经过SharedPreferences.edit()方法去获取到SharedPreferences.Editor对象来进行操做。
获取到Editor对象后，咱们就能够调用他的putXXX()方法进行存储了，存储以后必定记得经过apply()和commit()方法去将数据提交。
至于commit和apply的区别咱们后面会说。
//步骤1：建立一个SharedPreferences对象
SharedPreferences sharedPreferences= getSharedPreferences("data",Context.MODE_PRIVATE);
//步骤2： 实例化SharedPreferences.Editor对象
SharedPreferences.Editor editor = sharedPreferences.edit();
//步骤3：将获取过来的值放入文件
editor.putString("name", “Tom”);
editor.putInt("age", 28);
editor.putBoolean("marrid",false);
//步骤4：提交
editor.commit();
// 删除指定数据
editor.remove("name");
editor.commit();
// 清空数据
editor.clear();
editor.commit();
复制代码
1.3 取数据
取值就很简单了，构建出SharedPreferences的对象后，就直接调用SharedPreferences的getXXX()方法就行。
SharedPreferences sharedPreferences = getSharedPreferences("data", Context .MODE_PRIVATE);
String userId = sharedPreferences.getString("name", "");
复制代码
2. 源码分析
2.1 获取SharedPreferences实例
咱们上面说到，获取SharedPreferences实例最经常使用的方法就是Context#getSharedPreferences()。那咱们就从这个方法入手，看究竟是怎么获取到SharedPreferences实例的。
咱们先看下这个方法的实现：
public class ContextWrapper extends Context {
@UnsupportedAppUsage
Context mBase;
// ...
@Override
public SharedPreferences getSharedPreferences(String name, int mode) {
return mBase.getSharedPreferences(name, mode);
}
}
复制代码
能够看到他又调用了Context的getSharedPreferences()方法：
public abstract SharedPreferences getSharedPreferences(String name, @PreferencesMode int mode);
复制代码
而后咱们就会惊喜的发现，这是一个抽象方法。我开始还想去找一个ContextWrapper的构造的地方，看看mBase传入的是啥，后来找了一圈没找到，直接上网搜索，立马获得答案：ContextImpl，这个能够说是Context在Android中的惟一实现类，全部的操做又得通过这个类。那么咱们就来看下这个类中的getSharedPreferences()方法的实现：
@Override
public SharedPreferences getSharedPreferences(String name, int mode) {
// At least one application in the world actually passes in a null
// name. This happened to work because when we generated the file name
// we would stringify it to "null.xml". Nice.
// ps:这个nice很精髓😂
if (mPackageInfo.getApplicationInfo().targetSdkVersion <
Build.VERSION_CODES.KITKAT) {
if (name == null) {
name = "null";
}
}
File file;
// 加了一个类锁，保证同步
synchronized (ContextImpl.class) {
// mSharedPrefsPaths是一个保存了name和file对应关系的ArrayMap
if (mSharedPrefsPaths == null) {
mSharedPrefsPaths = new ArrayMap<>();
}
// 根据name从里面找有没有缓存的file
file = mSharedPrefsPaths.get(name);
// 若是没有，那就调用getSharedPreferencesPath去找
if (file == null) {
// ->>> 重点1. getSharedPreferencesPath(name)
file = getSharedPreferencesPath(name);
// 并保存到mSharedPrefsPaths
mSharedPrefsPaths.put(name, file);
}
}
// 获取到file后，再调用getSharedPreferences
return getSharedPreferences(file, mode);
}
/** * 重点1. ContextImpl # getSharedPreferencesPath(String name) * 根据PreferencesDir和name.xml去建立了这个文件 */
@Override
public File getSharedPreferencesPath(String name) {
return makeFilename(getPreferencesDir(), name + ".xml");
}
复制代码
那咱们在看下getSharedPreferences(File file, int mode)的实现：
@Override
public SharedPreferences getSharedPreferences(File file, int mode) {
// SharedPreferences惟一实现类SharedPreferencesImpl的实例
SharedPreferencesImpl sp;
// 一样的加类锁
synchronized (ContextImpl.class) {
// 构造了一个File-SharedPreferencesImpl对应关系的ArrayMap
// 调用getSharedPreferencesCacheLocked方法区获取cahce
// ->>> 重点1
final ArrayMap<File, SharedPreferencesImpl> cache = getSharedPreferencesCacheLocked();
// 从file-SharedPreferencesImpl键值对中根据当前file去过去SharedPreferencesImpl实例
sp = cache.get(file);
// 若是没有，那就须要新建一个
if (sp == null) {
// 检查mode，若是是MODE_WORLD_WRITEABLE或者MODE_MULTI_PROCESS则直接抛异常
checkMode(mode);
if (getApplicationInfo().targetSdkVersion >= android.os.Build.VERSION_CODES.O) {
if (isCredentialProtectedStorage()
&& !getSystemService(UserManager.class)
.isUserUnlockingOrUnlocked(UserHandle.myUserId())) {
throw new IllegalStateException("SharedPreferences in credential encrypted "
+ "storage are not available until after user is unlocked");
}
}
// 调用构造方法去构造SharedPreferencesImpl对象
sp = new SharedPreferencesImpl(file, mode);
// 将对象和file的键值对存入cache中
cache.put(file, sp);
return sp;
}
}
if ((mode & Context.MODE_MULTI_PROCESS) != 0 ||
getApplicationInfo().targetSdkVersion < android.os.Build.VERSION_CODES.HONEYCOMB) {
// If somebody else (some other process) changed the prefs
// file behind our back, we reload it. This has been the
// historical (if undocumented) behavior.
sp.startReloadIfChangedUnexpectedly();
}
return sp;
}
/** * 重点1. ContextImap # getSharedPreferencesCacheLocked() * 根据当前的包名，去获取到由此应用建立的File-SharedPreferencesImpl的Map对象， * 而这个对象里面就存放了这个应用建立的全部的SharedPreferencesImpl和File的对应关系 */
@GuardedBy("ContextImpl.class")
private ArrayMap<File, SharedPreferencesImpl> getSharedPreferencesCacheLocked() {
// 若是sSharedPrefsCache为空就构造一个ArrayMap
// sSharedPrefsCache就是一个存放String-String, ArrayMap<File, SharedPreferencesImpl>的Map
// 换句话说，也就是存放包名-packagePrefs对应关系的Map
if (sSharedPrefsCache == null) {
sSharedPrefsCache = new ArrayMap<>();
}
// 获取包名
final String packageName = getPackageName();
// 到sSharedPrefsCache中找
ArrayMap<File, SharedPreferencesImpl> packagePrefs = sSharedPrefsCache.get(packageName);
// 若是找不到，就构建一个而后存进去
if (packagePrefs == null) {
packagePrefs = new ArrayMap<>();
sSharedPrefsCache.put(packageName, packagePrefs);
}
// 找获得就返回
return packagePrefs;
}
复制代码
2.2 构建SharedPreferencesImpl
2.2.1 SharedPreferencesImpl构造方法
咱们先来看下这个类的构造方法：
@UnsupportedAppUsage
SharedPreferencesImpl(File file, int mode) {
mFile = file;
// file的备份文件
mBackupFile = makeBackupFile(file);
mMode = mode;
// 从磁盘加载的标志，当须要从磁盘加载时将其设为true，这样若是有其余线程也调用了SharedPreferences的加载方法时，就会由于其为true而直接返回也就不执行加载方法
// 保证了全局只有一个线程在加载
mLoaded = false;
// SharedPreferences中的数据
mMap = null;
// 保存的错误信息
mThrowable = null;
startLoadFromDisk();
}
复制代码
初始化参数后立马调用了startLoadFromDisk()方法：
2.2.2 startLoadFromDisk()
@UnsupportedAppUsage
private void startLoadFromDisk() {
synchronized (mLock) {
mLoaded = false;
}
// 开启一个新线程来加载数据
new Thread("SharedPreferencesImpl-load") {
public void run() {
loadFromDisk();
}
}.start();
}
复制代码
2.2.3 loadFromDIsk()
loadFromDisk():
private void loadFromDisk() {
synchronized (mLock) {
// 若是已经家在过了，就直接退出
if (mLoaded) {
return;
}
// 若是备份文件已经存在，那就删除源文件，并将备份文件替换为源文件
if (mBackupFile.exists()) {
mFile.delete();
mBackupFile.renameTo(mFile);
}
}
// Debugging
if (mFile.exists() && !mFile.canRead()) {
Log.w(TAG, "Attempt to read preferences file " + mFile + " without permission");
}
// 存储聚的map
Map<String, Object> map = null;
// 文件信息，对应的是C语言stat.h中的struct stat
StructStat stat = null;
Throwable thrown = null;
try {
// 经过文件路径去构建StructStat对象
stat = Os.stat(mFile.getPath());
if (mFile.canRead()) {
// 从XML中把数据读出来，并把数据转化成Map类型
BufferedInputStream str = null;
try {
str = new BufferedInputStream(
new FileInputStream(mFile), 16 * 1024);
map = (Map<String, Object>) XmlUtils.readMapXml(str);
} catch (Exception e) {
Log.w(TAG, "Cannot read " + mFile.getAbsolutePath(), e);
} finally {
IoUtils.closeQuietly(str);
}
}
} catch (ErrnoException e) {
// An errno exception means the stat failed. Treat as empty/non-existing by
// ignoring.
} catch (Throwable t) {
thrown = t;
}
synchronized (mLock) {
mLoaded = true;
mThrowable = thrown;
// It's important that we always signal waiters, even if we'll make
// them fail with an exception. The try-finally is pretty wide, but
// better safe than sorry.
try {
if (thrown == null) {
// 文件里拿到的数据为空就重建，存在就赋值
if (map != null) {
// 将数据存储放置到具体类的一个全局变量中
// 稍微记一下这个关键点
mMap = map;
mStatTimestamp = stat.st_mtim;
mStatSize = stat.st_size;
} else {
mMap = new HashMap<>();
}
}
// In case of a thrown exception, we retain the old map. That allows
// any open editors to commit and store updates.
} catch (Throwable t) {
mThrowable = t;
} finally {
mLock.notifyAll();
}
}
}
复制代码
到目前来讲，就完成的SharedPreferencesImpl的构建过程。
2.3 读数据 SharedPreferences # getXXX()
相对来讲，读数据涉及到的方法比写数据简单得多，因此咱们先来看下读数据： 咱们以getString()为例
2.3.1 getString
@Override
@Nullable
public String getString(String key, @Nullable String defValue) {
synchronized (mLock) {
// 见2.3.2
awaitLoadedLocked();
// 从map中获取数据
String v = (String)mMap.get(key);
// 若是获取到数据，就返回数据，不然返回方法参数中给定的默认值
return v != null ? v : defValue;
}
}
复制代码
2.3.2 awaitLoadedLocked
@GuardedBy("mLock")
private void awaitLoadedLocked() {
// 若是没有加载过，则进行加载
if (!mLoaded) {
// Raise an explicit StrictMode onReadFromDisk for this
// thread, since the real read will be in a different
// thread and otherwise ignored by StrictMode.
BlockGuard.getThreadPolicy().onReadFromDisk();
}
// 若是没有加载过，则等待
while (!mLoaded) {
try {
mLock.wait();
} catch (InterruptedException unused) {
}
}
if (mThrowable != null) {
throw new IllegalStateException(mThrowable);
}
}
复制代码
这个方法简单点来讲就是若是mLoad不为true也就是没有加载完成的话，就等待加载完成。
2.4 写数据
2.4.1 SharedPreferences.Editor
可是光构建了对象还不够，咱们还得能对她进行操做。咱们前面说到过，SharedPreferences并不提供修改的功能，若是你想对她进行修改，必须经过SharedPreferences.Editor来实现。
咱们来看下SharedPreferences.edit():
@Override
public Editor edit() {
// TODO: remove the need to call awaitLoadedLocked() when
// requesting an editor. will require some work on the
// Editor, but then we should be able to do:
//
// context.getSharedPreferences(..).edit().putString(..).apply()
//
// ... all without blocking.
synchronized (mLock) {
// ->>> 重点1
awaitLoadedLocked();
}
// 建立了一个EditorImpl的对象，
// 可是这块须要注意下，咱们想对SharedPreferences进行修改，就必须调用edit()方法，就会去构建一个新的EditorImpl对象
// 因此为了不没必要要的开销，咱们在使用时最好一次性完成对数据的操做
return new EditorImpl();
}
/** * 重点1：SharedPreferencesImpl # awaitLoadedLocked() */
@GuardedBy("mLock")
private void awaitLoadedLocked() {
if (!mLoaded) {
// Raise an explicit StrictMode onReadFromDisk for this
// thread, since the real read will be in a different
// thread and otherwise ignored by StrictMode.
BlockGuard.getThreadPolicy().onReadFromDisk();
}
while (!mLoaded) {
try {
// 若是尚未加载完成，就进入等待状态
mLock.wait();
} catch (InterruptedException unused) {
}
}
if (mThrowable != null) {
throw new IllegalStateException(mThrowable);
}
}
复制代码
2.4.2 EditorImpl
2.4.2.1 putXXX()
那咱们再来看下putXXX()方法，咱们以putString()来举例：
public final class EditorImpl implements Editor {
private final Object mEditorLock = new Object();
// 存数据的HashMap
@GuardedBy("mEditorLock")
private final Map<String, Object> mModified = new HashMap<>();
@GuardedBy("mEditorLock")
private boolean mClear = false;
@Override
public Editor putString(String key, @Nullable String value) {
synchronized (mEditorLock) {
mModified.put(key, value);
return this;
}
}
复制代码
putString()方法很简单，直接将数据put到存数据的HashMap中去就好了。或者说，全部的putXXX()都是这么简单。
可是，若是咱们想将修改提交到SharedPreferences里面去的话，还须要调用apply()或者commit()方法，那咱们如今来看下这两个方法。
2.4.2.2 apply()
@Override
public void apply() {
// 获取当前时间
final long startTime = System.currentTimeMillis();
// 见2.2.3.4
// 构建了一个MemoryCommitResult的对象
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");
}
}
};
// 将awaitCommit添加到Queue的Word中去
QueuedWork.addFinisher(awaitCommit);
Runnable postWriteRunnable = new Runnable() {
@Override
public void run() {
// 执行操做，并从QueuedWord中删除
awaitCommit.run();
QueuedWork.removeFinisher(awaitCommit);
}
};
SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);
// Okay to notify the listeners before it's hit disk
// because the listeners should always get the same
// SharedPreferences instance back, which has the
// changes reflected in memory.
notifyListeners(mcr);
}
复制代码
2.4.2.3 commit()
@Override
public boolean commit() {
long startTime = 0;
if (DEBUG) {
startTime = System.currentTimeMillis();
}
// 见2.2.3.4
// 构建了一个MemoryCommitResult对象
MemoryCommitResult mcr = commitToMemory();
// 将内存数据同步到文件
// 见
SharedPreferencesImpl.this.enqueueDiskWrite(
mcr, null /* sync write on this thread okay */);
try {
// 进入等待状态, 直到写入文件的操做完成
mcr.writtenToDiskLatch.await();
} catch (InterruptedException e) {
return false;
} finally {
if (DEBUG) {
Log.d(TAG, mFile.getName() + ":" + mcr.memoryStateGeneration
+ " committed after " + (System.currentTimeMillis() - startTime)
+ " ms");
}
}
// 通知监听则, 并在主线程回调onSharedPreferenceChanged()方法
notifyListeners(mcr);
// 返回文件操做的结果数据
return mcr.writeToDiskResult;
}
复制代码
2.4.2.4 commitToMemory()
// Returns true if any changes were made
private MemoryCommitResult commitToMemory() {
// 当前Memory的状态，其实也就是当须要提交数据到内存的时候，他的值就加一
long memoryStateGeneration;
List<String> keysModified = null;
Set<OnSharedPreferenceChangeListener> listeners = null;
// 存数据的Map
Map<String, Object> mapToWriteToDisk;
synchronized (SharedPreferencesImpl.this.mLock) {
// We optimistically don't make a deep copy until
// a memory commit comes in when we're already
// writing to disk.
// 若是有数据待被提交到硬盘
if (mDiskWritesInFlight > 0) {
// We can't modify our mMap as a currently
// in-flight write owns it. Clone it before
// modifying it.
// noinspection unchecked
mMap = new HashMap<String, Object>(mMap);
}
mapToWriteToDisk = mMap;
// 2.2.3.5的关键点
mDiskWritesInFlight++;
boolean hasListeners = mListeners.size() > 0;
if (hasListeners) {
keysModified = new ArrayList<String>();
listeners = new HashSet<OnSharedPreferenceChangeListener>(mListeners.keySet());
}
synchronized (mEditorLock) {
boolean changesMade = false;
// 若是mClear为true，就清空mapToWriteToDisk
if (mClear) {
if (!mapToWriteToDisk.isEmpty()) {
changesMade = true;
mapToWriteToDisk.clear();
}
mClear = false;
}
for (Map.Entry<String, Object> e : mModified.entrySet()) {
String k = e.getKey();
Object v = e.getValue();
// "this" is the magic value for a removal mutation. In addition,
// setting a value to "null" for a given key is specified to be
// equivalent to calling remove on that key.
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, keysModified, listeners,
mapToWriteToDisk);
}
复制代码
这段代码刚开始看的时候有点晕，可是看完后就瞬间懂了，这段代码主要执行了一下的功能：
- 将
mMap赋值给mapToWriteToDisk - 当
mClear为true的时候，清空mapToWriteToDisk - 遍历
mModified，mModified也就是咱们上面说到的保存本次edit的数据的HashMap- 当当前的
value为null或者this的时候，移除对应的k
- 当当前的
- 构建了一个
MemoryCommitResult对象
2.4.2.5 SharedPreferencesImpl # enqueueDiskWrite()
private void enqueueDiskWrite(final MemoryCommitResult mcr, final Runnable postWriteRunnable) {
final boolean isFromSyncCommit = (postWriteRunnable == null);
final Runnable writeToDiskRunnable = new Runnable() {
@Override
public void run() {
synchronized (mWritingToDiskLock) {
// 这个方法这块就不讲了，太长了，你们感兴趣能够看下
// 主要功能就是
// 1. 当没有key没有改变，则直接返回了；不然执行下一步
// 2. 将mMap所有信息写入文件，若是写入成功则删除备份文件，若是写入失败则删除mFile
writeToFile(mcr, isFromSyncCommit);
}
synchronized (mLock) {
// 当写入成功后，将标志位减1
mDiskWritesInFlight--;
}
// 此时postWriteRunnable为null不执行该方法
if (postWriteRunnable != null) {
postWriteRunnable.run();
}
}
};
// Typical #commit() path with fewer allocations, doing a write on
// the current thread.
// 若是是commit则进入
if (isFromSyncCommit) {
boolean wasEmpty = false;
synchronized (mLock) {
// 因为commitToMemory会让mDiskWritesInFlight+1，则wasEmpty为true
wasEmpty = mDiskWritesInFlight == 1;
}
if (wasEmpty) {
// 在执行一遍上面的操做，保证将commit的内容也保存
writeToDiskRunnable.run();
return;
}
}
// 若是是apply()方法，则会将任务放入单线程的线程池中去执行
QueuedWork.queue(writeToDiskRunnable, !isFromSyncCommit);
}
复制代码
因此从这个方法咱们能够看到：
commit()是直接同步执行的，有数据就存入磁盘apply()是先将awaitCommit放入QueuedWork，而后在单线程的线程池中去执行，执行完毕后再将awaitCommit从QeueudWork中移除。
3. 知识点
3.1 apply和commit的区别
- apply没有返回值, commit有返回值能知道修改是否提交成功
- apply是将修改提交到内存，再异步提交到磁盘文件; commit是同步的提交到磁盘文件;
- 多并发的提交commit时，需等待正在处理的commit数据更新到磁盘文件后才会继续往下执行，从而下降效率; 而apply只是原子更新到内存，后调用apply函数会直接覆盖前面内存数据，从必定程度上提升不少效率。
3.2 多进程的问题
咱们前面说到了，SP提供了多进程访问，虽然说没有像World模式那样会直接抛异常，可是官方不建议多进程下使用SP。
那么咱们不由会好奇，多进程下访问SP会有什么问题呢？
探究这个问题，咱们得先回到ContextImpl#getSharedPreferences(File file, int mode)方法：
@Override
public SharedPreferences getSharedPreferences(File file, int mode) {
// ...前面的代码省略的，若是你们想回忆下，能够跳转到2.1节
if ((mode & Context.MODE_MULTI_PROCESS) != 0 ||
getApplicationInfo().targetSdkVersion < android.os.Build.VERSION_CODES.HONEYCOMB) {
// If somebody else (some other process) changed the prefs
// file behind our back, we reload it. This has been the
// historical (if undocumented) behavior.
// ->>> 重点1
sp.startReloadIfChangedUnexpectedly();
}
return sp;
}
/** * 重点1 SharedPreferencesImpl # startReloadIfChangedUnexpectedly() */
void startReloadIfChangedUnexpectedly() {
synchronized (mLock) {
// TODO: wait for any pending writes to disk?
// ->>> 重点2
if (!hasFileChangedUnexpectedly()) {
return;
}
// ->>> 重点3
startLoadFromDisk();
}
}
/** * 重点2 SharedPreferencesImpl # hasFileChangedUnexpectedly() * 若是文件发生了预期以外的修改，也就是说有其余进程在修改，就返回true，不然false */
private boolean hasFileChangedUnexpectedly() {
synchronized (mLock) {
// 若是mDiskWritesInFlight大于0，就证实是在当前进程中修改的，那就不用从新读取
if (mDiskWritesInFlight > 0) {
// If we know we caused it, it's not unexpected.
if (DEBUG) Log.d(TAG, "disk write in flight, not unexpected.");
return false;
}
}
final StructStat stat;
try {
/* * Metadata operations don't usually count as a block guard * violation, but we explicitly want this one. */
BlockGuard.getThreadPolicy().onReadFromDisk();
stat = Os.stat(mFile.getPath());
} catch (ErrnoException e) {
return true;
}
synchronized (mLock) {
return !stat.st_mtim.equals(mStatTimestamp) || mStatSize != stat.st_size;
}
}
/** * 重点3 SharedPreferencesImpl # startLoadFromDisk() */
private void startLoadFromDisk() {
synchronized (mLock) {
mLoaded = false;
}
new Thread("SharedPreferencesImpl-load") {
public void run() {
// ->>> 重点4，这块代码能够回到2.2.3看一下
loadFromDisk();
}
}.start();
}
复制代码
咱们能够看到：每次获取SharedPreferences实例的时候尝试从磁盘中加载数据，而且是在异步线程中，所以一个线程的修改最终会反映到另外一个线程，但不能当即反映到另外一个进程，因此经过SharedPreferences没法实现多进程同步。
loadFromDisk()方法中咱们最须要关注的是这一段：
// 若是备份文件已经存在，那就删除源文件，并将备份文件替换为源文件
if (mBackupFile.exists()) {
mFile.delete();
mBackupFile.renameTo(mFile);
}
复制代码
这块判断了mBackupFile是否存在，那mBackupFile咱们是在哪建立的呢？ 整个SharedPreferencesImpl中有两处：
- 构造方法：会调用
makeBackupFile()给传入的file构造一个mBackupFile - writeToFile()：在写入到磁盘的文件时，若是没有
mBackupFile，就会根据当前的mFile重命名为mBackupFile
而writeToFile()在enqueueDiskWrite()中被调用，这个方法太长了，我截取下关键信息：
@GuardedBy("mWritingToDiskLock")
private void writeToFile(MemoryCommitResult mcr, boolean isFromSyncCommit) {
// ...
boolean fileExists = mFile.exists();
// ...
// Rename the current file so it may be used as a backup during the next read
if (fileExists) {
// ...
boolean backupFileExists = mBackupFile.exists();
// ...
if (!backupFileExists) {
if (!mFile.renameTo(mBackupFile)) {
Log.e(TAG, "Couldn't rename file " + mFile
+ " to backup file " + mBackupFile);
mcr.setDiskWriteResult(false, false);
return;
}
} else {
mFile.delete();
}
}
// Attempt to write the file, delete the backup and return true as atomically as
// possible. If any exception occurs, delete the new file; next time we will restore
// from the backup.
try {
FileOutputStream str = createFileOutputStream(mFile);
// ...
XmlUtils.writeMapXml(mcr.mapToWriteToDisk, str);
writeTime = System.currentTimeMillis();
FileUtils.sync(str);
fsyncTime = System.currentTimeMillis();
str.close();
ContextImpl.setFilePermissionsFromMode(mFile.getPath(), mMode, 0);
// ...
try {
final StructStat stat = Os.stat(mFile.getPath());
synchronized (mLock) {
mStatTimestamp = stat.st_mtim;
mStatSize = stat.st_size;
}
} catch (ErrnoException e) {
// Do nothing
}
if (DEBUG) {
fstatTime = System.currentTimeMillis();
}
// Writing was successful, delete the backup file if there is one.
mBackupFile.delete();
// ...
复制代码
因此咱们大体总结下这个方法的功能：
- 若是源文件
mFIle存在而且备份文件mBackupFile不存在，就将源文件重命名为备份文件，若是源文件存在而且备份文件存在，就删除源文件 - 从新建立源文件
mFile，并将内容写进去 - 删除
mBackupFile
结合一下loadFromDisk()和writeToFile()两个方法，咱们能够推测出：当存在两个进程，一个读进程，一个写进程，因为只有在建立SharedPreferencesImpl的时候建立了一个备份进程，此时读进程会将源文件删除，并将备份文件重命名为源文件，这样的结果就是，读进程永远只会看到写以前的内容。而且因为写文件须要调用createFileOutputStream(mFile)，可是这个时候因为源文件被读进程删除了，因此致使写进程的mFIle没有了引用，也就会建立失败，致使修改的数据没法更新到文件上，进而致使数据丢失。
3.3 建议优化
- 不要在SP中存储较大的key或者value
- 只是用MODE_PRIVATE模式，其它模式都不要使用(也被弃用了)
- 能够的话，尽可能获取一次Editor而后提交全部的数据
- 不要高频使用apply，由于他每次都会新建一个线程；使用commit的时需谨慎，由于他在主线程中操做(对，就是主线程，主线程并非只能更新UI，可是仍是就把主线程当作更新UI的为好，咱们的耗时操做最好不要在主线程中)
- 若是须要在多进程中存储数据，建议使用ContentProvider
相关文章
- 1. Android SharedPreferences 源码分析
- 2. SharedPreferences源码之我见
- 3. android之SharedPreferences
- 4. SharedPreferences源码分析
- 5. SharedPreferences源码解析
- 6. Android学习之SharedPreferences
- 7. Android开发之SharedPreferences
- 8. Android之SharedPreferences存储
- 9. 从源码解析-Android数据存储之正确使用SharedPreferences
- 10. Android SharedPreferences
- 更多相关文章...
- • Docker 资源汇总 - Docker教程
- • Java操作Neo4j数据库（附带源码） - NoSQL教程
- • 互联网组织的未来：剖析GitHub员工的任性之源
- • Java Agent入门实战（二）-Instrumentation源码概述
相关标签/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
- 1. CVPR 2020 论文大盘点-光流篇
- 2. Photoshop教程_ps中怎么载入图案？PS图案如何导入？
- 3. org.pentaho.di.core.exception.KettleDatabaseException:Error occurred while trying to connect to the
- 4. SonarQube Scanner execution execution Error --- Failed to upload report - 500: An error has occurred
- 5. idea 导入源码包
- 6. python学习 day2——基础学习
- 7. 3D将是页游市场新赛道？
- 8. osg--交互
- 9. OSG-交互
- 10. Idea、spring boot 图片(pgn显示、jpg不显示)解决方案
欢迎关注本站公众号,获取更多信息
相关文章
- 1. Android SharedPreferences 源码分析
- 2. SharedPreferences源码之我见
- 3. android之SharedPreferences
- 4. SharedPreferences源码分析
- 5. SharedPreferences源码解析
- 6. Android学习之SharedPreferences
- 7. Android开发之SharedPreferences
- 8. Android之SharedPreferences存储
- 9. 从源码解析-Android数据存储之正确使用SharedPreferences
- 10. Android SharedPreferences