Android存储之SharedPreferences源码解析
个人博客：haichenyi.com。感谢关注
1. 目录
- 1–目录
- 2–简介
- 3–getSharedPreferences会不会阻塞线程，为什么？
- 4–get操作，为什么有时候会卡顿？
- 5–commit和apply的区别
- 6–sp写入异常会怎么处理？
- 7–优化sp操作
2.简介
从工作开始，Android存储数据最常见的应该就是SharePreference，但是，你真的用懂了吗？源码你看过吗？Google对sp的定位你知道吗？是不是所有数据都应该用sp来存储呢？
为什么现在面试关于sp非常常见呢？不就是一个get，put键值对的东西吗？commit或者apply就提交存储了，这么简单的一个东西，有啥好问的？
腾讯的mmkv，Google的dataSorce又是什么东西呢？
先说说sp，Google对sp的定位是轻量级存储，轻量级是什么意思呢？数据量小，数据量大肯定不建议用，但是，往往很多程序员，不管三七二十一，全都是用sp做本地持久化，导致，或多或少的性能问题，当然，不可否认sp的设计也有它的弊端。
sp 加锁多 xml解析 全量更新 速度慢 性能差 提交数据可能会ANR
3.getSharedPreferences会不会阻塞线程，为什么？
下面从用法一步一步来讲解sp的问题
SharedPreferences sp = getSharedPreferences("haichenyi", MODE_PRIVATE);
上面这个是获取sp，第一个问题就来了，我们都知道获取sp这里是从磁盘读取数据，就是从文件中读取数据，我们一般从文件中读取数据都是要新开线程的，这里没有新开线程，会不会阻塞主线程，为什么？带着这个问题，我们往下走。
这里调用的是base的getSharedPreferences方法，我们看这个base的类型，会发现是Context类型的，Context我们都知道，是装饰者模式，它的实现类ContextImpl，我们到这个类里面区找上面的这个方法，如下图
这个里面逻辑并不复杂，就是一个name在 api19以下的空判断，然后就是file的空判断，用的ArrayMap存储，最后就是调用的重载方法，如下图
重点就是框起来的这里了，SharedPreferences的实现类SharedPreferencesImpl，这里也是装饰者模式(到处都是)。
看到这里就知道了，它的startLoadFromDisk方法，看名字就知道是从磁盘读取数据，这里有个synchronized锁,锁对象是mLock，这个mLock比较重要。里面有一个mLoaded的Boolean类型的值，它也比较重要。下面具体读数据的逻辑，loadFromDisk是新开线程读取的。
所以，我们回到前面的问题会不会阻塞线程？虽然，它是同步返回的sp对象，但是，具体读数据的逻辑是新开线程的，所以，不会阻塞线程。
4.get操作，为什么有时候会卡顿？
会卡顿吗？怎么没有碰到过呢？答案是肯定的，肯定会有卡顿的情况，这是为什么呢？我们来看看它的实现：
我们来看看这个getXXX这一系列的方法，里面都有同步锁，然后，都有一个awaitLoadedLocked方法，重点就是这个方法，看名字就知道：等待加载锁。什么意思呢？我们看一下具体实现
private void awaitLoadedLocked() {
...
//while循环，当mLoaded为false的时候进入while
while (!mLoaded) {
try {
//wait方法
mLock.wait();
} catch (InterruptedException unused) {
}
}
...
}
这里有一个while循环，判断的就是上面我们提到过的mLoaded，然后，里面就是我们上面也提到过的mLock对象，mLock.wait()方法。
当代码执行到这里的时候，如果mLoaded是false，就会进入while循环，然后，会调用mLoack的wait方法，进入等待状态。
那，这个mLoaded的值又是在哪里修改的呢？mLock对象是时候唤醒呢？
我们回到上面说的，新开线程执行loadFromDisk方法
private void loadFromDisk() {
...
//开始从文件读取数据
Map map = null;
StructStat stat = null;
Throwable thrown = null;
try {
stat = Os.stat(mFile.getPath());
if (mFile.canRead()) {
BufferedInputStream str = null;
try {
str = new BufferedInputStream(
new FileInputStream(mFile), 16 * 1024);
//把数据赋值给map
map = (Map) 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的值
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
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
mLock.notifyAll();
}
}
}
源码里面注释都写的比较清楚。mLoaded值的修改是在从磁盘中把数据读取完之后，然后，在finally里面调用notifyAll唤醒mLock。
数据读完之后，修改boolean值，然后，在finally里面唤醒，finally是try-catch最后执行的。
为什么会卡顿呢？我们平时用sp，是不是像下面这样用的：
//这里是直接返回对象，
//但是，它实际上数据量大的时候，是需要时间去从磁盘读数据的
SharedPreferences sp = getSharedPreferences("haichenyi", MODE_PRIVATE);
//当代码执行到这里的时候，我们虽然，拿到了sp对象，
//但是，数据可能没有读取完，上面说的boolean的值，还是false，
//就进入while循环，调用awit方法，进入等待状态
//然后，过一会从磁盘读取完数据，修改boolean值为true，在finally调用notifyAll唤醒mLock
//然后，唤醒了while循环，boolean的值这个时候是true，跳出while循环
//所以，这个卡顿的时间，就是从磁盘读取数据的时间
String s = sp.getString("xxx","aaa");
上面代码的注释写的很清楚了吧？不用在做过多的解释了吧？
PS:它这个卡顿仅限于第一次，为什么呢？因为它从磁盘读出数据之后，把数据存到内存中了（也就是loadFromDisk方法中的mMap对象），我在那里加了注释，可以去看一下。读取数据都是从这个mMap对象返回的，也就是从内存中返回，这也是为什么从另一方面说，sp返回数据比较快的原因。它都是从内存中返回的，并不是每次都是从磁盘读数据，然后返回的。
5.commit和apply的区别
先说结论：
| 类型 | 返回值 | 同步 | ANR |
|---|---|---|---|
| commit | 有 | 同步提交 | 可能会 |
| apply | 无 | 异步提交 | 可能会 |
我们一个一个来慢慢说这个结论：
是否有返回值
这个很简单吧？用过如果没注意，可能不知道，因为，我们平时也不用处理这些东西，我们来看一下源码就知道了。
//看到这个方法有返回值就知道了，boolean类型的返回值
public boolean commit() {
...
//为什么说每次都是全量更新，就在这里，这个commitToMemory方法里面，
//它每次都会把内存的map数据全部都更新好
MemoryCommitResult mcr = commitToMemory();
//然后通过这个enqueueDisk方法全部都重新写到硬盘上
//第二个参数是null，它的注释也比较清楚
SharedPreferencesImpl.this.enqueueDiskWrite(
mcr, null /* sync write on this thread okay */);
try {
//然后，写入等待
mcr.writtenToDiskLatch.await();
} catch (InterruptedException e) {
return false;
} finally {
...
}
notifyListeners(mcr);
//返回写入结果
return mcr.writeToDiskResult;
}
//这个方法没有返回值
public void apply() {
...
}
我们先说返回值的问题，上面这两个方法就是commit和apply的大致结构。所以，commit是有个boolean类型的返回值，apply是没有返回值的
是否有同步
这个问题，上面commit的源码注释那里已经解释清楚了，它会有一个wait方法等待数据更新完，所以commit是同步的。
我们再来看看apply方法，上面主要是说返回值的问题，所以，没有把apply的源码贴出来，下面我们来看看apply的源码
public void apply() {
final long startTime = System.currentTimeMillis();
final MemoryCommitResult mcr = commitToMemory();
//重点就是这里，它这里是新建了一个runnable来执行await方法，
//上面commit方法是直接在当前线程执行的
final Runnable awaitCommit = new Runnable() {
@Override
public void run() {
try {
mcr.writtenToDiskLatch.await();
} catch (InterruptedException ignored) {
}
...
}
};
//然后调用了QueuedWork.addFinisher,把这个runnable传了进去
//这个QueuedWork是什么呢？下面我贴出来了这个方法，addFinisher
QueuedWork.addFinisher(awaitCommit);
//上面其实就是把runnable加到了一个队列当中
//又新开了一个runnable执行了上面runnable的run方法，
//这是什么意思还要我做过多的解释吗？runnable.run()
Runnable postWriteRunnable = new Runnable() {
@Override
public void run() {
awaitCommit.run();
QueuedWork.removeFinisher(awaitCommit);
}
};
//回过头看看，commit的这个方法，第二个参数是null，上面我特意做了解释的。
//看这里，第二个参数，传的runnable
//就是在runnable的线程里面执行
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);
}
@UnsupportedAppUsage
public static void addFinisher(Runnable finisher) {
synchronized (sLock) {
//等于，就是把我们的runnable给add到了sFinishers，这个sFinishers又是什么呢？
sFinishers.add(finisher);
}
}
//没错，它其实就是一个队列，再回到上面
private static final LinkedList sFinishers = new LinkedList<>();
我这里的源码解释的是比较清楚的了吧？所以，apply是异步的。
是否会ANR
说到ANR，我们先来聊一下ANR，什么是ANR？多长时间会造成ANR提示？
ANR：Android系统是消息驱动的，每个消息都需要在一定的时间范围内处理完，如果在规定的时间内未处理完，系统就会提示ANR异常
那么，这个时间是怎么限定的呢？
| 类型 | Service | Broadcast | Activity | ContentProvider |
|---|---|---|---|---|
| 前台(单位：s) | 20 | 10 | 5 | 10 |
| 后台(单位：s) | 20*10 | 60 | - | - |
前两个都好理解，这个ANR就很难理解了，commit是同步提交，可能会ANR我可以理解，sp每次都是全量更新，commit又是在主线程提交，cpu峰值的时候，数据量大，可能就会卡住主线程，造成ANR。
辣么，问题就来了，commit同步卡能会卡住主线程，造成ANR，apply是异步的呀？为什么apply也会造成ANR呢？是结论错了吗？
龙儿筝给我说了一个结论：Google认为SP是数据持久化，数据的安全性要大于页面的行为，当页面离开时，会等待持久化完成。
这个结论怎么理解呢？有一个场景，当你调用apply去更新数据，然后，紧接着下一行代码就执行了finish方法，或者跳转了下一个界面，此时会怎么样呢？
我们先来简单聊一聊activity启动相关的问题
简单的从AMS开始说两句吧，当zygote进程启动了系统主要的服务之后，里面就有一个AMS(ActivityManagerService)，AMS通过Binder创建了ActivityThread，然后通过handler开始发消息，创建Activity，我们activity的生命周期的回调，都说是系统调用了，系统是怎么调用的呢？都是通过handler发送一个一个的消息，然后去执行对应的回调方法。
然后，再是，我们常说的onCreate—onStart(可见，不能与用户交互)—onResume(可见，与用户交互)—activity running—onPause—onStop—onDestroy
除了activity running，其余的每一种生命周期都对应着一个handler的message。handler的机制，在我的博文深入理解handler机制里面讲的很清楚了
辣么，从Activity A跳转Activity B，两个activity的生命周期是怎么变化的呢？
当A中启动B，生命周期的流程是这样的：
- A的onPause
- B的onCreate-onStart-onResume
- A的onStop
扯了这么远，回到上面说的apply的问题，为什么它会ANR线程呢？
问题就出在这个A的onStop方法里面，我们来看看这个onStop放的源码：
如上图，我们通过handler发送消息，最终定位到执行的是这一块的代码，看到我框起来的代码了吗？
// Make sure any pending writes are now committed.
//看这个注释写的，确认没有正在写入的操作，就是这个waitToFinish方法，
//这个if判断，可以看实现，只要taget小于11判断就是true，我们现在都是大于11了，所以，这里是false
//然后，前面取了一个非，所以，我们现在这里能进去
//如果要是小于11呢？看activity的onPause方法里面，你会有新发现
if (!r.isPreHoneycomb()) {
QueuedWork.waitToFinish();
}
上面的注释很清楚了，这个waitToFinish方法里面的逻辑是什么样的呢？大致贴一下主要的逻辑：
public static void waitToFinish() {
...
try {
//while循环
while (true) {
Runnable finisher;
synchronized (sLock) {
//从sFinishers队列中取出runnable
finisher = sFinishers.poll();
}
if (finisher == null) {
//空(队列中没有数据了)就中止while循环
break;
}
//执行runnable
finisher.run();
}
} finally {
sCanDelay = true;
}
...
}
我们想想之前apply方法里面，是不是新建的runnable，然后，把这个runnable是不是添加到sFinishers队列中去了？
所以，整个逻辑就是
- 你在Activity A中apply之后(假设数据量大)，立马跳转Activity B
- 当Activity B正常启动完，走完它自己的onResume方法，执行了Activity A的onStop方法
- 执行的时候发现，QueueWork里面还有提交正在执行，就会等待它执行完，就会阻塞当前线程
6.sp写入异常会怎么处理？
在代码执行getSharedPreferences的时候，你会发现，磁盘上会多一个同名文件，扩展名不一样，扩展名是 点bak,这个文件是备份文件。写入成功就会删除这个文件，写入失败，下次就会用这个备份文件。
我们再来找一下源码你会发现：
static File makeBackupFile(File prefsFile) {
return new File(prefsFile.getPath() + ".bak");
}
这个方法在哪调用的呢？在SharedPreferencesImpl的构造方法里面
SharedPreferencesImpl(File file, int mode) {
mFile = file;
//就是这个变量
mBackupFile = makeBackupFile(file);
...
}
我们再来看看这个写入方法，你会发现，在写入完成之后，会把这个文件删除
private void writeToFile(MemoryCommitResult mcr, boolean isFromSyncCommit) {
...
// 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);
if (DEBUG) {
outputStreamCreateTime = System.currentTimeMillis();
}
if (str == null) {
mcr.setDiskWriteResult(false, false);
return;
}
XmlUtils.writeMapXml(mcr.mapToWriteToDisk, str);
writeTime = System.currentTimeMillis();
FileUtils.sync(str);
fsyncTime = System.currentTimeMillis();
str.close();
ContextImpl.setFilePermissionsFromMode(mFile.getPath(), mMode, 0);
if (DEBUG) {
setPermTime = System.currentTimeMillis();
}
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();
...
}
7.优化sp操作
- sp获取的时候，会新开线程去读取数据，我们可以提前读取sp，不要每次到用的时候，再去读取。
- sp每次提交都是全量更新，不要每次修改了就直接提交，可以多修改几次之后，一起提交
- sp是轻量级存储，数据量大，不要存sp
- sp的内容不要太多，sp内容过多，读取的时候会非常慢，可以适当的拆分sp的内容，分多个sp存储，但是也不要太多
但是，这些优化操作，都是基于sp原有的性能做的优化操作，不能从根本上解决问题。
sp的源码就说完了，为什么Google更新了十多版本之后的sp，最终还是放弃维护了？而是新出推出了Jetpack的组件之一DataStore这是人性的扭曲还是道德的沦丧，我们且听下回分解。
下一篇来聊聊MMKV，它是怎么从根本上解决问题的。