来聊一聊MMKV的不足以及线下调试工具

8,142 阅读3分钟

开题

毋容置疑,MMKV是一款非常优秀的轻量级存储框架,像百度、头条、快手等应用都线上引用了,质量和性能上有微信实践做保证。在Android上MMKV主要用来替换系统的sp,用来解决sp性能 + 不支持多进程问题,掘金上有不少优秀文章对原理做了分析,如最近的《反思|官方也无力回天?Android SharedPreferences的设计与实现》等,就不再赘述,我们换个思路,来谈谈MMKV的一些设计缺陷,或者说改进点。

存在的问题

0x1 数据存储分了两个文件,数据+校验

先来介绍下MMKV的存储结构,分了两个文件,一个数据文件,存储结构如下:

一个校验文件,crc结尾,存储结构如下: (新版本扩展了一些字节,图是老的)

这种设计最直接问题就是占用空间变大了很多,如下面的例子,只存储了一个字段,但是为了方便MMAP映射,磁盘直接占用了8k的存储,官方宣称的protobuf存储(可变长整型) 也省不回这个大小

另一方面就是操作两个文件按理说出错的概率会变大,这个官方进行了回复 github.com/Tencent/MMK…, 微信线上错误率很低问题不大,但是存储在一个文件头上其实是更好的设计,不知道官方是为了向下兼容还是有其他考虑

0x2 数据存储阶段把类型擦除了

MMKV都是按字节进行存储的,实际写入文件把类型擦除了,这也是MMKV不支持getAll的原因,虽然说getAll用的不多问题不大,但是MMKV因此就不具备导出和迁移的能力了,比如说,以后出了更优秀的存储框架,是没有办法直接从MMKV批量迁移到新框架的,除非代码里面写死一个个key迁移

我觉得比较好的方案是每次存储,多用一个字节来存储数据类型,这样占用的空间也不会大很多,但是具备了更好的可扩展性

0x3 不方便调试

官方目前支持了5个平台,Android、iOS、Win、MacOS、python,但是没有提供解析数据的工具,数据文件和crc都是字节码,除了中文能看出一些内容,直接查看还是存在大量乱码。比如线上出了问题,把用户的存储文件捞上来,还得替换到系统目录里,通过代码断点去看,这也太不方便了。

敝人开发了一个MAC的工具(为什么不支持win? 只有mac本,也没精力维护多端)来调试MMKV的文件,支持以上五个平台产生的数据文件,使用也很简单,直接拖入数据文件和crc文件就行。

下载地址: github.com/pengwei1024…

界面预览

加载完成后还需要自己手动选择下类型,还是类型擦除的问题,不能直接读取出结果

结束

看到这里,你是不是明白了这篇文章的重点。^_^

希望各位大佬 star支持一下,能贡献代码就更棒了

本文使用 mdnice 排版