你真的了解SharedPreferences吗
本篇将从源码角度带大家分析一下Android中常用的轻量级数据存储工具SharedPreferences，以及SharedPreferences在多进程下的一些坑。
阅读本文大概需要5分钟。
本文已授权微信公众号：鸿洋（hongyangAndroid）原创首发。
SharedPreferences踩坑
在日常开发中SharedPreferences想必肯定是经常被我们使用的了，通常情况下使用它并不会发生什么问题，但是假如遇到了在不同进程中使用SharedPreferences（例如指定了process的activity/service），那坑就来了。
这里我们可以实验一下，创建两个Activity，在AndroidManifest其中一个将其process指定为second进程
<activity android:name=".MainActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
<activity android:name=".SecondActivity"
android:process=":second"/>
MainActivity
public class MainActivity extends AppCompatActivity {
private TextView tvResult;
private EditText etInput;
private Button btnChange;
private Button btnJump;
private SharedPreferences sharedPreferences;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
sharedPreferences = PreferenceManager.getDefaultSharedPreferences(this);
setContentView(R.layout.activity_main);
tvResult = (TextView) findViewById(R.id.tv_result);
tvResult.setText(sharedPreferences.getString("test", "I am default"));
etInput = (EditText) findViewById(R.id.et_input);
btnChange = (Button) findViewById(R.id.btn_change);
btnChange.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
sharedPreferences.edit().putString("test", etInput.getText().toString()).commit();
tvResult.setText(sharedPreferences.getString("test", "I am default"));
}
});
btnJump = (Button) findViewById(R.id.btn_jump);
btnJump.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
startActivity(new Intent(MainActivity.this, SecondActivity.class));
}
});
}
}
代码比较简单，就是将输入框的内容存入到SharedPreferences中，并显示到TextView上，点击跳转按钮跳转到SecondActivity
SecondActivity
public class SecondActivity extends AppCompatActivity {
private TextView tvResult;
private Button btnGetResult;
private SharedPreferences sharedPreferences;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_second);
sharedPreferences = PreferenceManager.getDefaultSharedPreferences(this);
tvResult = (TextView) findViewById(R.id.tv_result);
btnGetResult = (Button) findViewById(R.id.btn_getResult);
btnGetResult.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
tvResult.setText(sharedPreferences.getString("test", "I am default"));
}
});
}
}
SecondActivity就是点击按钮获取SharedPreferences的值并显示到TextView，不过这里要注意它是运行在不同的进程中的。
MainActivity
这里我们将值改为hello，然后点击修改，可以看到SharedPreferences的值已经改成功了。然后我们跳转到SecondActivity并获取值，
SecondActivity
一切正常，好现在我们回到MainActivity，并再次修改SharedPreferences中的值，
MainActivity
可以看到SharedPreferences的值已经再次被修改成功，这时我们再跳转到SecondActivity并获取值，
SecondActivity
不管怎么获取都是之前的值，然后重启app，再进入SecondActivity，便又能获取到正确的值了。
SecondActivity(重启app后)
这里我们先总结一下结论
- 先启动主进程并获取SharedPreferences对象，然后启动其他进程并获取SharedPreferences对象，那么此时对SharedPreferences的数值进行修改均不能对其他进程产生作用。
- 先启动主进程并获取SharedPreferences对象，然后对值进行修改，然后启动其他进程并获取SharedPreferences对象，能取得修改后的值，但此时如果再对此值进行修改，均不能对其他进程产生作用。
总结下来就是，其他进程在启动时获取到的SharedPreferences的值只能是这个进程启动前这个值的最后值，即在进程启动后对值的修改只对当前进程有效，须等到进程重启或者app重启才能与其他进程进行“同步”。这里即使把获取SharedPreferences对象的模式改为MODE_MULTI_PROCESS，或者系统版本是Android 3.0以下，也仅仅是在重新获取SharedPreferences对象时能够得到正确的值，即每次不同进程间对SharedPreferences的值进行修改，均需要重新获取SharedPreferences对象才能够使其正常。
那么为什么会这样子呢，笔者带大家从源码的角度来分析一下，我们来看一下关于SharedPreferences的源码
源码分析
通常我们获取SharedPreferences对象一般是这样
SharedPreferences sharedPreferences = PreferenceManager.getDefaultSharedPreferences(this);
//或者这样
SharedPreferences sharedPreferences = getSharedPreferences("name", Context.MODE_PRIVATE);
实际上PreferenceManager.getDefaultSharedPreferences(context)方法也是对getSharedPreferences做了封装
public static SharedPreferences getDefaultSharedPreferences(Context context) {
return context.getSharedPreferences(getDefaultSharedPreferencesName(context),
getDefaultSharedPreferencesMode());
}
所以不管通过哪种方式，最终都是通过Context中的getSharedPreferences方法来获取SharedPreferences对象，在Context中，getSharedPreferences方法是一个抽象方法，没有具体实现。
public abstract SharedPreferences getSharedPreferences(String name, int mode);
我们知道Context的实现类其实就是ContextImpl，所以这里我们直接去到ContextImpl的getSharedPreferences方法中，
@Override
public SharedPreferences getSharedPreferences(String name, int mode) {
// 如果传入null，将文件名给为"null"，即最后会是null.xml
if (mPackageInfo.getApplicationInfo().targetSdkVersion <
Build.VERSION_CODES.KITKAT) {
if (name == null) {
name = "null";
}
}
File file;
synchronized (ContextImpl.class) {
if (mSharedPrefsPaths == null) {
mSharedPrefsPaths = new ArrayMap<>();
}
file = mSharedPrefsPaths.get(name);
if (file == null) {
file = getSharedPreferencesPath(name);
mSharedPrefsPaths.put(name, file);
}
}
return getSharedPreferences(file, mode);
}
@Override
public File getSharedPreferencesPath(String name) {
return makeFilename(getPreferencesDir(), name + ".xml");
}
这里比较简单，先判断了ArrayMap中是否存在该File对象，不存在则创建一个并放入ArrayMap，然后调用getSharedPreferences的重载方法getSharedPreferences(file, mode)，我们看一下这个方法的源码
@Override
public SharedPreferences getSharedPreferences(File file, int mode) {
checkMode(mode);
SharedPreferencesImpl sp;
synchronized (ContextImpl.class) {
//查看缓存中是否存在SharedPreferencesImpl对象，若存在直接返回
final ArrayMap<File, SharedPreferencesImpl> cache = getSharedPreferencesCacheLocked();
sp = cache.get(file);
if (sp == null) {
sp = new SharedPreferencesImpl(file, mode);
cache.put(file, sp);
return sp;
}
}
//若Android版本小于3.0或者mode为MODE_MULTI_PROCESS，则调用startReloadIfChangedUnexpectedly方法重新读取磁盘文件
if ((mode & Context.MODE_MULTI_PROCESS) != 0 ||
getApplicationInfo().targetSdkVersion < android.os.Build.VERSION_CODES.HONEYCOMB) {
sp.startReloadIfChangedUnexpectedly();
}
return sp;
}
private ArrayMap<File, SharedPreferencesImpl> getSharedPreferencesCacheLocked() {
//以包名为key进行缓存ArrayMap，存在则直接return
if (sSharedPrefsCache == null) {
sSharedPrefsCache = new ArrayMap<>();
}
final String packageName = getPackageName();
ArrayMap<File, SharedPreferencesImpl> packagePrefs = sSharedPrefsCache.get(packageName);
if (packagePrefs == null) {
packagePrefs = new ArrayMap<>();
sSharedPrefsCache.put(packageName, packagePrefs);
}
return packagePrefs;
}
private void checkMode(int mode) {
//在Android 7.0以上若允许外部读写将直接抛出异常
if (getApplicationInfo().targetSdkVersion >= Build.VERSION_CODES.N) {
if ((mode & MODE_WORLD_READABLE) != 0) {
throw new SecurityException("MODE_WORLD_READABLE no longer supported");
}
if ((mode & MODE_WORLD_WRITEABLE) != 0) {
throw new SecurityException("MODE_WORLD_WRITEABLE no longer supported");
}
}
}
可以看到，这里将SharedPreferences的实例对象SharedPreferencesImpl缓存起来，以后每次获取如果内存中已经存在那么直接返回，如果不存在才会进行重新创建，那么这里我们可以有个猜想，即是否只有在创建SharedPreferences对象的时候才会从磁盘中进行读取，读取后的值保存在了内存中，获取SharedPreferences对象优先从缓存中获取，再次创建时才会重新从磁盘中再次读取文件。
我们直接看一下SharedPreferencesImpl的源码，验证一下我们的猜想。
//SharedPreferencesImpl的构造方法
SharedPreferencesImpl(File file, int mode) {
mFile = file;
mBackupFile = makeBackupFile(file);
mMode = mode;
mLoaded = false;
mMap = null;
startLoadFromDisk();
}
private void startLoadFromDisk() {
synchronized (this) {
mLoaded = false;
}
new Thread("SharedPreferencesImpl-load") {
public void run() {
loadFromDisk();
}
}.start();
}
可以看到，在SharedPreferencesImpl的构造方法中调用了startLoadFromDisk，startLoadFromDisk方法中开启了一个线程加载磁盘中的文件，loadFromDisk源码如下
private void loadFromDisk() {
//若已经在加载，直接return
synchronized (SharedPreferencesImpl.this) {
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 = null;
StructStat stat = null;
try {
stat = Os.stat(mFile.getPath());
if (mFile.canRead()) {
BufferedInputStream str = null;
try {
str = new BufferedInputStream(
new FileInputStream(mFile), 16*1024);
//使用XmlUtils将xml文件读取后转成一个map对象
map = XmlUtils.readMapXml(str);
} catch (XmlPullParserException | IOException e) {
Log.w(TAG, "getSharedPreferences", e);
} finally {
IoUtils.closeQuietly(str);
}
}
} catch (ErrnoException e) {
/* ignore */
}
synchronized (SharedPreferencesImpl.this) {
//加载完成，状态更新
mLoaded = true;
if (map != null) {
//将map对象赋值给成员变量mMap
mMap = map;
mStatTimestamp = stat.st_mtime;
mStatSize = stat.st_size;
} else {
mMap = new HashMap<>();
}
notifyAll();
}
}
看到这里，已经逐步验证了我们之前的猜想，在构造方法中读取了磁盘文件的内容并赋值给了成员变量mMap集合，我们只需要看看所有的get方法是不是从mMap成员变量中获取值就能完全验证我们的猜想是否正确，因为get方法都大同小异，所以我们就只分析一下getString方法就可以了。
@Nullable
public String getString(String key, @Nullable String defValue) {
synchronized (this) {
//这个方法只要判断是否加载xml文件完毕，防止加载未完成就调用了getString方法
awaitLoadedLocked();
String v = (String)mMap.get(key);
return v != null ? v : defValue;
}
}
可以看到，果然是这样的，从mMap集合中直接取出值进行返回，那么看到这里肯定会有个疑问，为什么在同个进程却又没有问题呢，或者其他进程对SharedPreferences的获取在值修改完毕之后也没有问题，这里我们看一下SharedPreferencesImpl的内部类EditorImpl的源码，EditorImpl是Editor的实现类。
public final class EditorImpl implements Editor {
private final Map<String, Object> mModified = Maps.newHashMap();
private boolean mClear = false;
public Editor putString(String key, @Nullable String value) {
synchronized (this) {
mModified.put(key, value);
return this;
}
}
...
public void apply() {
final MemoryCommitResult mcr = commitToMemory();
final Runnable awaitCommit = new Runnable() {
public void run() {
try {
mcr.writtenToDiskLatch.await();
} catch (InterruptedException ignored) {
}
}
};
QueuedWork.add(awaitCommit);
Runnable postWriteRunnable = new Runnable() {
public void run() {
awaitCommit.run();
QueuedWork.remove(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);
}
public boolean commit() {
MemoryCommitResult mcr = commitToMemory();
SharedPreferencesImpl.this.enqueueDiskWrite(
mcr, null /* sync write on this thread okay */);
try {
mcr.writtenToDiskLatch.await();
} catch (InterruptedException e) {
return false;
}
notifyListeners(mcr);
return mcr.writeToDiskResult;
}
...
可以看到，EditorImpl内部有一个mModified的Map成员变量，我们所有的修改在调用了commit或者apply方法后才会执行保存，可以看到，不管调用哪个方法都会调用commitToMemory()和enqueueDiskWrite方法，那么我们看一下这两个方法的源码
private MemoryCommitResult commitToMemory() {
MemoryCommitResult mcr = new MemoryCommitResult();
synchronized (SharedPreferencesImpl.this) {
if (mDiskWritesInFlight > 0) {
//对mMap进行扩容
mMap = new HashMap<String, Object>(mMap);
}
mcr.mapToWriteToDisk = mMap;
mDiskWritesInFlight++;
//判断是否有注册监听者
boolean hasListeners = mListeners.size() > 0;
if (hasListeners) {
mcr.keysModified = new ArrayList<String>();
mcr.listeners =
new HashSet<OnSharedPreferenceChangeListener>(mListeners.keySet());
}
synchronized (this) {
if (mClear) {
if (!mMap.isEmpty()) {
mcr.changesMade = true;
mMap.clear();
}
mClear = false;
}
for (Map.Entry<String, Object> e : mModified.entrySet()) {
//将值添加到SharedPreferences的成员变量mMap中去
String k = e.getKey();
Object v = e.getValue();
if (v == this || v == null) {
if (!mMap.containsKey(k)) {
continue;
}
mMap.remove(k);
} else {
if (mMap.containsKey(k)) {
Object existingValue = mMap.get(k);
if (existingValue != null && existingValue.equals(v)) {
continue;
}
}
mMap.put(k, v);
}
mcr.changesMade = true;
if (hasListeners) {
mcr.keysModified.add(k);
}
}
mModified.clear();
}
}
return mcr;
}
其实通过方法名我们也可以猜到，就是将值提交到内存，从代码上也可以看出来，就是将Editor的所有put进去的值添加到SharedPreferences的mMap成员变量中。
那么最后将内容写入磁盘的方法就是enqueueDiskWrite了，我们看一下它的源码
private void enqueueDiskWrite(final MemoryCommitResult mcr,
final Runnable postWriteRunnable) {
final Runnable writeToDiskRunnable = new Runnable() {
public void run() {
synchronized (mWritingToDiskLock) {
writeToFile(mcr);
}
synchronized (SharedPreferencesImpl.this) {
mDiskWritesInFlight--;
}
if (postWriteRunnable != null) {
postWriteRunnable.run();
}
}
};
final boolean isFromSyncCommit = (postWriteRunnable == null);
// Typical #commit() path with fewer allocations, doing a write on
// the current thread.
if (isFromSyncCommit) {
boolean wasEmpty = false;
synchronized (SharedPreferencesImpl.this) {
wasEmpty = mDiskWritesInFlight == 1;
}
if (wasEmpty) {
writeToDiskRunnable.run();
return;
}
}
QueuedWork.singleThreadExecutor().execute(writeToDiskRunnable);
}
源码比较简单，其中最主要的就是区分了apply方法调用和commit的调用,apply调用的话会将写入磁盘的任务加入到一个线程池中在后台运行，直接commit的话则会在当前线程进行写入。
总结
整个获取SharedPreferences对象过程的流程图如下
流程图
Android的SharedPreferences采用了这种模式，主要还是为了防止频繁通过IO读取磁盘带来的性能开销，毕竟SharedPreferences还是比较常用的，如果实时去磁盘文件进行读取，那么在性能上肯定有不容忽视的影响。同时，MODE_MULTI_PROCESS的模式也已经被Google弃用，多进程之间的数据共享Google不推荐我们使用SharedPreferences，而是使用例如ContentProvider这种方式。因为多个进程同时对一个文件进行修改，也有可能导致文件丢失等异常情况，同时，通过源码我们发现，如果对存储的成功与否的结果并不关心的话，使用apply方法进行提交可以在性能上有一定的优化，因为apply方法是在线程池进行文件的写入，而commit方法则是直接在当前线程进行文件的写入的。
如果觉得对你有所帮助，请点个赞，谢谢。你的鼓励是我最大的动力。
欢迎关注EoniJJ的简书
不定期与你分享关于Android开发的点点滴滴。
