本文详细介绍了微信MMKV 1.1.1版本的实现，包括MMKV的初始化、数据结构、CRC校验、文件有效性检查、数据加载和处理。MMKV利用mmap和protobuf提高性能，支持多进程并发，并通过CRC32校验确保数据完整性。文章深入探讨了MMKV在Apple平台的实现细节，包括类初始化、实例初始化和数据存储与获取的过程。
介绍
MMKV is an efficient, small, easy-to-use mobile key-value storage framework used in the WeChat application. It's currently available on Android, iOS/macOS, Win32 and POSIX.
作为一个精简易用且性能强悍的全平台 K-V 存储框架，MMKV 有如下特点：
- 高效：
- 利用 mmap 直接将文件映射到内存；
- 利用 protobuf 对键值进行编解码压缩；
- 多进程并发；
- 易用：无需手动
synchronize和配置，全程自动同步； - 精简.
- 少量的文件: 仅包括了编解码工具类和 mmap 逻辑代码，无冗余依赖；
- 二进制文件仅小于 30K: 如为 ipa 文件则会更小；
具体性能，微信团队提供了简单的 benchmark。总之就是秒杀苹果的 NSUserDefaults，性能差异达 100 多倍。
说明，现在大家看到的这篇文章是重写的 2.0 版本。就在前不久，MMKV 悄摸地发布了主版本更新 v1.1.0，而原有的实现已面目全非 ，原因详见：
We refactor the whole MMKV project and unify the cross-platform Core library. From now on, MMKV on iOS/macOS, Android, Win32 all share the same core logic code.
另，本篇涉及大量 C++ 实现，如果描述有误望及时指出。
准备工作
在开始之前，我们需要了解几个概念，熟悉的同学可 pass。
mmap
mmap是一种内存映射文件的方法，即将一个文件或者其它对象映射到进程的地址空间，实现文件磁盘地址和进程虚拟地址空间中一段虚拟地址的一一对映关系。实现这样的映射关系后，进程就可以采用指针的方式读写操作这一段内存，而系统会自动回写脏页面到对应的文件磁盘上，即完成了对文件的操作而不必再调用read,write等系统调用函数。相反，内核空间对这段区域的修改也直接反映用户空间，从而可以实现不同进程间的文件共享。
通常，我们的文件读写操作需要页缓存作为内核和应用层的中转。因此，一次文件操作需要两次数据拷贝（内核到页缓存，页缓存到应用层），而 mmap 实现了用户空间和内核空间数据的直接交互而省去了页缓存。当然有利也有弊，如 苹果文档 所述，想高效使用 mmap 需要符合以下场景：
- You have a large file whose contents you want to access randomly one or more times.
- You have a small file whose contents you want to read into memory all at once and access frequently. This technique is best for files that are no more than a few virtual memory pages in size.
- You want to cache specific portions of a file in memory. File mapping eliminates the need to cache the data at all, which leaves more room in the system disk caches for other data.
因此，当我们需要高频率的访问某一较大文件中的一小部分内容的时候，mmap 的效率是最高的。
其实不光是 MMKV 包括微信的 XLog 和 美团的 Logan 日志工具，还有 SQLight 都使用 mmap 来提升高频更新场景下的文件访问效率。
Protocol Buffer
Protobuf is a method of serializing structured data. It is useful in developing programs to communicate with each other over a wire or for storing data. The method involves an interface description language that describes the structure of some data and a program that generates source code from that description for generating or parsing a stream of bytes that represents the structured data.
Protobuf 是一种将结构化数据进行序列化的方法。它最初是为了解决服务器端新旧协议（高低版本）兼容性问题而诞生的。因此，称为“协议缓冲区”，只不过后期慢慢发展成用于传输数据和存储等。
MMKV 正是考虑到了 protobuf 在性能和空间上的不错表现，以简化版 protobuf 作为序列化方案，还扩展了 protobuf 的增量更新的能力，将 K-V 对象序列化后，直接 append 到内存末尾进行序列化。
那 Protobuf 是如何实现高效编码？
- 以
Tag - Value(Tag - Length - Value)的编码方式的实现。减少了分隔符的使用，数据存储更加紧凑； - 利用
base 128 varint(变长编码）原理压缩数据以后，二进制数据非常紧凑，pb 体积更小。不过 pb 并没有压缩到极限，float、double 浮点型都没有压缩； - 相比 JSON 和 XML 少了
{、}、:这些符号，体积也减少一些。再加上 varint、gzip 压缩以后体积更小。
CRC 校验
循环冗余校验（Cyclic redundancy check）是一种根据网络数据包或计算机文件等数据产生简短固定位数校验码的一种散列函数，主要用来检测或校验数据传输或者保存后可能出现的错误。生成的数字在传输或者存储之前计算出来并且附加到数据后面，然后接收方进行检验确定数据是否发生变化。
同样是用于计算校验值，相比 MD5 或者 SHA1，CRC 的计算效率较高，安全性较弱。考虑到文件系统、操作系统都有一定的不稳定性，MMKV 增加了 CRC 校验，对无效数据进行甄别。
在 iOS 微信现网环境上，有平均约 70万日次的数据校验不通过。
初始化
在 v1.1.0 版本 Tencent 团队重写了整个 MMVK 项目，统一跨平台核心库。自此 MMKV 在 iOS/macOS, Android, Win32 共享同一份核心逻辑。在一定程度上提高了可维护性，以及优势共享。也正是由于这一点，在 iOS/macOS 上可以实现 Multi-Process Access。
在代码结构上，MMKV 独立出单独的 MMVKCore，Apple 平台基于 MMKV Core 做了一层 Objc 的封装。
原有的实现基本都迁移到 MMKV Core 中并替换成了 C++ 实现。对不同平台的所独有的 API 或逻辑通过不同的文件名和宏来隔离。以 MemoryFile 为例：
MemoryFile.h
MemoryFile.cpp
MemoryFile_Android.cpp
MemoryFile_OSX.cpp
MemoryFile_Win32.cpp
本篇我们重点关注 Apple 相关逻辑。
Class Initialize
MMKV 在使用前的准备工作分成两个阶段：
- 初始化
g_instanceDic等静态变量。它在应用启动时的 pre_main 函数前，在 MMKV class 的+ initialize里完成的。 - 需要用户手动执行
+initializeMMKV来完成g_basePath的指定，即 MMKV 的根目录。
+ (void)initialize {
if (self == MMKV.class) {
g_instanceDic = [[NSMutableDictionary alloc] init];
g_lock = new mmkv::ThreadLock();
g_lock->initialize();
mmkv::MMKV::minimalInit([self mmkvBasePath].UTF8String);
/* 注册启动通知 */
}
}在类的初始化中，做了四件事情：
g_instanceDic：全局 MMKV 实例的容器，key 由多个字段混合生成的，后面会说明；g_lock: 为g_instanceDic配了把线程锁；minimalInit：以 MMKV 默认的根目录 (～/Document/mmkv) ，初始化 MMKV Core 中的全局变量；- 注册 App 生命周期相关的通知 （仅 iOS 应用主体）
这里之前有不明白之处，就是为什么这里没有使用 dispatch_once 来保证不可重入呢？
当翻看该文件的 history 时，发现早期版本确实用到了 dispatch_once 来避免重入。而现在换成这种写法难道是
用了什么新特性吗？
我们知道 +initialize 是有可能被多次调用的，但是对其如何被多次调用，被谁多次调用，这里理解有误。
以 MMKV 为例，假设我们声明 MMKVTest 作为其 MMKV 的子类，但未实现 +initialize 或者 MMKVTest 在其 +initialize 中显式的调用 [super initialize] 方法，那么 MMKV 的 +initialize 才会被调用多次。
但是忽略了很重要的一点，+initialize 是 class method，完全可以通过判断 class 类型来避免重入。这也是第一行判断 self == MMKV.class 的重要性和作用。
MinimalInit
protect from some old code that don't call initializeMMKV()
为了确保相关属性访问时已初始化完成，在类初始化时需要提前备好全局变量。
void MMKV::minimalInit(MMKVPath_t defaultRootDir) {
ThreadLock::ThreadOnce(&once_control, initialize);
int device = 0, version = 0;
GetAppleMachineInfo(device, version);
# ifdef __aarch64__
if ((device == iPhone && version >= 9) || (device == iPad && version >= 7)) {
CRC32 = mmkv::armv8_crc32;
}
# endif
g_rootDir = defaultRootDir;
mkPath(g_rootDir);
}
该方法以最低限度把必须要完成的事情放到了应用的启动前，主要三件事：
- 执行 initialize 完成全局变量的 init。
- 确定 CRC 校验的算法；
- 生成 mmkv 根目录；
Initialize
ThreadLock::ThreadOnce 背后以 pthread_once 来保证单词调用，以完成 initialize()，最后用 g_rootDir 创建对应的文件目录。来看私有的 initialize 方法做了啥：
void initialize() {
g_instanceDic = new unordered_map<string, MMKV *>;
g_instanceLock = new ThreadLock();
g_instanceLock->initialize();
mmkv::DEFAULT_MMAP_SIZE = mmkv::getPageSize();
}
在 MMKV Core 实现中也维护了 g_instanceDic 和 g_instanceLock 。看到这不太理解，那在 iOS / MacOS 端为何仍旧保留了这两 ？求告知。
static NSMutableDictionary *g_instanceDic = nil;
static mmkv::ThreadLock *g_lock;CRC32
该方法用于获取文件的 digest 校验值。
typedef uint32_t (*CRC32_Func_t)(uint32_t crc, const unsigned char *buf, size_t len);
extern CRC32_Func_t CRC32;
这里的 CRC32 就是正儿八经的函数指针，默认指向的是：
static inline uint32_t _crc32Wrap(uint32_t crc, const unsigned char *buf, size_t len) {
return static_cast<uint32_t>(::crc32(crc, buf, static_cast<uInt>(len)));
}
不过这里作者做了优化，当 CPU 架构为 aarch64，则改换了 mmkv::armv8_crc32 的实现。由于 crc32 指令需要A10芯片，也就是 iPhone 7 或 iPad 的第六代。因此，这个通过 GetAppleMachineInfo 获取设备和系统版本来判断。
最后一步，获取内存页的大小用于后续文件存取时计算所需内存，并存入 DEFAULT_MMAP_SIZE。
注册通知
MMKV 在 Core/MMKVPredef.h 定义了各个平台的宏，这里只在 iOS 应用主体注册了 Notification：
#if defined(MMKV_IOS) && !defined(MMKV_IOS_EXTENSION)
if ([[[NSBundle mainBundle] bundlePath] hasSuffix:@".appex"]) {
g_isRunningInAppExtension = YES;
}这里由于担心遗漏对 MMKV_IOS_EXTENSION 的判断，故此添加了 g_isRunningInAppExtension 静态变量；
注册的两个 Notification 的方法为：didEnterBackground 和 didBecomeActive，用于监听 UIApplicationState 在前后台的状态变化。在注册通知时，也会获取了当前 applicationState 并通过方法：
void MMKV::setIsInBackground(bool isInBackground)
来更新 g_isInBackground。这么做是为了保证在后台时能够安全的执行文件写入。
InitializeMMKV
真正使用前还需要手动调用一次 +initializeMMKV: logLevel: 或其相关 convene method。
方法内部使用 static BOOL g_hasCalledInitializeMMKV 来防止被多次调用:
if (g_hasCalledInitializeMMKV) {
MMKVWarning("already called +initializeMMKV before, ignore this request");
return [self mmkvBasePath];
}
g_hasCalledInitializeMMKV = YES;
initializeMMKV: 第一个参数为 rootDir 用于更新 g_basePath，为空的话就用默认值。接着传入 logLevel，执行 MMKV Core 提供的初始化方法：
void MMKV::initializeMMKV(const MMKVPath_t &rootDir, MMKVLogLevel logLevel) {
g_currentLogLevel = logLevel;
ThreadLock::ThreadOnce(&once_control, initialize);
g_rootDir = rootDir;
mkPath(g_rootDir);
}
这里同样也调用了 ThreadLock::ThreadOnce 保证 MMKV Core 能够成功初始化。
在 1.1 版本中，由于底层实现的统一，iOS 端可以支持多进程调用，这里多出来一个控制参数，对应的方法为：
+initializeMMKV: groupDir: logLevel:。内部也是走上面的方法，不过多出来一个全局变量：
g_groupPath = [groupDir stringByAppendingPathComponent:@"mmkv"];Instance Initialize
mmkvWithID
获取实例 MMKV 同样提供了多个 convince method，最终收口的私有类方法如下：
+ (instancetype)mmkvWithID:(NSString *)mmapID
cryptKey:(NSData *)cryptKey
relativePath:(nullable NSString *)relativePath
mode:(MMKVMode)mode注意
最低0.47元/天 解锁文章
扫一扫
1693
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
