前言
年前在公司做了从 SharedPreferences 到 MMKV 的迁移，所以借这次机会和大家讨论一下Android存储优化。
我们为什么要去做存储优化？归根到底，还是 SharedPreferences 不太给力：
- 增量更新导致文件写入的时间长。
- 线程安全问题和潜在的ANR。
- 不能跨进程，不过跨进程的使用场景还真不多！
除了 SharedPreferences，我们还可以选择哪些本地存储方式呢？
一、介绍
上面说了四种本地数据存储方式，简单介绍一下吧。
1. SharedPreferences
这个应该就不用介绍了，大家的老朋友，用于存储偏好设置。
2. DataStore
官方文档：传送门
DataStore 也是 Android Jetpack 中的一员，它是谷歌爸爸用来取缔 SharedPreferences 的。
所以，简单来说，它的作用也是存储偏好设置，不过，除了键值对以外，这位大哥还支持类型化对象。
什么是类型化对象，就是存对象。
常见的场景就是读书读了一半，退出了，需要存储书Id、章节Id和进度，不存用户Id的情况，需要使用三个键值对，使用封装好的对象只需要一个类型。
不过，数据足够复杂或者多维度的时候请使用数据库。
3. MMKV
官方文档：传送们
腾讯出品，必属精品。
同上面几个一样，主要用来存储键值对，但性能非常出色，毕竟经过了微信客户端的验证。
4. SQLite
跟上面哥几个的定位不太一样，主要用来对象的持久化存储。
比如，上面读书读一半的场景，举一个不太恰当的例子，你希望记录每个登陆用户对应的读书场景，这个时候，偏好设置肯定不太能满足你的需求，数据库就登场了。
二、测试
简单写了一段测试代码：
- 测试项目地址：Hoo
- 测试过程：单个文件1000次的读写和查询
测试界面，路径【我的】-【数据存储】：
1. 写入结果
单文件1000次数据写入的情况：
看到这个结果的时候属实有点意外，Google 推出的 DataStore 怎么就最慢了？
1. SharedPreferences
SharedPreferences 的慢也在情理之中，主要有两点：
- 数据写入进文件比较耗时。
- 增量更新会导致数据重新写入。
特别是第二点，导致了最终 3300ms 的耗时。
2. MMKV
MMKV为什么这么快？主要有三点：
- mmap：如果你了解过
Binder，你肯定知道它的快是因为内存映射，MMKV 也使用内存映射，App 只管往里写数据，最后由操作系统负责将内存回写到文件，并且不用担心 crash 导致的数据丢失。 - 数据组织：使用 protobuf 进行数据序列化。
- 写入优化：增量更新将 kv 对象加到内存末尾，操作这块内存的 Linux内核会自动将这部分数据写入到文件。
最终的时长是 17ms。
3. SQLite
SQLite 对应的第三方库为 Android Jetpack 中的 Room，它的慢是因为：
- 1000次的文件IO操作。
- 存储对象要比键值对复杂，不过本项目中的对象只有两个字段。
总的而言，当 SharedPreferences 中单个文件存了很多键值对的时候，每次增量更新会导致内存中所有键值对的重新写入，而 SQLite 应该是仅需处理当前的对象，所以内存也会远远小于 SharedPreferences。
4. DataStore
DataStore 的结果属实让所有人都意外。
DataStore，谷歌 Android Jetpack 中的新成员，protobuf 夹持，天之骄子，霍霍一顿操作，效率竟然还不如 SharedPreferences？
这说的过去吗？显然说不过去，我简单看了一下源码（有可能不太准确），大概有以下原因：
- 每个 edit 操作都会开启一个子协程，1000次的 edit 操作的开销不容小觑。
- 1000次文件IO操作。
- 增量更新也会导致内存中的数据重新写入到文件。
因为多了一个开子协程的操作，所以直接导致了 10594ms 之久。
2. 读取结果
对之前的1000次写入的数据读取并进行检验：
可以看到，DataStore 仍然大于 SharedPreferences 和 MMKV。
1. SharedPreferences和MMKV
SharedPreferences 和 MMKV 分别是 14ms 和 12ms，测试中，有时 SharedPreferences 快，有时 MMKV 快，总的而言，两个结果差不多。
快的原因是两者都是直接从内存中读取。
2. SQLite
这次 SQLite 变成最慢的了，耗时达 296ms，因为每次查询都要从数据库中查询。
3. DataStore
DataStore 仍然没有那么快，时间要达到 67ms，相较于 SharedPreferences 和 MMKV，多了一个从文件读取数据到内存这个过程，如果优化一下，使用单例模式，应该也可以省略掉这个过程，最终结果应该跟上面二位差不多。
三、如何选择
除了效率以外，下面是谷歌给出的关于 DataStore 的表格：
与 MMKV 相比，DataStore 的优点是：
- 类型安全
但是 MMKV 的优点：
- 效率超级高
- 内存占用较小
- 支持多进程
- 发生crash也可以将数据写入到文件
所以总结下来就是：
- 数据集大或者维度多选 SQLite。
- 本地数据存储少直接用 SharedPreferences。
- 实在要换就 MMKV，DataStore 才 alpha，MMKV 已经发布多年，品质有保证。
四、SharedPreferences的优化
当然，肯定还有很多同学在使用 SharedPreferences，可以给出的一些建议是：
- 偏好设置少的情况可以使用单例，数据读取快。
- 偏好设置多的情况可以根据模块拆分多个文件，数据量大还是挺耗内存的。
- 不要频繁使用
apply或者commit，存在这种情况可以一次性提交。 - 优先使用
apply。 - 复杂数据请用数据库。
精彩内容
如果觉得本文不错，「点赞」是对作者最大的鼓励～
技术不止，文章有料，关注公众号 九心说，每周一篇高质好文，和九心在大厂路上肩并肩。
参考文章，每篇都值得阅读：
《反思｜官方也无力回天？Android SharedPreferences的设计与实现》
《[Google] 再见 SharedPreferences 拥抱 Jetpack DataStore》
《Android 存储优化 —— MMKV 集成与原理》
