这是一篇你应该了解的Android数据存储优化

前言

年前在公司做了从 SharedPreferences 到 MMKV 的迁移，所以借这次机会和大家讨论一下Android存储优化。

我们为什么要去做存储优化？归根到底，还是 SharedPreferences 不太给力：

1. 增量更新导致文件写入的时间长。
2. 线程安全问题和潜在的ANR。
3. 不能跨进程，不过跨进程的使用场景还真不多！

除了 SharedPreferences，我们还可以选择哪些本地存储方式呢？

别说，还挺多，有DataStore、MMKV 和 数据库。

一、介绍

上面说了四种本地数据存储方式，简单介绍一下吧。

1. SharedPreferences

这个应该就不用介绍了，大家的老朋友，用于存储偏好设置。

2. DataStore

官方文档：传送门

DataStore 也是 Android Jetpack 中的一员，它是谷歌爸爸用来取缔 SharedPreferences 的。

所以，简单来说，它的作用也是存储偏好设置，不过，除了键值对以外，这位大哥还支持类型化对象。

什么是类型化对象，就是存对象。

常见的场景就是读书读了一半，退出了，需要存储书Id、章节Id和进度，不存用户Id的情况，需要使用三个键值对，使用封装好的对象只需要一个类型。

不过，数据足够复杂或者多维度的时候请使用数据库。

3. MMKV

官方文档：传送们

腾讯出品，必属精品。

同上面几个一样，主要用来存储键值对，但性能非常出色，毕竟经过了微信客户端的验证。

4. SQLite

跟上面哥几个的定位不太一样，主要用来对象的持久化存储。

比如，上面读书读一半的场景，举一个不太恰当的例子，你希望记录每个登陆用户对应的读书场景，这个时候，偏好设置肯定不太能满足你的需求，数据库就登场了。

二、测试

简单写了一段测试代码：

1. 测试项目地址：Hoo
2. 测试过程：单个文件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也可以将数据写入到文件

所以总结下来就是：

1. 数据集大或者维度多选 SQLite。
2. 本地数据存储少直接用 SharedPreferences。
3. 实在要换就 MMKV，DataStore 才 alpha，MMKV 已经发布多年，品质有保证。

四、SharedPreferences的优化

当然，肯定还有很多同学在使用 SharedPreferences，可以给出的一些建议是：

1. 偏好设置少的情况可以使用单例，数据读取快。
2. 偏好设置多的情况可以根据模块拆分多个文件，数据量大还是挺耗内存的。
3. 不要频繁使用 apply 或者 commit，存在这种情况可以一次性提交。
4. 优先使用 apply。
5. 复杂数据请用数据库。

精彩内容

如果觉得本文不错，「点赞」是对作者最大的鼓励～

技术不止，文章有料，关注公众号 九心说，每周一篇高质好文，和九心在大厂路上肩并肩。

参考文章，每篇都值得阅读：

《反思｜官方也无力回天？Android SharedPreferences的设计与实现》
《[Google] 再见 SharedPreferences 拥抱 Jetpack DataStore》
《Android 存储优化 —— MMKV 集成与原理》