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

前言

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

我们为什么要去做存储优化?归根到底,还是 SharedPreferences 不太给力:

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

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

别说,还挺多,有DataStoreMMKV数据库

一、介绍

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

1. SharedPreferences

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

2. DataStore

官方文档:传送门

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

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

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

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

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

3. MMKV

官方文档:传送们

腾讯出品,必属精品。

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

4. SQLite

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

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

二、测试

简单写了一段测试代码:

  1. 测试项目地址:Hoo
  2. 测试过程:单个文件1000次的读写和查询

测试界面,路径【我的】-【数据存储】:

测试界面

1. 写入结果

单文件1000次数据写入的情况:

Col写入时间.jpeg

看到这个结果的时候属实有点意外,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次写入的数据读取并进行检验:

Col读取时间.jpeg

可以看到,DataStore 仍然大于 SharedPreferencesMMKV

1. SharedPreferences和MMKV

SharedPreferences 和 MMKV 分别是 14ms12ms,测试中,有时 SharedPreferences 快,有时 MMKV 快,总的而言,两个结果差不多。

快的原因是两者都是直接从内存中读取。

2. SQLite

这次 SQLite 变成最慢的了,耗时达 296ms,因为每次查询都要从数据库中查询。

3. DataStore

DataStore 仍然没有那么快,时间要达到 67ms,相较于 SharedPreferences 和 MMKV,多了一个从文件读取数据到内存这个过程,如果优化一下,使用单例模式,应该也可以省略掉这个过程,最终结果应该跟上面二位差不多。

三、如何选择

除了效率以外,下面是谷歌给出的关于 DataStore 的表格:

DataStore和SharedPreferences对比

与 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 集成与原理》

推荐阅读更多精彩内容