专栏首页微信终端开发团队的专栏MMKV for Android 多进程设计与实现

MMKV for Android 多进程设计与实现

MMKV 是基于 mmap 内存映射的移动端通用 key-value 组件,底层序列化/反序列化使用 protobuf 实现,性能高,稳定性强。从 2015 年中至今,在 iOS 微信上使用已有近 3 年,其性能和稳定性经过了时间的验证。近期已移植到 Android 平台。在腾讯内部开源半年之后,得到公司内部团队的广泛应用和一致好评。现在一并对外开源

 https://github.com/tencent/mmkv

欢迎 Star、提 Issue 和 PR。

前言

MMKV 的源起、设计原理与具体实现参考前文。将 MMKV 迁移到 Android 平台过程中,很多同事反馈需要支持多进程访问——这在之前是没有考虑过的(因为 iOS 不支持多进程),需要进行全盘的设计和仔细的实现。

IPC 选型

说到 IPC,首要的问题就是架构选型,不同的架构效果大相径庭。

CS 架构 vs 去中心化架构

Android 平台第一个想到的就是 ContentProvider:一个单独进程管理数据,数据同步不易出错,简单好用易上手。然而它的问题也很明显,就是一个字:启动慢,访问也慢。这个可以说是 Android 下基于 Binder 的 CS 架构组件的通用痛点。至于其他的 CS 架构,例如经典的 socket、PIPE、message queue,因为要至少 2 次的内存拷贝,就更加慢了。

MMKV 追求的是极致的访问速度,我们要尽可能地避免进程间通信,CS 架构是不可取的。再考虑到 MMKV 底层使用 mmap 实现,采用去中心化的架构是很自然的选择。我们只需要将文件 mmap 到每个访问进程的内存空间,加上合适的进程锁,再处理好数据的同步,就能够实现多进程并发访问。

挑选进程锁

然而去中心化的架构实现起来并不简单,Android 是个阉割版的 Linux,IPC 组件的支持比较残缺。例如,说到进程锁第一个想到的就是 pthread 库的 pthread_mutex,创建于共享内存的 pthread_mutex 是可以用作进程锁的,然而 Android 版的 pthread_mutex 并不保证robust,亦即对 pthread_mutex 加了锁的进程被 kill,系统不会进行清理工作,这个锁会一直存在下去,那么其他等锁的进程就会永远饿死。其他的 IPC 组件,例如信号量、条件变量,也有同样问题,Android 为了能够尽快关闭进程,真是无所不用其极。

找了一圈,能够保证 robust 的,只有已打开的文件描述符,以及基于文件描述符的文件锁和 Binder 组件的死亡通知(是的,Binder 也是依赖这个清理机制运作,打开的文件是 /dev/binder)。

我们有两个选择:

  • 文件锁,优点是天然 robust,缺点是不支持递归加锁,也不支持读写锁升级/降级,需要自行实现。
  • pthread_mutex,优点是 pthread 库支持递归加锁,也支持读写锁升级/降级,缺点是不 robust,需要自行清理。

关于 mutex 清理,有个可能的方案是基于 Binder 死亡通知进行清理:A、B进程相互注册对方的死亡通知,在对方死亡的时候进行清理。但有个比较棘手的场景:只有 A 进程存在,那么他的死亡通知就没人处理,留下一个永远加锁的 mutex。Binder 规定死亡通知不能本进程自行处理,必须由其他进程处理,所以这个问题不好解决。

综合各种考虑,我们先将文件锁作为一个简单的互斥锁,进行 MMKV 的多进程开发,稍后再回头解决递归锁和读写锁升级/降级的问题。

多进程实现细节

首先我们简单回顾一下 MMKV 原来的逻辑。MMKV 本质上是将文件 mmap 到内存块中,将新增的 key-value 统统 append 到内存中;到达边界后,进行重整回写以腾出空间,空间还是不够的话,就 double 内存空间;对于内存文件中可能存在的重复键值,MMKV 只选用最后写入的作为有效键值。那么其他进程为了保持数据一致,就需要处理这三种情况:写指针增长、内存重整、内存增长。但首先还得解决一个问题:怎么让其他进程感知这三种情况?

状态同步

  • 写指针的同步 我们可以在每个进程内部缓存自己的写指针,然后在写入键值的同时,还要把最新的写指针位置也写到 mmap 内存中;这样每个进程只需要对比一下缓存的指针与 mmap 内存的写指针,如果不一样,就说明其他进程进行了写操作。事实上 MMKV 原本就在文件头部保存了有效内存的大小,这个数值刚好就是写指针的内存偏移量,我们可以重用这个数值来校对写指针。
  • 内存重整的感知 考虑使用一个单调递增的序列号,每次发生内存重整,就将序列号递增。将这个序列号也放到 mmap 内存中,每个进程内部也缓存一份,只需要对比序列号是否一致,就能够知道其他进程是否触发了内存重整。
  • 内存增长的感知 事实上 MMKV 在内存增长之前,会先尝试通过内存重整来腾出空间,重整后还不够空间才申请新的内存。所以内存增长可以跟内存重整一样处理。至于新的内存大小,可以通过查询文件大小来获得,无需在 mmap 内存另外存放。

状态同步逻辑用伪码表达大概是这个样子:

写指针增长

当一个进程发现 mmap 写指针增长,就意味着其他进程写入了新键值。这些新的键值都 append 在原有写指针后面,可能跟前面的 key 重复,也可能是全新的 key,而原写指针前面的键值都是有效的。那么我们就要把这些新键值都读出来,插入或替换原有键值,并将写指针同步到最新位置。

内存重整

当一个进程发现内存被重整了,就意味着原写指针前面的键值全部失效,那么最简单的做法是全部抛弃掉,从头开始重新加载一遍。

内存增长

正如前文所述,发生内存增长的时候,必然已经先发生了内存重整,那么原写指针前面的键值也是统统失效,处理逻辑跟内存重整一样。

文件锁

到这里我们已经完成了数据的多进程同步工作,是时候回头处理锁事了,亦即前面提到的递归锁和锁升级/降级。

  • 递归锁 意思是如果一个进程/线程已经拥有了锁,那么后续的加锁操作不会导致卡死,并且解锁也不会导致外层的锁被解掉。对于文件锁来说,前者是满足的,后者则不然。因为文件锁是状态锁,没有计数器,无论加了多少次锁,一个解锁操作就全解掉。只要用到子函数,就非常需要递归锁。
  • 锁升级/降级 锁升级是指将已经持有的共享锁,升级为互斥锁,亦即将读锁升级为写锁;锁降级则是反过来。文件锁支持锁升级,但是容易死锁:假如 A、B 进程都持有了读锁,现在都想升级到写锁,就会陷入相互等待的困境,发生死锁。另外,由于文件锁不支持递归锁,也导致了锁降级无法进行,一降就降到没有锁。

为了解决这两个难题,需要对文件锁进行封装,增加读锁、写锁计数器。处理逻辑如下表:

需要注意的地方有两点:

  • 加写锁时,如果当前已经持有读锁,那么先尝试加写锁,try_lock 失败说明其他进程持有了读锁,我们需要先将自己的读锁释放掉,再进行加写锁操作,以避免死锁的发生。
  • 解写锁时,假如之前曾经持有读锁,那么我们不能直接释放掉写锁,这样会导致读锁也解了。我们应该加一个读锁,将锁降级

MMKV 多进程性能

写了个简单的测试,创建两个 Service,测试 MMKV、MultiProcessSharedPreferences、SQLite 多进程读写的性能,具体代码见 GitHub。

(测试环境:Pixel 2 XL 64G, Android 8.1.0,单位:ms。每组测试分别循环 1000 次;MultiProcessSharedPreferences 使用 apply() 同步数据;SQLite 打开 WAL 选项。)

本文分享自微信公众号 - WeMobileDev(WeMobileDev)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-09-25

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • MMKV 组件现在开源了

    MMKV 是基于 mmap 内存映射的移动端通用 key-value 组件,底层序列化/反序列化使用 protobuf 实现,性能高,稳定性强。从 2015 ...

    微信终端开发团队
  • 微信自用高性能通用key-value组件MMKV已开源!

    腾讯微信团队于2018年9月底宣布开源 MMKV ,这是基于 mmap 内存映射的 key-value 组件,底层序列化/反序列化使用 protobuf 实现,...

    JackJiang
  • 微信自用高性能通用key-value组件MMKV已开源!

    腾讯微信团队于2018年9月底宣布开源 MMKV ,这是基于 mmap 内存映射的 key-value 组件,底层序列化/反序列化使用 protobuf 实现,...

    JackJiang
  • 锦囊篇|一文摸懂SharedPreferences和MMKV

    不论是单线程还是多线程,MMKV的读写能力都远远的甩开了SharedPreferences&SQLite&SQLite+Transacion,但是MMKV到底是...

    ClericYi
  • 比 SharedPreferences 更高效?微信 MMKV 源码解析

    MMKV 是微信于 2018 年 9 月 20 日开源的一个 K-V 存储库,它与 SharedPreferences 相似,但又在更高的效率下解决了其不支持跨...

    音视频开发进阶
  • 微信团队分享:iOS版微信的高性能通用key-value组件技术实践

    本文要分享的是iOS版微信内部正在推广和使用的一个高性能通用key-value 组件的技术实践过程,该组件在微信内部被命名为MMKV(以下简称MMKV)。

    JackJiang
  • 锦囊篇|一文摸懂SharedPreferences和MMKV(二)

    因为到这里的话直接通过三方库的导入已经不能满足查看了,所以直接去下载MMKV的开源库源码查看比较合适。

    ClericYi
  • MMKV为什么可以替换SharedPreferences

    MMKV——基于 mmap 的高性能通用 key-value 组件,底层序列化/反序列化使用 protobuf 实现,性能高,稳定性强。 https://git...

    马上就说
  • 干货 | 携程机票 App KMM 跨端生产实践

    移动端跨平台技术自移动开发诞生以来一直是个热门话题,一是持续关注研发效率,降本提效;二是一套代码多端运行可以提升多端业务逻辑的一致性;三是跨端技术方案通常意味着...

    携程技术
  • FastKV:一个真的很快的KV存储组件

    对于Android客户端而言,最常见的莫过于SDK提供的SharePreferences(以下简称**SP**),但其低效率和ANR问题饱受诟病。

    呼啸长风
  • SharedPreferences VS MMKV

    SharedPreferences 作为轻量级存储在 Android 应用中是必不可少的,但依旧存在较大的优化空间,和尚在做性能优化时尝试了新的利器 腾讯 M...

    阿策小和尚
  • SharedPreferences VS MMKV

    SharedPreferences 作为轻量级存储在 Android 应用中是必不可少的,但依旧存在较大的优化空间,小菜在做性能优化时尝试了新的利器 腾讯 MM...

    阿策小和尚
  • 第一篇|腾讯开源项目盘点:WeUI,WePY,Tinker,Mars等

    开源展示了人类共同协作,成果分享的魅力,每一次技术发展都是站在巨人的肩膀上,技术诸多创新和发展往往就是基于开源发展起来的,没有任何一家网络公司可以不使用开源技术...

    腾讯技术工程官方号
  • Android 国际化之多语言适配小记

    甲方要求实现 App 国际化多语言,正好抽个时间弄了下,害,被自己蠢到死,特意记录下.

    HLQ_Struggle
  • Android开发4年,面试居然只值10K,4年Crud终于悔恨顿悟!

    学渣一枚,2017年6月某空港学校毕业。从事Android开发已经4年,开发过机顶盒应用,做过手机app,21年年后入职新单位从事车载应用开发。

    Android技术干货分享
  • Android MVVM框架搭建(三)MMKV + Room + RxJava2

      在上一篇文章中,我讲述了怎么在MVVM框架中搭建网络访问框架,并通过一个必应的每日壁纸做了一次请求接口的访问演示,这篇文章就需要来讲述Android端的本地...

    晨曦_LLW
  • 荣登Github周榜!Shadow发布更多设计细节

    腾讯最近开源的一款 Android 插件框架 Shadow,开源后受业内好评,荣登 Github 周榜。 这是腾讯旗下继 微信热补丁技术 tinker、前端跨...

    腾讯开源
  • 锦囊篇|一文摸懂SharedPreferences和MMKV(一)

    不论是单线程还是多线程,MMKV的读写能力都远远的甩开了SharedPreferences&SQLite&SQLite+Transacion。不过下面一句话仅代...

    ClericYi
  • MMKV--基于 mmap 的 iOS 高性能通用 key-value 组件

    MMKV 是基于 mmap 内存映射的 key-value 组件,底层序列化/反序列化使用 protobuf 实现,性能高,稳定性强。

    微信终端开发团队

扫码关注云+社区

领取腾讯云代金券