Android 之不要滥用 SharedPreferences（

闪存

Android 存储优化系列专题

• SharedPreferences 系列

《Android 之不要滥用 SharedPreferences》
《Android 之不要滥用 SharedPreferences（2）— 数据丢失》

• ContentProvider 系列（待更）

《Android 存储选项之 ContentProvider 启动过程源码分析》
《Android 存储选项之 ContentProvider 深入分析》

• 对象序列化系列

《Android 对象序列化之你不知道的 Serializable》
《Android 对象序列化之 Parcelable 深入分析》
《Android 对象序列化之追求完美的 Serial》

• 数据序列化系列（待更）

《Android 数据序列化之 JSON》
《Android 数据序列化之 Protocol Buffer 使用》
《Android 数据序列化之 Protocol Buffer 源码分析》

• SQLite 存储系列

《Android 存储选项之 SQLiteDatabase 创建过程源码分析》
《Android 存储选项之 SQLiteDatabase 源码分析》
《数据库连接池 SQLiteConnectionPool 源码分析》
《SQLiteDatabase 启用事务源码分析》
《SQLite 数据库 WAL 模式工作原理简介》
《SQLite 数据库锁机制与事务简介》
《SQLite 数据库优化那些事儿》

---

在上篇《Android 之不要滥用 SharedPreferences》一文，详细为大家分析了关于 SharedPreferences 存储机制以及对它的不当使用，可能引发的“严重后果”。本文也是建立在该基础之上进一步对 SharedPreferences 可能导致数据丢失场景进行分析。如果你对 SharedPreferences 机制还不熟悉的话，可以先去参考下。

先来简单回顾下：SharedPreferences 是 Android 中比较常用的存储方法，它可以用来存储一些比较小的键值对集合。虽然 SharedPreferences 使用非常简便，但也是我们诟病比较多的存储方法。它的性能问题比较多，我可以轻松说出它的“几宗罪”。

1. 跨进程不安全。由于没有使用跨进程的锁，就算使用 MODE_MULTI_PROCESS，SharedPreferences 在跨进程频繁读写有可能导致数据全部丢失。根据线上统计，SharedPreferences 大约会有万分之一的损坏率。

2. 加载缓慢。SharedPreferences 文件的加载使用了异步线程，而且加载线程并没有设置优先级，如果这个时候读取数据就需要等待文件加载线程的结束。这就导致主线程等待低优先线程锁的问题，比如一个 100KB 的 SP 文件读取等待时间大约需要 50 ~ 100ms，并且建议大家提前用预加载启动过程用到的 SP 文件。

3. 全量写入。无论是 commit() 还是 apply()，即使我们只改动其中一个条目，都会把整个内容全部写到文件。而且即使我们多次写同一个文件，SP 也没有将多次修改合并为一次，这也是性能差的重要原因之一。

4. 卡顿。由于提供了异步落盘的 apply 机制，在崩溃或者其它一些异常情况可能会导致数据丢失。所以当应用收到系统广播，或者被调用 onPause 等一些时机，系统会强制把所有的 SharedPreferences 对象的数据落地到磁盘。如果没有落地完成，这时候主线程会被一直阻塞。这样非常容易造成卡顿，甚至是ANR，从线上数据来看 SP 卡顿占比一般会超过 5%。

坦白来讲，系统提供的 SharedPreferences 的应用场景是用来存储一些非常简单、轻量的数据。我们不要使用它存储过于复杂的数据，例如 HTML、JSON 等。而且 SharedPreferences 的文件存储性能与文件大小有关，每个 SP 文件不能过大，我们不要将毫无关联的配置项保存在同一个文件中，同时考虑将频繁修改的条目单独隔离出来。

数据丢失分析

SharedPrefenerces 提供了线程安全操作（内部有大量Synchronized方法），但是并不能保证跨进程数据的安全，也就是在跨进程访问时可能会导致文件损坏（但并不局限于多进程场景）。

1、疑问：文件为什么会损坏？

为什么会文件损坏？在回答该问题之前先要明确一下什么是文件损坏？一个文件的格式或者内容，如果没有按照应用程序写入的结果都属于文件损坏。它不只是文件格式错误，文件内容丢失可能才是最常出现的，SharedPreferences 跨进程读写就非常容易出现数据丢失的情况。

我们可以从应用程序、文件系统和磁盘三个角度来审视这个问题。

• 应用程序。大部分的 I/O 方法都不是原子操作的，文件的跨进程或者多线程写入、使用一个已经关闭的文件描述符 fd 来操作文件，它们都有可能导致数据被覆盖或者删除。事实上，大部分的文件损坏都是因为应用程序代码设计考虑不当导致的，并不是文件系统或者磁盘的问题。

• 文件系统。虽说内核崩溃或者系统突然断电都有可能导致文件系统损坏，不过文件系统也做了很多的保护措施。例如 system 分区保证只读不可写，增加异常检查和恢复机制等。

在文件系统这一层，更多是因为断电而导致的写入丢失。为了提升 I/O 性能，文件系统把数据写入到 Page Cache 中，然后等待合适的时机才会真正的写入磁盘。当然我们也可以通过 fsync、msync 这些接口强制写入磁盘。（SharedPreferences 在落盘时就使用了sync 机制）

• 磁盘。手机上使用的闪存是电子式的存储设备，所以资料传输过程可能会发生电子遗失等现象导致数据错误。不过闪存也会使用 ECC、多级编码等方式增加数据的可靠性，一般来说出现这种情况的可能性比较小。

接下来还是结合源码的角度与大家一起重点探讨下 SharedPreferences 的落盘机制：

2、SharedPreferences 的备份文件

再回顾下我们通过 Context.getSharedPreferences(name)，得到的实际类型是：SharedPreferencesImpl。有关 SharedPreferencesImpl 的机制在上篇文章中已经详细分析过。SharedPreferencesImpl 的构造方法，如下图：

SharedPreferenceImpl 的构造方法

注意源码中 mBackupFile 变量，本文也是重点围绕该变量进行分析。

创建 SharedPreferences 备份文件

从这可以看出，mBackupFile 是原始文件的备份文件，如：.../config.xml.bak（config 为 SharedPreferences 的文件名）。

3、mBackupFile 备份文件的作用

无论我们使用 SharedPreferences 的 commit() 或 apply() 提交数据，都会调用到 writeToFile 方法：

提交流程

这里只给大家简单贴下调用栈，commit 提交方法如下：

commit 提交

enqueueDiskWrite 方法如下：

enqueueDiskWrite 方法

可以看到 wirteToFile 方法的调用时机，这也是我们要重点追踪的方法。wirteToFile 方法的作用是将我们前面一系列的 putXxx 或 remove 后的数据落盘到存储设备（在移动设备一般指的是 Flash 闪存）。

4、写入文件分析

由于 writeToFile 方法内容较多，我们分上下两个部分分析：

writeToFile 方法，执行数据落盘

省去部分日志代码，代码中也标注了详细的注释：

首先如果源文件存在（SharedPreferences 文件，这里相对它的备份文件而言），判断如果要写入的数据是否真正发生变化，如果未发生变化则直接 return，这算是一层优化，避免无谓的 I/O 操作。

注意判断数据是否真正发生变化是在 EditorImpl 的 commmitToMemory() 方法中，在上篇文章中也有分析到：当前一系列操作数据发生在 EditorImpl 的 mModified（Map）变量中，该方法会比较 mModified 与 SharedPreferencesImpl 中 mMap 后修正最后一次 mMap 中数据，如果数据发生改变，如下图：

当前数据是否真的发生变化

继续向下分析，mBackupFile.exists() 方法判断当前是否存在备份文件，如果不存在，则将原始文件重名为备份文件。此时如果存在该文件的备份文件，则直接将源文件丢弃：mFile.delete()。

writeToFile 方法的下半部分分析，如下图：

writeToFile 方法下半部分

由于代码篇幅较长，省去部分。

创建 mFile 文件的输出流，这里很明白是要写入数据使用，系统将真正写入数据的操作都封装在 XmlUtils 中，然后强制 sync 落盘到闪存。

强制落盘

熟悉 I/O 的朋友都知道，我们应用程序平时用到的 read/write 操作都属于标准 I/O，也就是缓存 I/O（Buffered I/O）。它的关键特性有：

（1）对于读操作来说，当应用程序读取某块数据的时候，如果这块数据已经存放在页缓冲中，那么这块数据就可以立即返回给应用程序，而不需要经过实际的物理读盘操作。

（2）对于写操作来说，应用程序也会将数据先写到页缓冲（Page Cache）中去，数据是否被立即写到磁盘上去取决于应用所采用写操作的机制。默认系统采用的是延迟写机制，应用程序只需要将数据写到页缓冲中去就可以了，完全不需要等数据全部被写回到磁盘，系统会负责定期地将放在页缓冲中的数据刷到磁盘上。

SharedPreferences 在写入文件时采用强制落盘机制来保证数据 “不丢失”：FileUtils.sync()。

如果上面步骤没有发生任何异常，则删除备份文件，还记得前面说过，在新的写入文件之前，先将原始文件备份吗？如下图：

原文件重名为备份文件

如果写入过程未发生异常，则直接 return，表示本次写入成功。如果写入过程发生异常，则直接将源文件删除：mFile.delete()。catch() 异常后的代码调用，删除源文件 mFile.delete()，如下图：

删除 SharedPreference 的原文件

此时不知道会不会有这样一个疑问？数据都丢失了？

让我们再来看下 ShardPreferencesImpl 构造方法（源码上图已贴出）的最后 startLoadFromDisk() 方法，如下图：（只贴出与 Backup 文件相关）

loadFromDisk 加载文件数据到内存

检查源文件的备份文件是否存在：mBackupFile.exists()，如果存在，则将源文件删除：mFile.delete()，然后将备份文件修改为源文件：mBackupFile.renameTo(mFile)。后续操作就是从备份文件加载相关数据到内存 mMap 容器中了。

小结

SharedPreferences 的写入操作，首先是将源文件备份：mFile.renameTo(mBackupFile) 再写入所有数据，只有写入成功，并且通过 sync 完成落盘后，才会将 Backup（.bak） 文件删除。如果写入过程中进程被杀，或者关机等非正常情况发生。进程再次启动后如果发现该 SharedPreferences 存在 Backup 文件，就将 Backup 文件重名为源文件，原本未完成写入的文件就直接丢弃，这样最多也就是未完成写入的数据丢失，它能保证最后一次落盘（真正落盘）成功后的数据。也正式这个 BackUp 机制，导致多进程可能会丢失新写入的数据。但也不是只有多进程场景才会发生数据丢失的情况。

1、Context.MODE_MULTI_PROCESS 到底做了什么？

在《Android之不要滥用SharedPreferences》只是简单给大家提到：使用 Context.MODE_MULTI_PROCESS 只是重新从文件加载了一遍 SharedPreferences 数据，不要指望这货能够跨进程通信。如下图：

MODE_MULTI_PROCESS 的作用

关于 SharedPreferences 的创建过程在上篇文章中已经做过详细介绍，不再赘述，这里主要关注红线框中部分：startReloadIfChangedUnexpectedly 方法跟踪：

重新从文件中加载一遍到内存 Map

hasFileChangedUnexpectedly 方法如果返回 false 直接 return。
否则 startLoadFromDisk（关于 startLoadFromDisk 方法的作用已经多次说明过，不再赘述）。hasFileChangedUnexpectedly 方法如下图：

当前文件内容是否发生过变化

SharedPreferences 中会记录最后修改时间以及文件大小，当使用 Context.MODE_MULTI_PROCESS 时，此时会通过 StructStat（Os.stat() 返回） 计算得到，然后与当前最后同步时间和文件大小进行比较，如果不匹配就会触发 startLoadFromDisk 方法执行，既重新加载文件内容到内存 mMap 中。

2、SharedPreferences 的监控

SharedPreferences 中为我们提供了 OnSharedPreferenceChangeListener 数据改变回调：

数据改变通知

需要注意 onSharedPreferenceChanged() 的回调时机在 commit() 和 apply() 有所区别：

（1）使用 commit() 提交时，onSharedPreferenceChanged() 回调时机是在数据落盘完成之后（不代表一定成功，有可能发生异常）

（2）使用 apply() 提交时，onSharedPreferenceChanged() 回调时机是在完成数据内存替换之后，既 mModified 中数据提交到 mMap 完成之后（前者是对我们一系列putXxx() 或 remove() 做保存，后者是写入文件时使用）。

（3）系统保存 OnSharedPreferenceChangeListener 对象在 WeakHashMap 中：

弱引用保存数据监听

不熟悉 WeakHashMap 的机制可以去了解下，故如果在局部创建 OnSharedPreferenceChangeListener 对象，在方法体结束后生命周期即结束。

通过 OnSharedPreferenceChangeListener 回调我们可以监控任意 SharedPreferences 提交的 key:value，比如较大的数据直接给出警告；也可以监控单个 SharedPreferences 文件是否过大。

• SharedPrefenerces 的优化

我们也可以替换通过复写 Application 的 getSharedPreferences 方法替换系统默认实现，比如优化卡顿、合并多次 apply 操作、支持跨进程操作等。具体如何实现参考这里。

重写 Application 相关方法替换 SharedPreferences 实现

对系统提供的 SharedPreferences 的小修小补虽然性能有所提升，但是依然不能彻底解决问题。基本每个大公司都会自研一套替代的存储方案，比如微信最近就开源了MMKV。

最后

SharedPreferences 是我们日常经常使用的存储方法，但是里面的确会有大大小小的暗坑。所以我们需要充分了解它们的优缺点，这样在工作中可以更好地使用和优化。

总的来说，我们需要结合应用场景选择合适的数据存储方法。除了 SharedPreferences，Android 还为应用开发者提供了其它存储数据的方法。你可以参考 Android 存储优化系列专题中其他存储方法分析。

文中分析如有不妥或更好的分析结果，还请大家指出！如果你喜欢我的文章，就请留个赞吧！

推荐阅读

• Android 之不要滥用 SharedPreferences
• Android 官方存储选项