浅析 - 微信 MMKV 1.1.1

介绍

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 是如何实现高效编码？

  1. 以 Tag - Value (Tag - Length - Value)的编码方式的实现。减少了分隔符的使用，数据存储更加紧凑；
  2. 利用 base 128 varint (变长编码）原理压缩数据以后，二进制数据非常紧凑，pb 体积更小。不过 pb 并没有压缩到极限，float、double 浮点型都没有压缩；
  3. 相比 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 的封装。

MMVK Core.png

原有的实现基本都迁移到 MMKV Core 中并替换成了 C++ 实现。对不同平台的所独有的 API 或逻辑通过不同的文件名和宏来隔离。以 MemoryFile 为例：

MemoryFile.h
MemoryFile.cpp
MemoryFile_Android.cpp
MemoryFile_OSX.cpp
MemoryFile_Win32.cpp

本篇我们重点关注 Apple 相关逻辑。

Class Initialize

MMKV 在使用前的准备工作分成两个阶段：

  1. 初始化 g_instanceDic 等静态变量。它在应用启动时的 pre_main 函数前，在 MMKV class 的 + initialize 里完成的。
  2. 需要用户手动执行 +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);
}

该方法以最低限度把必须要完成的事情放到了应用的启动前，主要三件事：

  1. 执行 initialize 完成全局变量的 init。
  2. 确定 CRC 校验的算法；
  3. 生成 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

注意，正式因为 relativePath 和 mode 是互斥的，不能同时设置，这才作为私有方法。那就一探究竟吧。

首先，会检查 g_hasCalledInitializeMMKV 是否执行过 +initializeMMKV: 以及 mmapID 是否有效。

上锁 SCOPED_LOCK(g_lock)之后，接着就是处理 relativePath 和 mode 的问题了：

if (mode == MMKVMultiProcess) {
    if (!relativePath) {
        relativePath = g_groupPath;
    }
    if (!relativePath) {
        MMKVError("Getting a multi-process MMKV [%@] without setting groupDir makes no sense", mmapID);
        MMKV_ASSERT(0);
    }
}

g_groupPath 本身是服务于 multi-process 的，对于单进程而言 g_groupPath 值自然为 nil，也就不会有冲突一说。上述逻辑做的事情也比较清晰，就是在 multi-process 下，会将 relativePath 覆盖，并保证起不能为空。

至于为何不能为空？MMKVError 中已经做了很明确的说明了。

初始化 MMKV 实例

NSString *kvKey = [MMKV mmapKeyWithMMapID:mmapID relativePath:relativePath];
MMKV *kv = [g_instanceDic objectForKey:kvKey];
if (kv == nil) {
    kv = [[MMKV alloc] initWithMMapID:mmapID cryptKey:cryptKey relativePath:relativePath mode:mode];
    if (!kv->m_mmkv) {
        return nil;
    }
    kv->m_mmapKey = kvKey;
    [g_instanceDic setObject:kv forKey:kvKey];
}

首先，通过 mmapID 和 relativePath 来生成 kvKey，用于关联生成的 mmkv 实例，最终存储在 g_instanceDic 中。如果 relativePath 为有效字符串，key 值为 relativePath 和 mmapID 拼接后的的 md5 值。

接着，尝试通过 key 来获取实例。没有的话就需要进行初始化，并将 mmkv 实例保存到 g_instanceDic。

这里每个实例本身也会将 key 保存在 m_mmapKey 中，以待其结束时，将自身从 g_instanceDic 中移除。

initWithMMapID

通过 MMKV Core 的 mmkv::MMKV::mmkvWithID 方法来获取 m_mmkv 实例。参数就是将 mmapID、cryptKey、relativePath 转为 c string 传入。

同类的初始化一样，MMKV Core 构造函数的实现与 iOS 侧无异，只是用 C++ 的方式再做了一遍。这里除了对 variable 进行默认值的赋值之外，最终调用 loadFromFile() 来加载 mmkv 文件和 CRC 文体。MMKV 的构造函数完整实现就不贴出来了，简单看一下声明吧：

#ifndef MMKV_ANDROID
    MMKV(const std::string &mmapID, MMKVMode mode, std::string *cryptKey, MMKVPath_t *relativePath);
    std::string m_mmapKey;
#else // defined(MMKV_ANDROID)
    MMKV(const std::string &mmapID, int size, MMKVMode mode, std::string *cryptKey, MMKVPath_t *relativePath);

    MMKV(const std::string &mmapID, int ashmemFD, int ashmemMetaFd, std::string *cryptKey = nullptr);
#endif

Data Structure

本节，会稍微介绍一下 MMKV 中用到的相关数据结构和一些变量。对主要数据结构有基本了解后，在解释实现时我们更能够 Focus 在核心逻辑。

先来看 MMKV 的实例变量：

mmkv::MMKVMap m_dic; /// 保存当前映射到内存的 k-v 
std::string m_mmapID;
MMKVPath_t m_path; // mmkv path
MMKVPath_t m_crcPath; // crc file path

mmkv::MemoryFile *m_file; // mmap 映射真实数据文件的相关信息，包括 file descrpitot 等
size_t m_actualSize; //当前 k-v 占用内存大小
mmkv::CodedOutputData *m_output; // 映射内存所剩余空间

bool m_needLoadFromFile; // 标记是否需要重新载入 m_file
bool m_hasFullWriteback; // 是否需要执行写回，例如 m_file 读取失败，内存异常等等

uint32_t m_crcDigest;
mmkv::MemoryFile *m_metaFile; // mmap 映射 crc 文件的相关信息，包括 file descrpitot etc.
mmkv::MMKVMetaInfo *m_metaInfo; // 保存了 crc 文件的 digest 和 size etc.

mmkv::AESCrypt *m_crypter; // 加密器，文件内容更新后会重新计算加密值

mmkv::ThreadLock *m_lock; // k-v 文件锁
mmkv::FileLock *m_fileLock; // crc 文件锁
mmkv::InterProcessLock *m_sharedProcessLock; // 读锁
mmkv::InterProcessLock *m_exclusiveProcessLock; // 写锁

上述变量会在 MMKV 构造函数调用时完成 initialize。

MMKVMap

首先是 MMKVMap，它区分了 Apple 系和其他系统。如果是 Apple 系，则使用 NSString 为 key，value 不仅是 MMBuffer 类型，需要实现 KeyHasher 和 KeyEqualer 协议，毕竟 unordered_map 是 C++ 泛型。

struct KeyHasher {
    size_t operator()(NSString *key) const { return key.hash; }
};

struct KeyEqualer {
    bool operator()(NSString *left, NSString *right) const { /* left isEqual right */ }
};
#ifdef MMKV_APPLE
using MMKVMap = std::unordered_map<NSString *, mmkv::MMBuffer, KeyHasher, KeyEqualer>;
#else
using MMKVMap = std::unordered_map<std::string, mmkv::MMBuffer>;
#endif

注意，在我们的 m_dic 中存储的数据类型是 MMBuffer 而非真实数据类型。只有当我们通过 Access 访问的时候才会 encode / decode 出来。

MMKVKey_t

#ifdef MMKV_APPLE
    using MMKVKey_t = NSString *__unsafe_unretained;
    static bool isKeyEmpty(MMKVKey_t key) { return key.length <= 0; }
#else
    using MMKVKey_t = const std::string &;
    static bool isKeyEmpty(MMKVKey_t key) { return key.empty(); }
#endif

注意，整个 MMKV Core 的源码中，应该只有 MMKV.cpp 这个文件是以 MRC 的方式进行内存管理的，其他的 C++ 类则使用了 ARC，可以查看 MMKVCore.podspec:

s.requires_arc = ['Core/MemoryFile.cpp', ...]

这里并未发现包含了 MMKV.cpp 文件，后续代码中会说明。

MMKVPath_t

using MMKVPath_t = std::string;

MemoryFile

class MemoryFile {
    MMKVPath_t m_name;
    MMKVFileHandle_t m_fd; // file descriptior (不同平台有所差异)
#ifdef MMKV_WIN32
    HANDLE m_fileMapping;
#endif
    void *m_ptr; // 指向 mmap 内存的起始地址
    size_t m_size; // 表示的是文件按照内存整数页截断后的 size。

    bool mmap();
    void doCleanMemoryCache(bool forceClean);
public:
#ifndef MMKV_ANDROID
    explicit MemoryFile(const MMKVPath_t &path);
#else
    MemoryFile(const MMKVPath_t &path, size_t size, FileType fileType);
    explicit MemoryFile(MMKVFileHandle_t ashmemFD);

    const FileType m_fileType;
#endif // MMKV_ANDROID
    
   /* methods ... */
}

MMKV 之所以高效就是源自 mmap，正是 MemoryFile 封装了 mmap、mumap、msync 等。

非安卓平台构造函数只需 filePath，其余变量均通过 reloadFromFile() 来获取。这里多说一嘴 FileType:

enum FileType : bool { MMFILE_TYPE_FILE = false, MMFILE_TYPE_ASHMEM = true };

MMFILE_TYPE_ASHMEM 指 Android 中所独有的匿名共享内存方式 ASharedMemory，本质也是 mmap 哈。

reloadFromFile

void MemoryFile::reloadFromFile() {
#    ifdef MMKV_ANDROID
    if (m_fileType == MMFILE_TYPE_ASHMEM) {
        return;
    }
#    endif
    if (isFileValid()) {
        MMKVWarning("calling reloadFromFile while the cache [%s] is still valid", m_name.c_str());
        MMKV_ASSERT(0);
        clearMemoryCache();
    }

    m_fd = open(m_name.c_str(), O_RDWR | O_CREAT | O_CLOEXEC, S_IRWXU);
    if (m_fd < 0) {
        MMKVError("fail to open:%s, %s", m_name.c_str(), strerror(errno));
    } else {
        FileLock fileLock(m_fd);
        InterProcessLock lock(&fileLock, ExclusiveLockType);
        SCOPED_LOCK(&lock);

        mmkv::getFileSize(m_fd, m_size);
        // round up to (n * pagesize)
        if (m_size < DEFAULT_MMAP_SIZE || (m_size % DEFAULT_MMAP_SIZE != 0)) {
            size_t roundSize = ((m_size / DEFAULT_MMAP_SIZE) + 1) * DEFAULT_MMAP_SIZE;
            truncate(roundSize);
        } else {
            auto ret = mmap();
            if (!ret) {
                doCleanMemoryCache(true);
            }
        }
#    ifdef MMKV_IOS
        tryResetFileProtection(m_name);
#    endif
    }
}

第一步就是判断 m_fileType，如果为 MMFILE_TYPE_ASHMEM 则直接 return 以通过 ASharedMemory_create 来完成内存映射。

接着判断 fd 是否指向有效内存：

#ifndef MMKV_WIN32
    bool isFileValid() { return m_fd >= 0 && m_size > 0 && m_ptr; }
#else
    bool isFileValid() { return m_fd != INVALID_HANDLE_VALUE && m_size > 0 && m_fileMapping && m_ptr; }
#endif

如果有效，则会执行 MemoryFile::clearMemoryCache() ，内部先调用 mumap(m_ptr, m_size) 清理内存缓存，再关闭文件访问 close(m_fd) 还原 m_fd 和 m_size。

在 mmap 前会有一个内存取整的检查，以保证所映射的数据是内存页 DEFAULT_MMAP_SIZE 的整数倍，以减少内存碎片。

最后，在 iOS 上会调整文件的读写保护，前面在注册通知中提到过，为了确保应用在后台时能安全的进行文件访问，而不至于被系统错杀 ⚠️。

truncate

内存区取整。

bool MemoryFile::truncate(size_t size) {
    if (m_fd < 0) {
        return false;
    }
    if (size == m_size) {
        return true;
    }
#    ifdef MMKV_ANDROID
        ...
#    endif // MMKV_ANDROID

    auto oldSize = m_size;
    m_size = size;
    // round up to (n * pagesize)
    if (m_size < DEFAULT_MMAP_SIZE || (m_size % DEFAULT_MMAP_SIZE != 0)) {
        m_size = ((m_size / DEFAULT_MMAP_SIZE) + 1) * DEFAULT_MMAP_SIZE;
    }

    if (::ftruncate(m_fd, static_cast<off_t>(m_size)) != 0) {
        MMKVError("fail to truncate [%s] to size %zu, %s", m_name.c_str(), m_size, strerror(errno));
        m_size = oldSize;
        return false;
    }
    if (m_size > oldSize) {
        if (!zeroFillFile(m_fd, oldSize, m_size - oldSize)) {
            MMKVError("fail to zeroFile [%s] to size %zu, %s", m_name.c_str(), m_size, strerror(errno));
            m_size = oldSize;
            return false;
        }
    }

    if (m_ptr) {
        if (munmap(m_ptr, oldSize) != 0) {
            MMKVError("fail to munmap [%s], %s", m_name.c_str(), strerror(errno));
        }
    }
    auto ret = mmap();
    if (!ret) {
        doCleanMemoryCache(true);
    }
    return ret;
}

为保证 size 准确性，再进行一次 round up to (n * pagesize) 后才进行取整。两步走：

ftruncate + lseek

对文件扩容或裁剪，并将 file offset 更新至当前容量的最后位置。由于 truncate 并不会操作 file offset 所以需要借助 lseek，剩余的部分均用 '\0' 写入。

munmap + mmap

由于 mmap 关联的是 oldSize 的内存，而现在我们调整了 m_size 大小，需要重新绑定文件与内存关系。

MMBuffer

class MMBuffer {
private:
    void *ptr;
    size_t size;
    MMBufferCopyFlag isNoCopy;
#ifdef MMKV_APPLE
    NSData *m_data = nil;
#endif

public:
    explicit MMBuffer(size_t length = 0);
    MMBuffer(void *source, size_t length, MMBufferCopyFlag flag = MMBufferCopy);
#ifdef MMKV_APPLE
    explicit MMBuffer(NSData *data, MMBufferCopyFlag flag = MMBufferCopy);
#endif
   // 数据读写方法 ...
}

就是一段连续的内存地址，在 Apple 上则用 NSData 指向，其他平台则是通过 ptr + size 来引用。

在 MMKV 中不论是从数据写入文件还是从文件中读取，统一转换为 MMBuffer 作为过渡。

CodedOutputData

class CodedOutputData {
    uint8_t *const m_ptr;
    size_t m_size;
    size_t m_position;

public:
    CodedOutputData(void *ptr, size_t len);
    size_t spaceLeft();
    uint8_t *curWritePointer();
    void seek(size_t addedSize);
    void writeRawByte(uint8_t value);
    /// 其他基本数据类型写入 ...
}

CodedOutputData

class CodedInputData {
    uint8_t *const m_ptr;
     size_t m_size;
    size_t m_position;

    int8_t readRawByte();

public:
    CodedInputData(const void *oData, size_t length);
    bool isAtEnd() { return m_position == m_size; };
    /// 其他基本数据类型读取 ...
}

CodedInputData 和 CodedOutputData 主要用于真实数据类型和 MMBuffer 之间转换，关系如下：

MMBuffer -> Input -> 真实数据 -> output -> MMBuffer

CodedInputData 将 binary Data 从 MMBuffer 中读取出来，转换为真实数据类型；

CodedOutputData 则将真实数据类型转换为 binaryData 输出到 MMBuffer 中；

可见，它们两起到了桥梁的作用，完成了真实数据和 MMBuffer 的相互转换。

InterProcessLock

MMKV 采用文件锁来处理多进程中的文件访问。用排他锁作为写锁，用共享锁作为读锁。 这里没有直接使用系统的 flock 而是用 FileLock 将其封装了一层，读写锁均为 InterProcessLock 本质为 FileLock。

class InterProcessLock {
    FileLock *m_fileLock;
    LockType m_lockType;

public:
    InterProcessLock(FileLock *fileLock, LockType lockType)
        : m_fileLock(fileLock), m_lockType(lockType), m_enable(true) {
        MMKV_ASSERT(m_fileLock);
    }

    bool m_enable;

    void lock() {
        if (m_enable) {
            m_fileLock->lock(m_lockType);
        }
    }

    bool try_lock() {
        if (m_enable) {
            return m_fileLock->try_lock(m_lockType);
        }
        return false;
    }

    void unlock() {
        if (m_enable) {
            m_fileLock->unlock(m_lockType);
        }
    }
};

MMVK.h 中还声明了变量 m_isInterProcess 用于控制锁功能开关。对于支持多进程的 MMKV 而言，m_isInterProcess 代表了当前实例所采用的读写模式：MMKVMode：

enum MMKVMode : uint32_t {
    MMKV_SINGLE_PROCESS = 0x1,
    MMKV_MULTI_PROCESS = 0x2,
#ifdef MMKV_ANDROID
    CONTEXT_MODE_MULTI_PROCESS = 0x4, // in case someone mistakenly pass Context.MODE_MULTI_PROCESS
    MMKV_ASHMEM = 0x8,
#endif
};

关于锁的，感兴趣的可以看看这篇：flock 文件锁。

由于本文篇幅较长，很多描述中忽略了锁相关的细节（其实非常重要的），之后会单独开篇来聊聊。

LoadData

本节主要介绍 MMKV 如何从文件中读取数据、异常数据处理、以及如何利用 CRC 来校验文件的完整性。

在应用首次初始化、数据异常，内存警告、清理数据时都会执行 loadFromFile() 来刷新内存中对应的数据，保证其准确性。整个 m_file 加载主要分三步：

  1. 校验 CRC 文件、m_file 的有效性，初始化 AESCrypter；
  2. 检查文件内部数据的有效性；
  3. 加载数据到内存。

文件有效性

在 MMKV 构造函数执行时，m_metaFile 为本地 crc 文件的内存映射，而 m_metaInfo 则记录了当前内存数据的相关 crc 校验值，默认为空。

struct MMKVMetaInfo {
    uint32_t m_crcDigest = 0;
    uint32_t m_version = MMKVVersionSequence;
    uint32_t m_sequence = 0; // full write-back count
    unsigned char m_vector[AES_KEY_LEN] = {};
    uint32_t m_actualSize = 0;

    // confirmed info: it's been synced to file
    struct {
        uint32_t lastActualSize = 0;
        uint32_t lastCRCDigest = 0;
        uint32_t __reserved__[16] = {};
    } m_lastConfirmedMetaInfo;

    void write(void *ptr) {
        MMKV_ASSERT(ptr);
        memcpy(ptr, this, sizeof(MMKVMetaInfo));
    }

    void writeCRCAndActualSizeOnly(void *ptr) {
        MMKV_ASSERT(ptr);
        auto other = (MMKVMetaInfo *) ptr;
        other->m_crcDigest = m_crcDigest;
        other->m_actualSize = m_actualSize;
    }

    void read(const void *ptr) {
        MMKV_ASSERT(ptr);
        memcpy(this, ptr, sizeof(MMKVMetaInfo));
    }
};

因此，MMKV 在加载 m_file 前要将 crc 的校验值载入 m_metaInfo，载入前会确认 crc 完成映射：

if (m_metaFile->isFileValid()) {
    m_metaInfo->read(m_metaFile->getMemory());
}

注意 m_version 表示当前缓存的内容数据的状态，初始值为 MMKVVersionSequence。有以下几种：

enum MMKVVersion : uint32_t {
    MMKVVersionDefault = 0,
    // 记录了完全回写的次数
    MMKVVersionSequence = 1,
    // 存储了加密的随机 iv 
    MMKVVersionRandomIV = 2,
    // 存储了 actual size、crc checksum, 用于减少文件损坏的情况
    MMKVVersionActualSize = 3,
};

AESCrypter

if (m_crypter) {
    if (m_metaInfo->m_version >= MMKVVersionRandomIV) {
        m_crypter->resetIV(m_metaInfo->m_vector, sizeof(m_metaInfo->m_vector));
    }
}

MMKV 初始化时，用户如果传入 AES Key，会通过 resetIV 来初始化 AES。

AES 属于块加密且存在多种加密模式，MMKV 中使用的是 CFB-128 模式。该模式需要同时使用 KEY 和 IV 来完成对数据的加密。

关于 AES 的介绍可以看 WiKi，这里只介绍一下 IV 向量的作用。

IV称为初始向量，不同的IV加密后的字符串是不同的，加密和解密需要相同的IV，既然IV看起来和key一样，却还要多一个IV的目的，对于每个块来说，key是不变的，但是只有第一个块的IV是用户提供的，其他块IV都是自动生成。
IV的长度为16字节。超过或者不足，可能实现的库都会进行补齐或截断。但是由于块的长度是16字节，所以一般可以认为需要的IV是16字节。

所以 metaInfo->m_vector 记录的就是 AES 的 IV 向量，其长度 AES_KEY_LEN 为 16。

接着就是 m_file 有效性检查 isFileValid。通过就进入下一阶段，否则尝试 reloadFromFile。

数据有效性

整个数据有效性是在 checkDataValid 中完成的，首先是读取 m_actualSize 。

readActualSize

size_t MMKV::readActualSize() {
    MMKV_ASSERT(m_file->getMemory());
    MMKV_ASSERT(m_metaFile->isFileValid());

    uint32_t actualSize = 0;
    memcpy(&actualSize, m_file->getMemory(), Fixed32Size);

    if (m_metaInfo->m_version >= MMKVVersionActualSize) {
        if (m_metaInfo->m_actualSize != actualSize) {
            MMKVWarning("[%s] actual size %u, meta actual size %u"，...);
        }
        return m_metaInfo->m_actualSize;
    } else {
        return actualSize;
    }
}

如果 m_metaInfo 记录了 m_actualSize 将其优先返回。否则以文件记录值为准。这里 actualSize 通过读取 m_file 头部的固定长度 Fixed32Size 的数据。

constexpr uint32_t LittleEdian32Size = 4;

constexpr uint32_t pbFixed32Size() {
    return LittleEdian32Size;
}

constexpr uint32_t Fixed32Size = pbFixed32Size();

其次，确认当前文件所剩余空间是否足够使用。前面提过对于未存储数据的部分默认是以 \0 填充的，因此这里需要将文件大小和真实数据大小进行比较。

void MMKV::checkDataValid(bool &loadFromFile, bool &needFullWriteback) {
    // try auto recover from last confirmed location
    auto fileSize = m_file->getFileSize();
    auto checkLastConfirmedInfo = [&] { ... }

    m_actualSize = readActualSize();

    if (m_actualSize < fileSize && (m_actualSize + Fixed32Size) <= fileSize) {
        if (checkFileCRCValid(m_actualSize, m_metaInfo->m_crcDigest)) {
            loadFromFile = true; /// 数据正确且剩余空间足够
        } else {
            checkLastConfirmedInfo();

           if (!loadFromFile) {
                ⚠️ Handler 3: 数据异常
            }
    } else {
        checkLastConfirmedInfo();

        if (!loadFromFile) {
            ⚠️ Handler 4: 空间不足
        }
    }
}

如果空间足够，则计算出当前 m_file 真实数据的 crc digest，并与 m_metaInfo 的 m_crcDigest 对比。

bool MMKV::checkFileCRCValid(size_t actualSize, uint32_t crcDigest) {
    auto ptr = (uint8_t *) m_file->getMemory();
    if (ptr) {
        m_crcDigest = (uint32_t) CRC32(0, (const uint8_t *) ptr + Fixed32Size, (uint32_t) actualSize);

        if (m_crcDigest == crcDigest) {
            return true;
        }
        MMKVError("check crc [%s] fail, crc32:%u, m_crcDigest:%u", ...);
    }
    return false;
}

另，关于 CRC 差错检测能力，移步百科。

校验通过就开始 m_file 内容的加载。

checkLastConfirmedInfo

如果数据异常或者空间不足，都会调用 checkLastConfirmedInfo 重新确认 loadFromFile 状态。checkLastConfirmedInfo 为 C++ 中的 lambda 函数，其声明在 checkDataValid 中，具体逻辑如下：

if (m_metaInfo->m_version >= MMKVVersionActualSize) {
    // downgrade & upgrade support
    uint32_t oldStyleActualSize = 0;
    memcpy(&oldStyleActualSize, m_file->getMemory(), Fixed32Size);
    if (oldStyleActualSize != m_actualSize) {
        MMKVWarning("oldStyleActualSize not equal to meta actual size" ...);
        if (oldStyleActualSize < fileSize && (oldStyleActualSize + Fixed32Size) <= fileSize) {
            if (checkFileCRCValid(oldStyleActualSize, m_metaInfo->m_crcDigest)) { ⚠️ Handler 1
                MMKVInfo("looks like [%s] been downgrade & upgrade again" ...);
                loadFromFile = true;
                writeActualSize(oldStyleActualSize, m_metaInfo->m_crcDigest, nullptr, KeepSequence);
                return;
            }
        } else {
            MMKVWarning("oldStyleActualSize greater than file size" ...);
        }
    }

    auto lastActualSize = m_metaInfo->m_lastConfirmedMetaInfo.lastActualSize;
    if (lastActualSize < fileSize && (lastActualSize + Fixed32Size) <= fileSize) {
        auto lastCRCDigest = m_metaInfo->m_lastConfirmedMetaInfo.lastCRCDigest;
        if (checkFileCRCValid(lastActualSize, lastCRCDigest)) { ⚠️ Handler 2
            loadFromFile = true;
            writeActualSize(lastActualSize, lastCRCDigest, nullptr, KeepSequence);
        } else {
            MMKVError("check lastActualSize, lastActualCRC error" ...);
        }
    } else {
        MMKVError("check lastActualSize, file size error" ...);
    }
}

在 MMKVMetaInfo 中的 m_lastConfirmedMetaInfo 可能记录了上一次校验过的 metaInfo，而只在 m_version 为 MMKVVersionActualSize 时，m_lastConfirmedMetaInfo 才有数据。故而 check 的前置条件为 >= MMKVVersionActualSize。

检查中有两次恢复正确 metaInfo 的机会：

Handler 1

oldStyleActualSize 记录值为 m_file 的内容数据大小，当其值不等于 m_metaInfo->m_actualSize 时，尝试以 oldStyleActualSize 为准更新 metaInfo 的信息。更新仍然要进行 CRC 校验，通过后将 loadFromFile 标记为 true，调用 writeActualSize 完成 metaInfo 的恢复。

Handler 2

最后一根救命稻草为 m_metaInfo->m_lastConfirmedMetaInfo.lastActualSize。用它再进行一次 Handler 1 的检查。

writeActualSize

用于更新 m_metaInfo 信息，包括 actualSize、crcDigest、IV、lastConfrimInfo。

bool MMKV::writeActualSize(size_t size, uint32_t crcDigest, const void *iv, bool increaseSequence) {
   // backward compatibility
   oldStyleWriteActualSize(size);

   if (!m_metaFile->isFileValid()) {
       return false;
   }

   bool needsFullWrite = false;
   m_actualSize = size;
   m_metaInfo->m_actualSize = static_cast<uint32_t>(size);
   m_crcDigest = crcDigest;
   m_metaInfo->m_crcDigest = crcDigest;
   if (m_metaInfo->m_version < MMKVVersionSequence) {
       m_metaInfo->m_version = MMKVVersionSequence;
       needsFullWrite = true;
   }
   if (unlikely(iv)) {
       memcpy(m_metaInfo->m_vector, iv, sizeof(m_metaInfo->m_vector));
       if (m_metaInfo->m_version < MMKVVersionRandomIV) {
           m_metaInfo->m_version = MMKVVersionRandomIV;
       }
       needsFullWrite = true;
   }
   if (unlikely(increaseSequence)) {
       m_metaInfo->m_sequence++;
       m_metaInfo->m_lastConfirmedMetaInfo.lastActualSize = static_cast<uint32_t>(size);
       m_metaInfo->m_lastConfirmedMetaInfo.lastCRCDigest = crcDigest;
       if (m_metaInfo->m_version < MMKVVersionActualSize) {
           m_metaInfo->m_version = MMKVVersionActualSize;
       }
       needsFullWrite = true;
   }
#ifdef MMKV_IOS
   return protectFromBackgroundWriting(m_metaFile->getMemory(), sizeof(MMKVMetaInfo), ^{
     if (unlikely(needsFullWrite)) {
         m_metaInfo->write(m_metaFile->getMemory());
     } else {
         m_metaInfo->writeCRCAndActualSizeOnly(m_metaFile->getMemory());
     }
   });
#else
   ...
#endif

前三个参数就不用说了，看最后参数 increaseSequence，类型如下：

enum : bool {
    KeepSequence = false,
    IncreaseSequence = true,
};

它用于控制是否更新文件的 full write-back count 及 needsFullWrite。needsFullWrite 相当于 dirty bit 的作用，每当 m_version 有更新，都会将 needsFullWrite 标记为 dirty 用于之后的写回更新。

write-back 概念后面会介绍。

checkDataValid

到这里，数据校验的主流程算是介绍完了，我们回到 checkDataValid，补上 checkLastConfirmedInfo 后数据状态依旧错误，loadlFromFile 为 false 的情况。

Handler 3 （标记在👆代码中）

auto strategic = onMMKVCRCCheckFail(m_mmapID);
if (strategic == OnErrorRecover) {
    loadFromFile = true;
    needFullWriteback = true;
}
MMKVInfo("recover strategic for [%s] is %d", m_mmapID.c_str(), strategic);

Handler 4

auto strategic = onMMKVFileLengthError(m_mmapID);
if (strategic == OnErrorRecover) {
    // make sure we don't over read the file
    m_actualSize = fileSize - Fixed32Size;
    loadFromFile = true;
    needFullWriteback = true;
}
MMKVInfo("recover strategic for [%s] is %d", m_mmapID.c_str(), strategic);

对于异常的处理策略，MMKV 为我们提供了修改的回调。策略有两种：

enum MMKVRecoverStrategic : int {
    OnErrorDiscard = 0,
    OnErrorRecover,
};

默认 MMKV 会丢弃当前数据、清空文件和 metaInfo。此时可通过 g_errorHandler 修改：

static MMKVRecoverStrategic onMMKVCRCCheckFail(const string &mmapID) {
    if (g_errorHandler) {
        return g_errorHandler(mmapID, MMKVErrorType::MMKVCRCCheckFail);
    }
    return OnErrorDiscard;
}

static MMKVRecoverStrategic onMMKVFileLengthError(const string &mmapID) {
    if (g_errorHandler) {
        return g_errorHandler(mmapID, MMKVErrorType::MMKVFileLength);
    }
    return OnErrorDiscard;
}

数据处理

校验完有效性，依据其结果 loadFromFile 和 needFullWriteback 值来判定后续操作。简化后的 loadFromFile：

void MMKV::loadFromFile() {
    /// 1. 文件有效性
    /// 2. 数据有效性
    ...
    bool loadFromFile = false, needFullWriteback = false;
    checkDataValid(loadFromFile, needFullWriteback);
    ...
    auto ptr = (uint8_t *) m_file->getMemory();

    if (loadFromFile && m_actualSize > 0) {
       MMKVInfo("loading [%s] with crc %u sequence %u version" ...);
       // loading    
    } else {
       // file not valid or empty, discard everything
       SCOPED_LOCK(m_exclusiveProcessLock);

       m_output = new CodedOutputData(ptr + Fixed32Size, m_file->getFileSize() - Fixed32Size);
       if (m_actualSize > 0) {
           writeActualSize(0, 0, nullptr, IncreaseSequence);
           sync(MMKV_SYNC);
       } else {
           writeActualSize(0, 0, nullptr, KeepSequence);
       }
   }
};

先看异常处理。

当校验失败或文件为空，直接调用 writeActualSize 清理 metaInfo 缓存。

如果文件异常，传入 IncreaseSequence 来设置 dirt bit，以待下次重载 m_file。

Loading

当 loadFromFile 为 true 且文件内容不为空，将数据从内存读入 MMBuffer，进行 AES 解密、清空 m_dic、准备 buffer 数据写入。

// loading
MMBuffer inputBuffer(ptr + Fixed32Size, m_actualSize, MMBufferNoCopy);
if (m_crypter) {
    decryptBuffer(*m_crypter, inputBuffer);
}
clearDictionary(m_dic);
if (needFullWriteback) {
    MiniPBCoder::greedyDecodeMap(m_dic, inputBuffer);
} else {
    MiniPBCoder::decodeMap(m_dic, inputBuffer);
}
m_output = new CodedOutputData(ptr + Fixed32Size, m_file->getFileSize() - Fixed32Size);
m_output->seek(m_actualSize);
if (needFullWriteback) {
    fullWriteback();
}

数据写入 m_dic 后，创建 CodedOutputData 对象来记录当前映射的内存指针和文件大小，通过 seek 来记录读取的文件位置。

最后，当 needFullWriteback 为 true 时进行文件写回 fullWriteback。

写入策略分为贪婪模式和普通两种：

void MiniPBCoder::decodeMap(MMKVMap &dic, const MMBuffer &oData, size_t size) {
    MiniPBCoder oCoder(&oData);
    oCoder.decodeOneMap(dic, size, false);
}

void MiniPBCoder::greedyDecodeMap(MMKVMap &dic, const MMBuffer &oData, size_t size) {
    MiniPBCoder oCoder(&oData);
    oCoder.decodeOneMap(dic, size, true);
}

区别在于 greed 会将所有 buffer 转成 k-v 保存在 m_dic 中。

在前面的数据校验中可知，仅当校验失败且恢复策略为 OnErrorRecover 会将 needFullWriteback 标记为 ture。就是说，当数据异常或空间不足时，会采用贪婪策略尽可能的将数据优先读入内存。

void MiniPBCoder::decodeOneMap(MMKVMap &dic, size_t size, bool greedy) {
    auto block = [size, this](MMKVMap &dictionary) {
        if (size == 0) {
            [[maybe_unused]] auto length = m_inputData->readInt32();
        }
        while (!m_inputData->isAtEnd()) {
            const auto &key = m_inputData->readString();
            if (key.length > 0) {
                auto value = m_inputData->readData();
                if (value.length() > 0) {
                    dictionary[key] = move(value);
                    [key retain];
                } else {
                    auto itr = dictionary.find(key);
                    if (itr != dictionary.end()) {
                        dictionary.erase(itr);
                        [itr->first release];
                    }
                }
            }
        }
    };

    if (greedy) {
        try {
            block(dic);
        } catch (std::exception &exception) {
            MMKVError("%s", exception.what());
        }
    } else {
        try {
            MMKVMap tmpDic;
            block(tmpDic);
            dic.swap(tmpDic);
            for (auto &pair : tmpDic) {
                [pair.first release];
            }
        } catch (std::exception &exception) {
            MMKVError("%s", exception.what());
        }
    }
}

fullWriteback

写回 (write-back) 作为缓存策略中的一种，其概念可以查看 wiki，简单描述如下：

仅当一个缓存块需要被替换回内存时，才将其内容写入内存。而为了减少内存写操作，通过脏位标识该块在被载入之后是否发生过更新。如果一个缓存块在被置换回内存之前从未被写入过，则可以免去回写操作。

MMKV 的写回操作就是将内存数据 m_dic 序列化后写回文件。

bool MMKV::fullWriteback() {
    ...
    auto allData = MiniPBCoder::encodeDataWithObject(m_dic);
    SCOPED_LOCK(m_exclusiveProcessLock);
    if (allData.length() > 0) {
        auto fileSize = m_file->getFileSize();
        if (allData.length() + Fixed32Size <= fileSize) {
            return doFullWriteBack(std::move(allData));
        } else {
            // ensureMemorySize will extend file & full rewrite, no need to write back again
            return ensureMemorySize(allData.length() + Fixed32Size - fileSize);
        }
    }
    return false;
}

操作前会检查几个状态：

  • m_hasFullWriteback：直接 return true
  • m_needLoadFromFile：直接 return true
  • isFileValid() 为 false：直接 return false
  • m_dic.empty() ：clearAll() 后 return true

既然是数据读取，如果 m_dic 为空，认为数据可能出现异常。将会清理临时数据和内存缓存、重置相关标记位、重新加载文件。

void MMKV::clearAll() {
    MMKVInfo("cleaning all key-values from [%s]", m_mmapID.c_str());
    SCOPED_LOCK(m_lock);
    SCOPED_LOCK(m_exclusiveProcessLock);

    if (m_needLoadFromFile) {
        m_file->reloadFromFile();
    }

    m_file->truncate(DEFAULT_MMAP_SIZE);
    auto ptr = m_file->getMemory();
    if (ptr) {
        memset(ptr, 0, m_file->getFileSize());
    }
    m_file->msync(MMKV_SYNC);

    unsigned char newIV[AES_KEY_LEN];
    AESCrypt::fillRandomIV(newIV);
    if (m_crypter) {
        m_crypter->resetIV(newIV, sizeof(newIV));
    }
    writeActualSize(0, 0, newIV, IncreaseSequence);
    m_metaFile->msync(MMKV_SYNC);

    clearMemoryCache();
    loadFromFile();
}

检查通过后，将 m_dic 转换为 MiniPBCoder 即 binary data，写入前会确认当前文件 size 是否足够满足当前数据的写入，否则进行扩容。

doFullWriteBack

首先，生成 AES 随机 IV 对 allData 进行加密，接着通过 CodedOutputData 把 MMBuffer 写入 m_file，最后更新 crc 校验值。

bool MMKV::doFullWriteBack(MMBuffer &&allData) {
#ifdef MMKV_IOS
    unsigned char oldIV[AES_KEY_LEN];
    unsigned char newIV[AES_KEY_LEN];
    if (m_crypter) {
        memcpy(oldIV, m_crypter->m_vector, sizeof(oldIV));
#else
    unsigned char newIV[AES_KEY_LEN];
    if (m_crypter) {
#endif
        AESCrypt::fillRandomIV(newIV);
        m_crypter->resetIV(newIV, sizeof(newIV));
        auto ptr = allData.getPtr();
        m_crypter->encrypt(ptr, ptr, allData.length());
    }

    auto ptr = (uint8_t *) m_file->getMemory();
    delete m_output;
    m_output = new CodedOutputData(ptr + Fixed32Size, m_file->getFileSize() - Fixed32Size);
#ifdef MMKV_IOS
    auto ret = protectFromBackgroundWriting(m_output->curWritePointer(), allData.length(), ^{
      m_output->writeRawData(allData); // note: don't write size of data
    });
    if (!ret) {
        // revert everything
        if (m_crypter) {
            m_crypter->resetIV(oldIV);
        }
        delete m_output;
        m_output = new CodedOutputData(ptr + Fixed32Size, m_file->getFileSize() - Fixed32Size);
        m_output->seek(m_actualSize);
        return false;
    }
#else
    m_output->writeRawData(allData); // note: don't write size of data
#endif

    m_actualSize = allData.length();
    if (m_crypter) {
        recaculateCRCDigestWithIV(newIV);
    } else {
        recaculateCRCDigestWithIV(nullptr);
    }
    m_hasFullWriteback = true;
    // make sure lastConfirmedMetaInfo is saved
    sync(MMKV_SYNC);
    return true;
}

recaculateCRCDigestWithIV

void MMKV::recaculateCRCDigestWithIV(const void *iv) {
auto ptr = (const uint8_t *) m_file->getMemory();
if (ptr) {
    m_crcDigest = 0;
    m_crcDigest = (uint32_t) CRC32(0, ptr + Fixed32Size, (uint32_t) m_actualSize);
    writeActualSize(m_actualSize, m_crcDigest, iv, IncreaseSequence);
}

注意，重新生成 crc digest 这一行为只有在 full write-back 中被调用。尽管这里调用 writeActualSize 更新 m_metaInfo 并增加了 m_sequence，但是 actualSize 并没有变化。

ensureMemorySize

除了完全写回的情况，当 append 的数据超出 fileSize 也会进行扩容。扩容策略以 2 倍于原来的 fileSize，不断扩充，直到比扩充的额外容量大为止。最后通过 truncate 裁剪至 DEFAULT_MMAP_SIZE 的整数倍。

核心逻辑如下：

constexpr size_t ItemSizeHolderSize = 4;
if (m_dic.empty()) {
    newSize += ItemSizeHolderSize;
}
if (newSize >= m_output->spaceLeft() || m_dic.empty()) {
    auto fileSize = m_file->getFileSize();
    MMBuffer data = MiniPBCoder::encodeDataWithObject(m_dic);
    size_t lenNeeded = data.length() + Fixed32Size + newSize;
    size_t avgItemSize = lenNeeded / std::max<size_t>(1, m_dic.size());
    size_t futureUsage = avgItemSize * std::max<size_t>(8, (m_dic.size() + 1) / 2);
    // 所需空间 >= 当前文件大小 || 所需空间的 1.5 倍于当前文件大小
    if (lenNeeded >= fileSize || (lenNeeded + futureUsage) >= fileSize) {
        size_t oldSize = fileSize;
        do {
            fileSize *= 2;
        } while (lenNeeded + futureUsage >= fileSize);

        if (!m_file->truncate(fileSize)) {
            return false;
        }

        if (!isFileValid()) {
            MMKVWarning("[%s] file not valid", m_mmapID.c_str());
            return false;
        }
    }
    return doFullWriteBack(std::move(data));
}

Setter

改版后 iOS 端的 setter 则直接在 C++ API 上套了一层。

bool set(bool value, MMKVKey_t key);
...
   
// avoid unexpected type conversion (pointer to bool, etc)
template <typename T>
bool set(T value, MMKVKey_t key) = delete;
bool set(NSObject<NSCoding> *__unsafe_unretained obj, MMKVKey_t key);

先以 bool 为例：

bool MMKV::set(bool value, MMKVKey_t key) {
    if (isKeyEmpty(key)) {
        return false;
    }
    size_t size = pbBoolSize();
    MMBuffer data(size);
    CodedOutputData output(data.getPtr(), size);
    output.writeBool(value);

    return setDataForKey(std::move(data), key);
}

value 通过 CodedOutputData 写入 MMBuffer，最后走向了 setDataForKey。其他数据类型也是一样套路。

setDataForKey

更新 k-v 的核心方法，承接了全部数据更新的入口，做了三件事情：

  1. 数据校验，确认是否需要刷新缓存，重新加载文件；
  2. 将 buffer 数据写入文件；
  3. 更新 m_dic;
bool MMKV::setDataForKey(MMBuffer &&data, MMKVKey_t key) {
    if (data.length() == 0 || isKeyEmpty(key)) {
        return false;
    }
    SCOPED_LOCK(m_lock);
    SCOPED_LOCK(m_exclusiveProcessLock);
    checkLoadData();

    auto ret = appendDataWithKey(data, key);
    if (ret) {
        m_dic[key] = std::move(data);
        m_hasFullWriteback = false;
#ifdef MMKV_APPLE
        [key retain];
#endif
    }
    return ret;
}

整个 MMKV.cpp 文件中就这方法里冒出来一行 [key retain]，这也是为啥这里 MMKV.cpp 采用 MRC 的原因。至于为啥要 retain 大家可以 🤔 一下。

checkLoadData

数据校验，第一步是确认 m_needLoadFromFile 为 true，是则加锁执行 loadFromFile。

接下来的检查是防止文件被其他进程篡改，对于单进程则无需考虑该 case，直接 return。

void MMKV::checkLoadData() {
    if (m_needLoadFromFile) {
        SCOPED_LOCK(m_sharedProcessLock);

        m_needLoadFromFile = false;
        loadFromFile();
        return;
    }
    if (!m_isInterProcess) { // single process
        return;
    }

    if (!m_metaFile->isFileValid()) {
        return;
    }
    // TODO: atomic lock m_metaFile?
    MMKVMetaInfo metaInfo;
    metaInfo.read(m_metaFile->getMemory());
    if (m_metaInfo->m_sequence != metaInfo.m_sequence) {
        MMKVInfo("[%s] oldSeq %u, newSeq %u", ...);
        SCOPED_LOCK(m_sharedProcessLock);

        clearMemoryCache();
        loadFromFile();
        notifyContentChanged();
    } else if (m_metaInfo->m_crcDigest != metaInfo.m_crcDigest) {
        MMKVDebug("[%s] oldCrc %u, newCrc %u, new actualSize" ...);
        SCOPED_LOCK(m_sharedProcessLock);

        size_t fileSize = m_file->getActualFileSize();
        if (m_file->getFileSize() != fileSize) {
            MMKVInfo("file size has changed [%s] from %zu to %zu" ...);
            clearMemoryCache();
            loadFromFile();
        } else {
            partialLoadFromFile();
        }
        notifyContentChanged();
    }
}

防止文件的多进程篡改，会先读取 crc 文件中记录的 metaInfo 与当前内存的 m_metaInfo 对比。metaInfo 中的数据更新都在 writeActualSize 中完成。而当文件读取异常、空间不足或 crc 校验失败，这些情况发生时，会触发 meta_info 的变更。具体处理：

  1. m_sequence 代表了脏位数据 dirt bit 存在，此时需要 重新加载 m_file。
  2. m_crcDigest 不同且 fileSize 不同，说明进行了扩容，也需要重新加载 m_file。
  3. m_crcDigest 不同且 fileSize 相同，说明进行了 full write-back，之后会通过 partialLoadFromFile 完成相关内存数据的更新。

appendData

官方说明

标准 protobuf 不提供增量更新的能力，每次写入都必须全量写入。考虑到主要使用场景是频繁地进行写入更新，我们需要有增量更新的能力：将增量 kv 对象序列化后，直接 append 到内存末尾；这样同一个 key 会有新旧若干份数据，最新的数据在最后；那么只需在程序启动第一次打开 mmkv 时，不断用后读入的 value 替换之前的值，就可以保证数据是最新有效的。

bool MMKV::appendDataWithKey(const MMBuffer &data, MMKVKey_t key) {
#ifdef MMKV_APPLE
    auto keyData = [key dataUsingEncoding:NSUTF8StringEncoding];
    size_t keyLength = keyData.length;
#else
    size_t keyLength = key.length();
#endif
    // size needed to encode the key
    size_t size = keyLength + pbRawVarint32Size((int32_t) keyLength);
    // size needed to encode the value
    size += data.length() + pbRawVarint32Size((int32_t) data.length());

    SCOPED_LOCK(m_exclusiveProcessLock);

    bool hasEnoughSize = ensureMemorySize(size);
    if (!hasEnoughSize || !isFileValid()) {
        return false;
    }

#ifdef MMKV_IOS
    auto ret = protectFromBackgroundWriting(m_output->curWritePointer(), size, ^{
      m_output->writeData(MMBuffer(keyData, MMBufferNoCopy));
      m_output->writeData(data); // note: write size of data
    });
    if (!ret) {
        return false;
    }
#else
    ... /// 除了 iOS 需要判断 background mode，其余均直接 m_output->writeData(data);
#endif
    ... // encrypt 数据，更新 m_actualSize、crcDigest
    return true;
}

追加逻辑比较简单，就是将存储 Key、Data 的 MMBuffer 经过 pb 压缩后写入 m_file。直接追加到 m_file 末尾带来的问题就是空间快速增长，导致文件大小不可控。因此，每次写入需要检查剩余文件空间。

Set Object

再来看看 Objc 中的 NSObject 是如何存取的。

bool MMKV::set(NSObject<NSCoding> *__unsafe_unretained obj, MMKVKey_t key) {
    if (isKeyEmpty(key)) {
        return false;
    }
    if (!obj) {
        removeValueForKey(key);
        return true;
    }
    MMBuffer data;
    if (MiniPBCoder::isCompatibleObject(obj)) {
        data = MiniPBCoder::encodeDataWithObject(obj);
    } else {
        /*if ([object conformsToProtocol:@protocol(NSCoding)])*/ {
            auto tmp = [NSKeyedArchiver archivedDataWithRootObject:obj];
            if (tmp.length > 0) {
                data = MMBuffer(tmp);
            }
        }
    }

    return setDataForKey(std::move(data), key);
}

对 Objc 而言 MiniPBCoder 仅支持了基本数据类型和 NSString、NSData、NSDate 这三种：

bool MiniPBCoder::isCompatibleObject(NSObject *obj) {
    if ([obj isKindOfClass:[NSString class]]) {
        return true;
    }
    if ([obj isKindOfClass:[NSData class]]) {
        return true;
    }
    if ([obj isKindOfClass:[NSDate class]]) {
        return true;
    }

    return false;
}

其余 NSObject 对象就需要走 NSCoding 协议通过 NSArchive 方式编码为 NSData 存入。

Getter

bool getBool(MMKVKey_t key, bool defaultValue = false);
...

#ifdef MMKV_APPLE
    NSObject *getObject(MMKVKey_t key, Class cls);
#else  // !defined(MMKV_APPLE)
    mmkv::MMBuffer getBytes(MMKVKey_t key);
    bool getVector(MMKVKey_t key, std::vector<std::string> &result);
#endif // MMKV_APPLE

以 bool 为例：

bool MMKV::getBool(MMKVKey_t key, bool defaultValue) {
    if (isKeyEmpty(key)) {
        return defaultValue;
    }
    SCOPED_LOCK(m_lock);
    auto &data = getDataForKey(key);
    if (data.length() > 0) {
        try {
            CodedInputData input(data.getPtr(), data.length());
            return input.readBool();
        } catch (std::exception &exception) {
            MMKVError("%s", exception.what());
        }
    }
    return defaultValue;
}

数据读取就更简单了，直接从 getDataForKey 中取出 MMBuffer，经过 CodedOutputData 转换得到 bool。

getDataForKey

const MMBuffer &MMKV::getDataForKey(MMKVKey_t key) {
    checkLoadData();
    auto itr = m_dic.find(key);
    if (itr != m_dic.end()) {
        return itr->second;
    }
    static MMBuffer nan;
    return nan;
}

Get Object

NSObject *MMKV::getObject(MMKVKey_t key, Class cls) {
    if (isKeyEmpty(key) || !cls) {
        return nil;
    }
    SCOPED_LOCK(m_lock);
    auto &data = getDataForKey(key);
    if (data.length() > 0) {
        if (MiniPBCoder::isCompatibleClass(cls)) {
            try {
                auto result = MiniPBCoder::decodeObject(data, cls);
                return result;
            } catch (std::exception &exception) {
                MMKVError("%s", exception.what());
            }
        } else {
            if ([cls conformsToProtocol:@protocol(NSCoding)]) {
                auto tmp = [NSData dataWithBytesNoCopy:data.getPtr() length:data.length() freeWhenDone:NO];
                return [NSKeyedUnarchiver unarchiveObjectWithData:tmp];
            }
        }
    }
    return nil;
}

这个也比较简单就不展开了。

总结

宁可错杀一千，也绝不放过一个。

这是整体读完 MMKV 核心逻辑的第一感受。为什么呢？

MMKV 作为多进程读写的框架。细心的同学可以发现，在它的每一个方法的真正逻辑执行前都进行了大量的异常校验，同时对于脏数据的保护和容错也比较绕。感觉你不把所有方法看过一遍，比较难 get 到其中的用意。相比这一点，CocoaLumberjack 的代码就非常友好了，每个关键字段的作用，核心逻辑的解释，以及背后的一些原理都有很详细的注释。

本文忽略了 MiniPB 的编解码逻辑和读写锁保护，以核心逻辑文件读写为主。MMKV 对于只要异常就是各种标记，然后重载。整个框架也是围绕 loadFromFile 不断的添加保护，文件锁，crc 校验，脏数据写回。

如果你看到这里，应该能发现，本文是按照调用逻辑一层层深入，尽可能地让各个方法的上下文是衔接有序。希望能帮助各位大致了解 MMKV 的核心逻辑。

©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 212,029评论 6赞 492
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 90,395评论 3赞 385
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 157,570评论 0赞 348
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 56,535评论 1赞 284
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 65,650评论 6赞 386
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 49,850评论 1赞 290
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 39,006评论 3赞 408
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 37,747评论 0赞 268
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 44,207评论 1赞 303
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,536评论 2赞 327
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,683评论 1赞 341
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 34,342评论 4赞 330
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 39,964评论 3赞 315
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,772评论 0赞 21
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,004评论 1赞 266
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 46,401评论 2赞 360
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 43,566评论 2赞 349