写在前面
最近看了不少大牛的推文，再加上最近工作的一些心得，发现做了这么久的Android开发，到最后还是最基础的知识点才是往高级进阶的重中之重。因此也萌生了做一个介绍基础知识的系列文章。目前来说先从support包里的一些控件，工具类开始然后延伸出去。
前几天写项目无意间IDE提示了SharedPreferencesCompat类，然后就多看了两眼...
关于SharedPreferencesCompat
SharedPreferencesCompat是V4包里的类，讲真，这个类并没有什么卵用。它本身对SharedPreferences并没有什么操作，还是需要通过传入SharedPreferences.Editor来实现数据的存储。
既然没有什么卵用，那为什么要出现这么一个鸡肋呢？还得从Editor.apply()和Editor.commit()的区别说起。这个后面再讲，先来看下SharedPreferencesCompat的用法
SharedPreferencesCompat的用法
var editor = getPreferences(Context.MODE_PRIVATE).edit()
editor.putString(DEFAULT_KEY,value_sharedpref.text.toString())
SharedPreferencesCompat.EditorCompat.getInstance().apply(editor)
上面是用kotlin写的，java的实现差不多。可以看到的是，还是需要获取Editor的对象，然后将键值对存放在Editor中，而SharedPreferencesCompat的使用仅仅是代替了最后一步apply或者是commit的操作。那是不是呢？答案是肯定的！
SharedPreferencesCompat源码解析
public void apply(@NonNull SharedPreferences.Editor editor) {
try {
editor.apply();
} catch (AbstractMethodError unused) {
// The app injected its own pre-Gingerbread
// SharedPreferences.Editor implementation without
// an apply method.
editor.commit();
}
}
核心的代码部分就是上面这些了，可以看到，实际上就是先调用了editor.apply()方法，如果发生异常的话，则再调用editor.commit()的方法。简单说就是优先使用apply()方法。
Commit与Apply的对比
在看源码之前，我们先来分别实现下，来看下在时间效率上的差异
commit存储数据
var editor = getPreferences(Context.MODE_PRIVATE).edit()
for (i in 1..1000){
editor.putString(DEFAULT_KEY+i,"value$i")
}
var startTime = System.currentTimeMillis()
editor.commit()
Toast.makeText(this@SharedPreferencesCompatActivity,"commit use time ${System.currentTimeMillis()-startTime}",Toa
apply存储数据
var editor = getPreferences(Context.MODE_PRIVATE).edit()
for (i in 1..1000){
editor.putString(DEFAULT_KEY+i,"value$i")
}
var startTime = System.currentTimeMillis()
editor.apply()
Toast.makeText(this@SharedPreferencesCompatActivity,"apply use time ${System.currentTimeMillis()-startTime}",Toast.LENGTH_LONG).show()
在三星S6 edge plus上对比发现，1000条数据，commit大概需要10ms左右，而apply只需要1ms
居然有将近10倍的差距，那么commit和apply究竟是怎么实现的呢？
源码分析
SharedPreferences本身是一个接口，其实现的代码都在android.app.SharedPreferencesImpl类中，而Editor的实现都在EditorImpl类中，这是SharedPreferencesImpl的内部类。commit 和 apply 函数本身并不复杂，先来看源码：
- commit
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;
}
- apply
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);
}
从上面的实现就可以看出为什么效率有这么大差距了，原因就是commit是同步的，而apply是异步执行的
commit的操作是在主线程中执行的，在enqueueDiskWrite方法中，如果第二个参数为null，并且mDiskWritesInFlight为1的时候，那么写操作则在当前线程中直接完成：
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;
}
}
等写操作完成后再继续下面的步骤通知listener，最后返回写操作成功与否的标记
apply的实现是直接把写任务抛给了子线程，然后就通知listener，然后就没有然后了。所有的写操作都在子线程了，函数并不关心是否成功
这里有个疑问的地方，就是notifyListeners(mcr)。之前一直认为apply的时候，写磁盘和notify是在两个线程同时运行的，应该会出现读取的时候，还没写入的情况；但实际测试中并没有出现这种情况。原因是因为在获取内容值的时候，会先判断当前的SharepdPreferences是否加载，加载了，则直接返回mMap中的值，因为apply函数中在获取MemoryCommitResult的时候，已经把需要修改的值放到mMap中了,因此这个值并没有从磁盘里读出来，而是直接从内存里返回的。
主要的代码如下：
public String getString(String key, @Nullable String defValue) {
synchronized (this) {
awaitLoadedLocked();
String v = (String)mMap.get(key);
return v != null ? v : defValue;
}
}
再看下awaitLoadedLocked()方法里
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 {
wait();
} catch (InterruptedException unused) {
}
}
}
可以看到，如果mLoaded==true的话这个方法是直接跳过的；而mLoaded的赋值是在loadFromDisk()的方法里，而这个在SharedPreferencesImpl初始化的时候，或者在调用getSharedPreferences的时候都会调用的。因此回调里是可以接受到正确的值
总结
- 对于存储结果不需要太关注时，可以使用apply的方法，否则使用commit的方法
- 如果使用apply的方法，则可以考虑使用SharedPreferencesCompat来避免兼容的问题，毕竟apply的方法是API9 才添加的。
