浅析 - MMKV 1.1.1

时间  2021-08-13
标签 html linux android c++ git github objective-c 算法 缓存 安全 栏目 HTML 繁體版
原文   原文链接

mmkv.png

介绍

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.html

做为一个精简易用且性能强悍的全平台 K-V 存储框架，MMKV 有以下特色：linux

  • 高效：
    • 利用 mmap 直接将文件映射到内存；
    • 利用 protobuf 对键值进行编解码压缩；
    • 多进程并发；
  • 易用：无需手动 synchronize 和配置，全程自动同步；
  • 精简.
    • 少许的文件: 仅包括了编解码工具类和 mmap 逻辑代码，无冗余依赖；
    • 二进制文件仅小于 30K: 如为 ipa 文件则会更小；

具体性能，微信团队提供了简单的 benchmark。总之就是秒杀苹果的 NSUserDefaults，性能差别达 100 多倍。android

说明，如今你们看到的这篇文章是重写的 2.0 版本。就在前不久，MMKV 悄摸地发布了主版本更新 v1.1.0，而原有的实现已面目全非 💔，缘由详见：c++

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.git

另，本篇涉及大量 C++ 实现，若是描述有误望及时指出。github

准备工做

在开始以前，咱们须要了解几个概念，熟悉的同窗可 pass。objective-c

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));
}
复制代码

最后来看一下简化版的数据流：

mmkv-structure.png

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 的核心逻辑。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程