微信版 iOS 高性能通用 key-value 组件

MMKV 源起

(1)在会话列表、会话界面等有大量 cell 的地方,希望新加的计时器不会影响滑动性能;
(2)另外这些计数器还要永久存储下来——因为闪退随时可能发生。

这就需要一个性能非常高的通用 key-value 存储组件,我们考察了 SharedPreferences、NSUserDefaults、SQLite 等常见组件,发现都没能满足如此苛刻的性能要求。

考虑到这个防 crash 方案最主要的诉求还是实时写入,而 mmap 内存映射文件刚好满足这种需求,我们尝试通过它来实现一套 key-value 组件。

MMKV 原理

  • 内存准备
    通过 mmap 内存映射文件,提供一段可供随时写入的内存块,App 只管往里面写数据,由操作系统负责将内存回写到文件,不必担心 crash 导致数据丢失。

  • 数据组织
    数据序列化方面我们选用 protobuf 协议,pb 在性能和空间占用上都有不错的表现。

message KV {
      string key = 1;
buffer value = 2;
}

      (BO0L )setInt3Z:(int32_ t)value forKey: (NSString*)key 
}

      auto dato . PBEncode(value);

      return [self setData: data forKey: key];
}

      BOOL setData:(NSData*doto forKey: NSStringtkey
 {

      autokv.KVfkey,data];auto buf . PBEncode(kv);return [self write:buf];

}
  • 写入优化
    考虑到主要使用场景是频繁地进行写入更新,我们需要有增量更新的能力。我们考虑将增量 kv 对象序列化后,append 到内存末尾。

  • 空间增长
    对于空间增长的问题:以内存 pagesize 为单位申请空间,在空间用尽之前都是 append 模式;
    当 append 到文件末尾时,进行文件重整、key 排重,尝试序列化保存排重结果;排重后空间还是不够用的话,将文件扩大一倍,直到空间足够。所以在每次append之前都会先调用- (BOOL)ensureMemorySize:(size_t)newSize;方法检查一下是否有足够空间,如果没有则按照每次2倍的大小去扩展空间:

- (BOOL)ensureMemorySize:(size_t)newSize {
    ...
    if (newSize >= m_output->spaceLeft()) {
// try a full rewrite to make space
        static const int offset = pbFixed32Size(0);
        NSData *data = [MiniPBCoder encodeDataWithObject:m_dic];
 size_t lenNeeded = data.length + offset + newSize;
        size_t avgItemSize = lenNeeded / std::max<size_t>(1, m_dic.count);
size_t futureUsage = avgItemSize * std::max<size_t>(8, m_dic.count / 2);
        // 1. no space for a full rewrite, double it
// 2. or space is not large enough for future usage, double it to avoid frequently full rewrite
        if (lenNeeded >= m_size || (lenNeeded + futureUsage) >= m_size) {

size_t oldSize = m_size;
            do {
 m_size *= 2;
            } while (lenNeeded + futureUsage >= m_size);
            ...
        }
        ...
    }
    ...
}

另外针对空间增长,mmkv还提供了- (void)trim;方法来提供了通过手动调用减小多余占用内存的功能,正如每次扩增时按2倍扩增,缩减时也是每次除以2:

- (void)trim {
    ...
    auto oldSize = m_size;
 while (m_size > (m_actualSize * 2)) {
        m_size /= 2;
    }
    ...
}

MMKV for Android 特有功能

我们不是简简单单地照搬 iOS 的实现,在迁移到 Android 的过程中,深入分析了 Android 平台现有 kv 组件的痛点,在原有功能基础上,开发了 Android 特有的功能。

  • 多进程访问
    通过与 Android 开发同学的沟通,了解到系统自带的 SharedPreferences 对多进程的支持不好。现有基于 ContentProvider 封装的实现,虽然多进程是支持了,但是性能低下,经常导致 ANR。考虑到 mmap 共享内存本质上的多进程共享的,我们在这个基础上,深入挖掘了 Android 系统的能力,提供了可能是业界最高效的多进程数据共享组件。具体实现原理我们中秋节后分享,心急的同学可以前往 GitHub 查看源码和 wiki 文档。

  • 匿名内存
    在多进程共享的基础上,考虑到某些敏感数据(例如密码)需要进程间共享,但是不方便落地存储到文件上,直接用 mmap 不合适。我们了解到 Android 系统提供了 Ashmem 匿名共享内存的能力,发现它在进程退出后就会消失,不会落地到文件上,非常适合这个场景。我们很愉快地提供了 Ashmem MMKV 的功能。

  • 数据加密
    不像 iOS 提供了硬件层级的加密机制,在 Android 环境里,数据加密是非常必须的。MMKV 使用了 AES CFB-128 算法来加密/解密。我们选择 CFB 而不是常见的 CBC 算法,主要是因为 MMKV 使用 append-only 实现插入/更新操作,流式加密算法更加合适。事实上这个功能也回馈到了 iOS 版,所以现在两个系统的 MMKV 都有加密功能。

MMKV 使用

iOS 的使用在前文已经陈述,这里简单介绍一下 Android 的用法。

快速上手

MMKV 已托管到 bintray(JCenter),可以直接使用。在 App 的 build.gradle 里加上依赖:

dependencies {
    implementation 'com.tencent:mmkv:1.0.10'
}

MMKV 的使用非常简单,所有变更立马生效,无需调用 syncapply。 在 App 启动时初始化 MMKV,设定 MMKV 的根目录(files/mmkv/),例如在 MainActivity 里:

protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    String rootDir = MMKV.initialize(this);
    Log.d("mmkv", "root: " + rootDir);
    //……
}

MMKV 提供一个全局的实例,可以直接使用:

如果不同业务需要区别存储,也可以单独创建自己的实例:

MMKV* mmkv = MMKV.mmkvWithID("MyID");
mmkv.encode("bool", true);
……

SharedPreferences 迁移

  • MMKV 提供了 importFromSharedPreferences() 函数,可以比较方便地迁移数据过来。

  • MMKV 还额外实现了一遍 SharedPreferences、SharedPreferences.Editor 这两个 interface,在迁移的时候只需两三行代码即可,其他 CRUD 操作代码都不用改。

更详细的用法可以参看 GitHub 上的 wiki 文档。

MMKV 性能

iOS 性能对比

我们将 MMKV 和 NSUserDefaults 进行对比,重复读写操作 1w 次。相关测试代码在 iOS/MMKVDemo/MMKVDemo/,结果见如下图表。

image

(测试机器是 iPhone X 256 G,iOS 12 beta 2,每组操作重复 1w 次,时间单位是 ms。)

可见,MMKV 在写入性能上远远超越 NSUserDefaults,在读取性能上也有相近或超越的表现。

Android 性能对比

我们将 MMKV 和 SharedPreferences、SQLite 进行对比, 重复读写操作 1k 次。相关测试代码在 Android/MMKV/mmkvdemo/。结果如下图表。

  • 单进程性能
    可见,MMKV 在写入性能上远远超越 SharedPreferences & SQLite,在读取性能上也有相近或超越的表现。

    image

    (测试机器是 Pixel 2 XL 64G,Android 8.1,每组操作重复 1k 次,时间单位是 ms。)

  • 多进程性能
    可见,MMKV 无论是在写入性能还是在读取性能,都远远超越 MultiProcessSharedPreferences & SQLite & SQLite, MMKV 在 Android 多进程 key-value 存储组件上是不二之选

    image

    (测试机器是 Pixel 2 XL 64G,Android 8.1,每组操作重复 1k 次,时间单位是 ms。)


此文来源于网络 若有侵权 请联系晓雯微信:Pingwen20 删除

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 196,165评论 5 462
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 82,503评论 2 373
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 143,295评论 0 325
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,589评论 1 267
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,439评论 5 358
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,342评论 1 273
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,749评论 3 387
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,397评论 0 255
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,700评论 1 295
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,740评论 2 313
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,523评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,364评论 3 314
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,755评论 3 300
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,024评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,297评论 1 251
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,721评论 2 342
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,918评论 2 336