-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
android_ipc
将 MMKV 迁移到 Android 平台之后,很多同事反馈需要支持多进程访问——这在之前是没有考虑过的(因为 iOS 不支持多进程),需要进行全盘的设计和仔细的实现。
说到 IPC,首要的问题就是架构选型,不同的架构效果大相径庭。
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 内存另外存放。
状态同步逻辑用伪码表达大概是这个样子:
void checkLoadData() {
if (m_sequence != mmapSequence()) {
m_sequence = mmapSequence();
if (m_size != fileSize()) {
m_size = fileSize();
// 处理内存增长
} else {
// 处理内存重整
}
} else if (m_actualSize != mmapActualSize()) {
auto lastPosition = m_actualSize;
m_actualSize = mmapActualSize();
// 处理写指针增长
} else {
// 什么也没发生
return;
}
}
当一个进程发现 mmap 写指针增长,就意味着其他进程写入了新键值。这些新的键值都 append 在原有写指针后面,可能跟前面的 key 重复,也可能是全新的 key,而原写指针前面的键值都是有效的。那么我们就要把这些新键值都读出来,插入或替换原有键值,并将写指针同步到最新位置。
auto lastPosition = m_actualSize;
m_actualSize = mmapActualSize();
// 处理写指针增长
auto bufferSize = m_actualSize - lastPosition;
auto buffer = Buffer(lastPosition, bufferSize);
map<string, Buffer> dictionary = decodeMap(buffer);
for (auto& itr : dictionary) {
// m_cache 还是有效的
m_cache[itr.first] = itr.second;
}
当一个进程发现内存被重整了,就意味着原写指针前面的键值全部失效,那么最简单的做法是全部抛弃掉,从头开始重新加载一遍。
// 处理内存重整
m_actualSize = mmapActualSize();
auto buffer = Buffer(0, m_actualSize);
m_cache = decodeMap(buffer);
正如前文所述,发生内存增长的时候,必然已经先发生了内存重整,那么原写指针前面的键值也是统统失效,处理逻辑跟内存重整一样。
到这里我们已经完成了数据的多进程同步工作,是时候回头处理锁事了,亦即前面提到的递归锁和锁升级/降级。
-
递归锁
意思是如果一个进程/线程已经拥有了锁,那么后续的加锁操作不会导致卡死,并且解锁也不会导致外层的锁被解掉。对于文件锁来说,前者是满足的,后者则不然。因为文件锁是状态锁,没有计数器,无论加了多少次锁,一个解锁操作就全解掉。只要用到子函数,就非常需要递归锁。 -
锁升级/降级
锁升级是指将已经持有的共享锁,升级为互斥锁,亦即将读锁升级为写锁;锁降级则是反过来。文件锁支持锁升级,但是容易死锁:假如 A、B 进程都持有了读锁,现在都想升级到写锁,就会陷入相互等待的困境,发生死锁。另外,由于文件锁不支持递归锁,也导致了锁降级无法进行,一降就降到没有锁。
为了解决这两个难题,需要对文件锁进行封装,增加读锁、写锁计数器。处理逻辑如下表:
读锁计数器 | 写锁计数器 | 加读锁 | 加写锁 | 解读锁 | 解写锁 |
---|---|---|---|---|---|
0 | 0 | 加读锁 | 加写锁 | - | - |
0 | 1 | +1 | +1 | - | 解写锁 |
0 | N | +1 | +1 | - | -1 |
1 | 0 | +1 | 解读锁再加写锁 | 解读锁 | - |
1 | 1 | +1 | +1 | -1 | 加读锁 |
1 | N | +1 | +1 | -1 | -1 |
N | 0 | +1 | 解读锁再加写锁 | -1 | - |
N | 1 | +1 | +1 | -1 | 加读锁 |
N | N | +1 | +1 | -1 | -1 |
需要注意的地方有两点:
- 加写锁时,如果当前已经持有读锁,那么先尝试加写锁,try_lock 失败说明其他进程持有了读锁,我们需要先将自己的读锁释放掉,再进行加写锁操作,以避免死锁的发生。
- 解写锁时,假如之前曾经持有读锁,那么我们不能直接释放掉写锁,这样会导致读锁也解了。我们应该加一个读锁,将锁降级。
写了个简单的测试,创建两个 Service,测试 MMKV、MultiProcessSharedPreferences、SQLite 多进程读写的性能,具体代码见 git repo。
测试环境:Pixel 2 XL 64G, Android 8.1.0,单位:ms。每组测试分别循环 1000 次;MultiProcessSharedPreferences 使用 apply() 同步数据;SQLite 打开 WAL 选项。
MMKV is published under the BSD 3-Clause license. For details check out the LICENSE.TXT.
Check out the CHANGELOG.md for details of change history.
If you are interested in contributing, check out the CONTRIBUTING.md, also join our Tencent OpenSource Plan.
To give clarity of what is expected of our members, MMKV has adopted the code of conduct defined by the Contributor Covenant, which is widely used. And we think it articulates our values well. For more, check out the Code of Conduct.
Check out the FAQ first. Should there be any questions, don't hesitate to create issues.
User privacy is taken very seriously: MMKV does not obtain, collect or upload any personal information. Please refer to the MMKV SDK Personal Information Protection Rules for details.
- In English
- 中文
- In English
- 中文
- In English
- 中文
-
In English
-
中文
-
Golang