本文主要是介绍再见SharedPreferences，你好MMKV！，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
前言
SharedPreferences是谷歌提供的轻量级存储方案，使用起来比较方便，可以直接进行数据存储，不必另起线程。
不过也带来很多问题，尤其是由SP引起的ANR问题，非常常见。
正因如此，后来也出现了一些SP的替代解决方案，比如MMKV。
本文主要包括以下内容
- SharedPreferences存在的问题
- MMKV的基本使用与介绍
- MMKV的原理
SharedPreferences存在的问题
SP的效率比较低
- 读写方式：直接I/O
- 数据格式：xml
- 写入方式：全量更新
由于SP使用的xml格式保存数据，所以每次更新数据只能全量替换更新数据。
这意味着如果我们有100个数据，如果只更新一项数据，也需要将所有数据转化成xml格式，然后再通过io写入文件中。
这也导致SP的写入效率比较低。
commit导致的ANR
public boolean commit() {
// 在当前线程将数据保存到mMap中
MemoryCommitResult mcr = commitToMemory();
SharedPreferencesImpl.this.enqueueDiskWrite(mcr, null);
try {
// 如果是在singleThreadPool中执行写入操作，通过await()暂停主线程，直到写入操作完成。
// commit的同步性就是通过这里完成的。
mcr.writtenToDiskLatch.await();
} catch (InterruptedException e) {
return false;
}
/*
* 回调的时机：
* 1. commit是在内存和硬盘操作均结束时回调
* 2. apply是内存操作结束时就进行回调
*/
notifyListeners(mcr);
return mcr.writeToDiskResult;
}
如上所示
- commit有返回值，表示修改是否提交成功。
- commit提交是同步的，直到磁盘操作成功后才会完成。
所以当数据量比较大时，使用commit很可能引起ANR。
Apply导致的ANR
commit是同步的，同时SP也提供了异步的apply。
apply是将修改数据原子提交到内存, 而后异步真正提交到硬件磁盘, 而commit是同步的提交到硬件磁盘，因此，在多个并发的提交commit的时候，他们会等待正在处理的commit保存到磁盘后在操作，从而降低了效率。
而apply只是原子的提交到内容，后面有调用apply的函数的将会直接覆盖前面的内存数据，这
这篇关于再见SharedPreferences，你好MMKV！的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
