淺析 - 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教程