介紹
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 直接將文件映射到內(nèi)存；
- 利用 protobuf 對鍵值進行編解碼壓縮；
- 多進程并發(fā)；
-
易用：無需手動
synchronize和配置，全程自動同步； -
精簡.
- 少量的文件: 僅包括了編解碼工具類和 mmap 邏輯代碼，無冗余依賴；
- 二進制文件僅小于 30K: 如為 ipa 文件則會更??；
具體性能，微信團隊提供了簡單的 benchmark?？傊褪敲霘⑻O果的 NSUserDefaults，性能差異達 100 多倍。
說明，現(xiàn)在大家看到的這篇文章是重寫的 2.0 版本。就在前不久，MMKV 悄摸地發(fā)布了主版本更新 v1.1.0，而原有的實現(xiàn)已面目全非 ??，原因詳見：
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++ 實現(xiàn)，如果描述有誤望及時指出。
準備工作
在開始之前，我們需要了解幾個概念，熟悉的同學可 pass。
mmap是一種內(nèi)存映射文件的方法，即將一個文件或者其它對象映射到進程的地址空間，實現(xiàn)文件磁盤地址和進程虛擬地址空間中一段虛擬地址的一一對映關系。實現(xiàn)這樣的映射關系后，進程就可以采用指針的方式讀寫操作這一段內(nèi)存，而系統(tǒng)會自動回寫臟頁面到對應的文件磁盤上，即完成了對文件的操作而不必再調(diào)用read,write等系統(tǒng)調(diào)用函數(shù)。相反，內(nèi)核空間對這段區(qū)域的修改也直接反映用戶空間，從而可以實現(xiàn)不同進程間的文件共享。
通常，我們的文件讀寫操作需要頁緩存作為內(nèi)核和應用層的中轉(zhuǎn)。因此，一次文件操作需要兩次數(shù)據(jù)拷貝（內(nèi)核到頁緩存，頁緩存到應用層），而 mmap 實現(xiàn)了用戶空間和內(nèi)核空間數(shù)據(jù)的直接交互而省去了頁緩存。當然有利也有弊，如 蘋果文檔 所述，想高效使用 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.
因此，當我們需要高頻率的訪問某一較大文件中的一小部分內(nèi)容的時候，mmap 的效率是最高的。
其實不光是 MMKV 包括微信的 XLog 和 美團的 Logan 日志工具，還有 SQLight 都使用 mmap 來提升高頻更新場景下的文件訪問效率。
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 是一種將結(jié)構(gòu)化數(shù)據(jù)進行序列化的方法。它最初是為了解決服務器端新舊協(xié)議（高低版本）兼容性問題而誕生的。因此，稱為“協(xié)議緩沖區(qū)”，只不過后期慢慢發(fā)展成用于傳輸數(shù)據(jù)和存儲等。
MMKV 正是考慮到了 protobuf 在性能和空間上的不錯表現(xiàn)，以簡化版 protobuf 作為序列化方案，還擴展了 protobuf 的增量更新的能力，將 K-V 對象序列化后，直接 append 到內(nèi)存末尾進行序列化。
那 Protobuf 是如何實現(xiàn)高效編碼？
- 以
Tag - Value(Tag - Length - Value)的編碼方式的實現(xiàn)。減少了分隔符的使用，數(shù)據(jù)存儲更加緊湊； - 利用
base 128 varint(變長編碼）原理壓縮數(shù)據(jù)以后，二進制數(shù)據(jù)非常緊湊，pb 體積更小。不過 pb 并沒有壓縮到極限，float、double 浮點型都沒有壓縮； - 相比 JSON 和 XML 少了
{、}、:這些符號，體積也減少一些。再加上 varint、gzip 壓縮以后體積更小。
循環(huán)冗余校驗（Cyclic redundancy check）是一種根據(jù)網(wǎng)絡數(shù)據(jù)包或計算機文件等數(shù)據(jù)產(chǎn)生簡短固定位數(shù)校驗碼的一種散列函數(shù)，主要用來檢測或校驗數(shù)據(jù)傳輸或者保存后可能出現(xiàn)的錯誤。生成的數(shù)字在傳輸或者存儲之前計算出來并且附加到數(shù)據(jù)后面，然后接收方進行檢驗確定數(shù)據(jù)是否發(fā)生變化。
同樣是用于計算校驗值，相比 MD5 或者 SHA1，CRC 的計算效率較高，安全性較弱?？紤]到文件系統(tǒng)、操作系統(tǒng)都有一定的不穩(wěn)定性，MMKV 增加了 CRC 校驗，對無效數(shù)據(jù)進行甄別。
在 iOS 微信現(xiàn)網(wǎng)環(huán)境上，有平均約 70萬日次的數(shù)據(jù)校驗不通過。
初始化
在 v1.1.0 版本 Tencent 團隊重寫了整個 MMVK 項目，統(tǒng)一跨平臺核心庫。自此 MMKV 在 iOS/macOS, Android, Win32 共享同一份核心邏輯。在一定程度上提高了可維護性，以及優(yōu)勢共享。也正是由于這一點，在 iOS/macOS 上可以實現(xiàn) Multi-Process Access。
在代碼結(jié)構(gòu)上，MMKV 獨立出單獨的 MMVKCore，Apple 平臺基于 MMKV Core 做了一層 Objc 的封裝。
原有的實現(xiàn)基本都遷移到 MMKV Core 中并替換成了 C++ 實現(xiàn)。對不同平臺的所獨有的 API 或邏輯通過不同的文件名和宏來隔離。以 MemoryFile 為例：
MemoryFile.h
MemoryFile.cpp
MemoryFile_Android.cpp
MemoryFile_OSX.cpp
MemoryFile_Win32.cpp
本篇我們重點關注 Apple 相關邏輯。
Class Initialize
MMKV 在使用前的準備工作分成兩個階段：
- 初始化
g_instanceDic等靜態(tài)變量。它在應用啟動時的 pre_main 函數(shù)前，在 MMKV class 的+ initialize里完成的。 - 需要用戶手動執(zhí)行
+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 時，發(fā)現(xiàn)早期版本確實用到了 dispatch_once 來避免重入。而現(xiàn)在換成這種寫法難道是
用了什么新特性嗎？
我們知道 +initialize 是有可能被多次調(diào)用的，但是對其如何被多次調(diào)用，被誰多次調(diào)用，這里理解有誤。
以 MMKV 為例，假設我們聲明 MMKVTest 作為其 MMKV 的子類，但未實現(xiàn) +initialize 或者 MMKVTest 在其 +initialize 中顯式的調(diào)用 [super initialize] 方法，那么 MMKV 的 +initialize 才會被調(diào)用多次。
但是忽略了很重要的一點，+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);
}
該方法以最低限度把必須要完成的事情放到了應用的啟動前，主要三件事：
- 執(zhí)行 initialize 完成全局變量的 init。
- 確定 CRC 校驗的算法；
- 生成 mmkv 根目錄；
Initialize
ThreadLock::ThreadOnce 背后以 pthread_once 來保證單詞調(diào)用，以完成 initialize()，最后用 g_rootDir 創(chuàng)建對應的文件目錄。來看私有的 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 實現(xiàn)中也維護了 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 就是正兒八經(jīng)的函數(shù)指針，默認指向的是：
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)));
}
不過這里作者做了優(yōu)化，當 CPU 架構(gòu)為 aarch64，則改換了 mmkv::armv8_crc32 的實現(xiàn)。由于 crc32 指令需要A10芯片，也就是 iPhone 7 或 iPad 的第六代。因此，這個通過 GetAppleMachineInfo 獲取設備和系統(tǒng)版本來判斷。
最后一步，獲取內(nèi)存頁的大小用于后續(xù)文件存取時計算所需內(nèi)存，并存入 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 靜態(tài)變量；
注冊的兩個 Notification 的方法為：didEnterBackground 和 didBecomeActive，用于監(jiān)聽 UIApplicationState 在前后臺的狀態(tài)變化。在注冊通知時，也會獲取了當前 applicationState 并通過方法：
void MMKV::setIsInBackground(bool isInBackground)
來更新 g_isInBackground。這么做是為了保證在后臺時能夠安全的執(zhí)行文件寫入。
InitializeMMKV
真正使用前還需要手動調(diào)用一次 +initializeMMKV: logLevel: 或其相關 convene method。
方法內(nèi)部使用 static BOOL g_hasCalledInitializeMMKV 來防止被多次調(diào)用:
if (g_hasCalledInitializeMMKV) {
MMKVWarning("already called +initializeMMKV before, ignore this request");
return [self mmkvBasePath];
}
g_hasCalledInitializeMMKV = YES;
initializeMMKV: 第一個參數(shù)為 rootDir 用于更新 g_basePath，為空的話就用默認值。接著傳入 logLevel，執(zhí)行 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);
}
這里同樣也調(diào)用了 ThreadLock::ThreadOnce 保證 MMKV Core 能夠成功初始化。
在 1.1 版本中，由于底層實現(xiàn)的統(tǒng)一，iOS 端可以支持多進程調(diào)用，這里多出來一個控制參數(shù)，對應的方法為：
+initializeMMKV: groupDir: logLevel:。內(nèi)部也是走上面的方法，不過多出來一個全局變量：
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 是否執(zhí)行過 +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 中已經(jīng)做了很明確的說明了。
初始化 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，用于關聯(lián)生成的 mmkv 實例，最終存儲在 g_instanceDic 中。如果 relativePath 為有效字符串，key 值為 relativePath 和 mmapID 拼接后的的 md5 值。
接著，嘗試通過 key 來獲取實例。沒有的話就需要進行初始化，并將 mmkv 實例保存到 g_instanceDic。
這里每個實例本身也會將 key 保存在 m_mmapKey 中，以待其結(jié)束時，將自身從 g_instanceDic 中移除。
initWithMMapID
通過 MMKV Core 的 mmkv::MMKV::mmkvWithID 方法來獲取 m_mmkv 實例。參數(shù)就是將 mmapID、cryptKey、relativePath 轉(zhuǎn)為 c string 傳入。
同類的初始化一樣，MMKV Core 構(gòu)造函數(shù)的實現(xiàn)與 iOS 側(cè)無異，只是用 C++ 的方式再做了一遍。這里除了對 variable 進行默認值的賦值之外，最終調(diào)用 loadFromFile() 來加載 mmkv 文件和 CRC 文體。MMKV 的構(gòu)造函數(shù)完整實現(xiàn)就不貼出來了，簡單看一下聲明吧：
#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
本節(jié)，會稍微介紹一下 MMKV 中用到的相關數(shù)據(jù)結(jié)構(gòu)和一些變量。對主要數(shù)據(jù)結(jié)構(gòu)有基本了解后，在解釋實現(xiàn)時我們更能夠 Focus 在核心邏輯。
先來看 MMKV 的實例變量：
mmkv::MMKVMap m_dic; /// 保存當前映射到內(nèi)存的 k-v
std::string m_mmapID;
MMKVPath_t m_path; // mmkv path
MMKVPath_t m_crcPath; // crc file path
mmkv::MemoryFile *m_file; // mmap 映射真實數(shù)據(jù)文件的相關信息，包括 file descrpitot 等
size_t m_actualSize; //當前 k-v 占用內(nèi)存大小
mmkv::CodedOutputData *m_output; // 映射內(nèi)存所剩余空間
bool m_needLoadFromFile; // 標記是否需要重新載入 m_file
bool m_hasFullWriteback; // 是否需要執(zhí)行寫回，例如 m_file 讀取失敗，內(nèi)存異常等等
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; // 加密器，文件內(nèi)容更新后會重新計算加密值
mmkv::ThreadLock *m_lock; // k-v 文件鎖
mmkv::FileLock *m_fileLock; // crc 文件鎖
mmkv::InterProcessLock *m_sharedProcessLock; // 讀鎖
mmkv::InterProcessLock *m_exclusiveProcessLock; // 寫鎖
上述變量會在 MMKV 構(gòu)造函數(shù)調(diào)用時完成 initialize。
MMKVMap
首先是 MMKVMap，它區(qū)分了 Apple 系和其他系統(tǒng)。如果是 Apple 系，則使用 NSString 為 key，value 不僅是 MMBuffer 類型，需要實現(xiàn) KeyHasher 和 KeyEqualer 協(xié)議，畢竟 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 中存儲的數(shù)據(jù)類型是 MMBuffer 而非真實數(shù)據(jù)類型。只有當我們通過 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 的方式進行內(nèi)存管理的，其他的 C++ 類則使用了 ARC，可以查看 MMKVCore.podspec:
s.requires_arc = ['Core/MemoryFile.cpp', ...]
這里并未發(fā)現(xiàn)包含了 MMKV.cpp 文件，后續(xù)代碼中會說明。
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 內(nèi)存的起始地址
size_t m_size; // 表示的是文件按照內(nèi)存整數(shù)頁截斷后的 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 等。
非安卓平臺構(gòu)造函數(shù)只需 filePath，其余變量均通過 reloadFromFile() 來獲取。這里多說一嘴 FileType:
enum FileType : bool { MMFILE_TYPE_FILE = false, MMFILE_TYPE_ASHMEM = true };
MMFILE_TYPE_ASHMEM 指 Android 中所獨有的匿名共享內(nèi)存方式 ASharedMemory，本質(zhì)也是 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 來完成內(nèi)存映射。
接著判斷 fd 是否指向有效內(nèi)存：
#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
如果有效，則會執(zhí)行 MemoryFile::clearMemoryCache() ，內(nèi)部先調(diào)用 mumap(m_ptr, m_size) 清理內(nèi)存緩存，再關閉文件訪問 close(m_fd) 還原 m_fd 和 m_size。
在 mmap 前會有一個內(nèi)存取整的檢查，以保證所映射的數(shù)據(jù)是內(nèi)存頁 DEFAULT_MMAP_SIZE 的整數(shù)倍，以減少內(nèi)存碎片。
最后，在 iOS 上會調(diào)整文件的讀寫保護，前面在注冊通知中提到過，為了確保應用在后臺時能安全的進行文件訪問，而不至于被系統(tǒng)錯殺 ??。
truncate
內(nèi)存區(qū)取整。
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) 后才進行取整。兩步走：
對文件擴容或裁剪，并將 file offset 更新至當前容量的最后位置。由于 truncate 并不會操作 file offset 所以需要借助 lseek，剩余的部分均用 '\0' 寫入。
munmap + mmap
由于 mmap 關聯(lián)的是 oldSize 的內(nèi)存，而現(xiàn)在我們調(diào)整了 m_size 大小，需要重新綁定文件與內(nèi)存關系。
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
// 數(shù)據(jù)讀寫方法 ...
}
就是一段連續(xù)的內(nèi)存地址，在 Apple 上則用 NSData 指向，其他平臺則是通過 ptr + size 來引用。
在 MMKV 中不論是從數(shù)據(jù)寫入文件還是從文件中讀取，統(tǒng)一轉(zhuǎn)換為 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);
/// 其他基本數(shù)據(jù)類型寫入 ...
}
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; };
/// 其他基本數(shù)據(jù)類型讀取 ...
}
CodedInputData 和 CodedOutputData 主要用于真實數(shù)據(jù)類型和 MMBuffer 之間轉(zhuǎn)換，關系如下：
MMBuffer -> Input -> 真實數(shù)據(jù) -> output -> MMBuffer
CodedInputData 將 binary Data 從 MMBuffer 中讀取出來，轉(zhuǎn)換為真實數(shù)據(jù)類型；
CodedOutputData 則將真實數(shù)據(jù)類型轉(zhuǎn)換為 binaryData 輸出到 MMBuffer 中；
可見，它們兩起到了橋梁的作用，完成了真實數(shù)據(jù)和 MMBuffer 的相互轉(zhuǎn)換。
InterProcessLock
MMKV 采用文件鎖來處理多進程中的文件訪問。用排他鎖作為寫鎖，用共享鎖作為讀鎖。 這里沒有直接使用系統(tǒng)的 flock 而是用 FileLock 將其封裝了一層，讀寫鎖均為 InterProcessLock 本質(zhì)為 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 文件鎖。
由于本文篇幅較長，很多描述中忽略了鎖相關的細節(jié)（其實非常重要的），之后會單獨開篇來聊聊。
LoadData
本節(jié)主要介紹 MMKV 如何從文件中讀取數(shù)據(jù)、異常數(shù)據(jù)處理、以及如何利用 CRC 來校驗文件的完整性。
在應用首次初始化、數(shù)據(jù)異常，內(nèi)存警告、清理數(shù)據(jù)時都會執(zhí)行 loadFromFile() 來刷新內(nèi)存中對應的數(shù)據(jù)，保證其準確性。整個 m_file 加載主要分三步：
- 校驗 CRC 文件、m_file 的有效性，初始化 AESCrypter；
- 檢查文件內(nèi)部數(shù)據(jù)的有效性；
- 加載數(shù)據(jù)到內(nèi)存。
文件有效性
在 MMKV 構(gòu)造函數(shù)執(zhí)行時，m_metaFile 為本地 crc 文件的內(nèi)存映射，而 m_metaInfo 則記錄了當前內(nèi)存數(shù)據(jù)的相關 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 表示當前緩存的內(nèi)容數(shù)據(jù)的狀態(tài)，初始值為 MMKVVersionSequence。有以下幾種：
enum MMKVVersion : uint32_t {
MMKVVersionDefault = 0,
// 記錄了完全回寫的次數(shù)
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 來完成對數(shù)據(jù)的加密。
關于 AES 的介紹可以看 WiKi，這里只介紹一下 IV 向量的作用。
IV稱為初始向量，不同的IV加密后的字符串是不同的，加密和解密需要相同的IV，既然IV看起來和key一樣，卻還要多一個IV的目的，對于每個塊來說，key是不變的，但是只有第一個塊的IV是用戶提供的，其他塊IV都是自動生成。
IV的長度為16字節(jié)。超過或者不足，可能實現(xiàn)的庫都會進行補齊或截斷。但是由于塊的長度是16字節(jié)，所以一般可以認為需要的IV是16字節(jié)。
所以 metaInfo->m_vector 記錄的就是 AES 的 IV 向量，其長度 AES_KEY_LEN 為 16。
接著就是 m_file 有效性檢查 isFileValid。通過就進入下一階段，否則嘗試 reloadFromFile。
數(shù)據(jù)有效性
整個數(shù)據(jù)有效性是在 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 將其優(yōu)先返回。否則以文件記錄值為準。這里 actualSize 通過讀取 m_file 頭部的固定長度 Fixed32Size 的數(shù)據(jù)。
constexpr uint32_t LittleEdian32Size = 4;
constexpr uint32_t pbFixed32Size() {
return LittleEdian32Size;
}
constexpr uint32_t Fixed32Size = pbFixed32Size();
其次，確認當前文件所剩余空間是否足夠使用。前面提過對于未存儲數(shù)據(jù)的部分默認是以 \0 填充的，因此這里需要將文件大小和真實數(shù)據(jù)大小進行比較。
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; /// 數(shù)據(jù)正確且剩余空間足夠
} else {
checkLastConfirmedInfo();
if (!loadFromFile) {
?? Handler 3: 數(shù)據(jù)異常
}
} else {
checkLastConfirmedInfo();
if (!loadFromFile) {
?? Handler 4: 空間不足
}
}
}
如果空間足夠，則計算出當前 m_file 真實數(shù)據(jù)的 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 內(nèi)容的加載。
checkLastConfirmedInfo
如果數(shù)據(jù)異常或者空間不足，都會調(diào)用 checkLastConfirmedInfo 重新確認 loadFromFile 狀態(tài)。checkLastConfirmedInfo 為 C++ 中的 lambda 函數(shù)，其聲明在 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 才有數(shù)據(jù)。故而 check 的前置條件為 >= MMKVVersionActualSize。
檢查中有兩次恢復正確 metaInfo 的機會：
Handler 1
oldStyleActualSize 記錄值為 m_file 的內(nèi)容數(shù)據(jù)大小，當其值不等于 m_metaInfo->m_actualSize 時，嘗試以 oldStyleActualSize 為準更新 metaInfo 的信息。更新仍然要進行 CRC 校驗，通過后將 loadFromFile 標記為 true，調(diào)用 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
前三個參數(shù)就不用說了，看最后參數(shù) increaseSequence，類型如下：
enum : bool {
KeepSequence = false,
IncreaseSequence = true,
};
它用于控制是否更新文件的 full write-back count 及 needsFullWrite。needsFullWrite 相當于 dirty bit 的作用，每當 m_version 有更新，都會將 needsFullWrite 標記為 dirty 用于之后的寫回更新。
write-back 概念后面會介紹。
checkDataValid
到這里，數(shù)據(jù)校驗的主流程算是介紹完了，我們回到 checkDataValid，補上 checkLastConfirmedInfo 后數(shù)據(jù)狀態(tài)依舊錯誤，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 為我們提供了修改的回調(diào)。策略有兩種：
enum MMKVRecoverStrategic : int {
OnErrorDiscard = 0,
OnErrorRecover,
};
默認 MMKV 會丟棄當前數(shù)據(jù)、清空文件和 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;
}
數(shù)據(jù)處理
校驗完有效性，依據(jù)其結(jié)果 loadFromFile 和 needFullWriteback 值來判定后續(xù)操作。簡化后的 loadFromFile：
void MMKV::loadFromFile() {
/// 1. 文件有效性
/// 2. 數(shù)據(jù)有效性
...
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);
}
}
};
先看異常處理。
當校驗失敗或文件為空，直接調(diào)用 writeActualSize 清理 metaInfo 緩存。
如果文件異常，傳入 IncreaseSequence 來設置 dirt bit，以待下次重載 m_file。
Loading
當 loadFromFile 為 true 且文件內(nèi)容不為空，將數(shù)據(jù)從內(nèi)存讀入 MMBuffer，進行 AES 解密、清空 m_dic、準備 buffer 數(shù)據(jù)寫入。
// 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();
}
數(shù)據(jù)寫入 m_dic 后，創(chuàng)建 CodedOutputData 對象來記錄當前映射的內(nèi)存指針和文件大小，通過 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);
}
區(qū)別在于 greed 會將所有 buffer 轉(zhuǎn)成 k-v 保存在 m_dic 中。
在前面的數(shù)據(jù)校驗中可知，僅當校驗失敗且恢復策略為 OnErrorRecover 會將 needFullWriteback 標記為 ture。就是說，當數(shù)據(jù)異常或空間不足時，會采用貪婪策略盡可能的將數(shù)據(jù)優(yōu)先讀入內(nèi)存。
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，簡單描述如下：
僅當一個緩存塊需要被替換回內(nèi)存時，才將其內(nèi)容寫入內(nèi)存。而為了減少內(nèi)存寫操作，通過臟位標識該塊在被載入之后是否發(fā)生過更新。如果一個緩存塊在被置換回內(nèi)存之前從未被寫入過，則可以免去回寫操作。
MMKV 的寫回操作就是將內(nèi)存數(shù)據(jù) 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;
}
操作前會檢查幾個狀態(tài)：
- m_hasFullWriteback：直接 return true
- m_needLoadFromFile：直接 return true
- isFileValid() 為 false：直接 return false
- m_dic.empty() ：
clearAll()后 return true
既然是數(shù)據(jù)讀取，如果 m_dic 為空，認為數(shù)據(jù)可能出現(xiàn)異常。將會清理臨時數(shù)據(jù)和內(nèi)存緩存、重置相關標記位、重新加載文件。
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 轉(zhuǎn)換為 MiniPBCoder 即 binary data，寫入前會確認當前文件 size 是否足夠滿足當前數(shù)據(jù)的寫入，否則進行擴容。
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 中被調(diào)用。盡管這里調(diào)用 writeActualSize 更新 m_metaInfo 并增加了 m_sequence，但是 actualSize 并沒有變化。
ensureMemorySize
除了完全寫回的情況，當 append 的數(shù)據(jù)超出 fileSize 也會進行擴容。擴容策略以 2 倍于原來的 fileSize，不斷擴充，直到比擴充的額外容量大為止。最后通過 truncate 裁剪至 DEFAULT_MMAP_SIZE 的整數(shù)倍。
核心邏輯如下：
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。其他數(shù)據(jù)類型也是一樣套路。
setDataForKey
更新 k-v 的核心方法，承接了全部數(shù)據(jù)更新的入口，做了三件事情：
- 數(shù)據(jù)校驗，確認是否需要刷新緩存，重新加載文件；
- 將 buffer 數(shù)據(jù)寫入文件；
- 更新 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
數(shù)據(jù)校驗，第一步是確認 m_needLoadFromFile 為 true，是則加鎖執(zhí)行 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 與當前內(nèi)存的 m_metaInfo 對比。metaInfo 中的數(shù)據(jù)更新都在 writeActualSize 中完成。而當文件讀取異常、空間不足或 crc 校驗失敗，這些情況發(fā)生時，會觸發(fā) meta_info 的變更。具體處理：
- m_sequence 代表了臟位數(shù)據(jù) dirt bit 存在，此時需要 重新加載 m_file。
- m_crcDigest 不同且 fileSize 不同，說明進行了擴容，也需要重新加載 m_file。
- m_crcDigest 不同且 fileSize 相同，說明進行了 full write-back，之后會通過
partialLoadFromFile完成相關內(nèi)存數(shù)據(jù)的更新。
appendData
官方說明
標準 protobuf 不提供增量更新的能力，每次寫入都必須全量寫入?？紤]到主要使用場景是頻繁地進行寫入更新，我們需要有增量更新的能力：將增量 kv 對象序列化后，直接 append 到內(nèi)存末尾；這樣同一個 key 會有新舊若干份數(shù)據(jù)，最新的數(shù)據(jù)在最后；那么只需在程序啟動第一次打開 mmkv 時，不斷用后讀入的 value 替換之前的值，就可以保證數(shù)據(jù)是最新有效的。
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 數(shù)據(jù)，更新 m_actualSize、crcDigest
return true;
}
追加邏輯比較簡單，就是將存儲 Key、Data 的 MMBuffer 經(jīng)過 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 僅支持了基本數(shù)據(jù)類型和 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 協(xié)議通過 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;
}
數(shù)據(jù)讀取就更簡單了，直接從 getDataForKey 中取出 MMBuffer，經(jīng)過 CodedOutputData 轉(zhuǎn)換得到 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;
}
這個也比較簡單就不展開了。
總結(jié)
寧可錯殺一千，也絕不放過一個。
這是整體讀完 MMKV 核心邏輯的第一感受。為什么呢？
MMKV 作為多進程讀寫的框架。細心的同學可以發(fā)現(xiàn)，在它的每一個方法的真正邏輯執(zhí)行前都進行了大量的異常校驗，同時對于臟數(shù)據(jù)的保護和容錯也比較繞。感覺你不把所有方法看過一遍，比較難 get 到其中的用意。相比這一點，CocoaLumberjack 的代碼就非常友好了，每個關鍵字段的作用，核心邏輯的解釋，以及背后的一些原理都有很詳細的注釋。
本文忽略了 MiniPB 的編解碼邏輯和讀寫鎖保護，以核心邏輯文件讀寫為主。MMKV 對于只要異常就是各種標記，然后重載。整個框架也是圍繞 loadFromFile 不斷的添加保護，文件鎖，crc 校驗，臟數(shù)據(jù)寫回。
如果你看到這里，應該能發(fā)現(xiàn)，本文是按照調(diào)用邏輯一層層深入，盡可能地讓各個方法的上下文是銜接有序。希望能幫助各位大致了解 MMKV 的核心邏輯。
