MMKV_浅析 - MMKV 1.1.1
介紹
MMKV is an efficient, small, easy-to-use mobile key-value storage framework used in the WeChat application. It's currently available on Android, iOS/macOS, Win32 and POSIX.
作為一個精簡易用且性能強悍的全平臺 K-V 存儲框架，MMKV 有如下特點：
高效：
利用 mmap 直接將文件映射到內存；
利用 protobuf 對鍵值進行編解碼壓縮；
多進程并發；
易用：無需手動 synchronize 和配置，全程自動同步；
精簡.
少量的文件: 僅包括了編解碼工具類和 mmap 邏輯代碼，無冗余依賴；
二進制文件僅小于 30K: 如為 ipa 文件則會更小；
具體性能，微信團隊提供了簡單的 benchmark。總之就是秒殺蘋果的 NSUserDefaults，性能差異達 100 多倍。
說明，現在大家看到的這篇文章是重寫的 2.0 版本。就在前不久，MMKV 悄摸地發布了主版本更新 v1.1.0，而原有的實現已面目全非 💔，原因詳見：
We refactor the whole MMKV project and unify the cross-platform Core library. From now on, MMKV on iOS/macOS, Android, Win32 all share the same core logic code.
另，本篇涉及大量 C++ 實現，如果描述有誤望及時指出。
準備工作
在開始之前，我們需要了解幾個概念，熟悉的同學可 pass。
mmap
mmap是一種內存映射文件的方法，即將一個文件或者其它對象映射到進程的地址空間，實現文件磁盤地址和進程虛擬地址空間中一段虛擬地址的一一對映關系。實現這樣的映射關系后，進程就可以采用指針的方式讀寫操作這一段內存，而系統會自動回寫臟頁面到對應的文件磁盤上，即完成了對文件的操作而不必再調用read,write等系統調用函數。相反，內核空間對這段區域的修改也直接反映用戶空間，從而可以實現不同進程間的文件共享。
通常，我們的文件讀寫操作需要頁緩存作為內核和應用層的中轉。因此，一次文件操作需要兩次數據拷貝(內核到頁緩存，頁緩存到應用層)，而 mmap 實現了用戶空間和內核空間數據的直接交互而省去了頁緩存。當然有利也有弊，如 蘋果文檔 所述，想高效使用 mmap 需要符合以下場景：
You have a large file whose contents you want to access randomly one or more times.
You have a small file whose contents you want to read into memory all at once and access frequently. This technique is best for files that are no more than a few virtual memory pages in size.
You want to cache specific portions of a file in memory. File mapping eliminates the need to cache the data at all, which leaves more room in the system disk caches for other data.
因此，當我們需要高頻率的訪問某一較大文件中的一小部分內容的時候，mmap 的效率是最高的。
其實不光是 MMKV 包括微信的 XLog 和 美團的 Logan 日志工具，還有 SQLight 都使用 mmap 來提升高頻更新場景下的文件訪問效率。
Protocol Buffer
Protobuf is a method of serializing structured data. It is useful in developing programs to communicate with each other over a wire or for storing data. The method involves an interface description language that describes the structure of some data and a program that generates source code from that description for generating or parsing a stream of bytes that represents the structured data.
Protobuf 是一種將結構化數據進行序列化的方法。它最初是為了解決服務器端新舊協議(高低版本)兼容性問題而誕生的。因此，稱為“協議緩沖區”，只不過后期慢慢發展成用于傳輸數據和存儲等。
MMKV 正是考慮到了 protobuf 在性能和空間上的不錯表現，以簡化版 protobuf 作為序列化方案，還擴展了 protobuf 的增量更新的能力，將 K-V 對象序列化后，直接 append 到內存末尾進行序列化。
那 Protobuf 是如何實現高效編碼？
以 Tag - Value (Tag - Length - Value)的編碼方式的實現。減少了分隔符的使用，數據存儲更加緊湊；
利用 base 128 varint (變長編碼)原理壓縮數據以后，二進制數據非常緊湊，pb 體積更小。不過 pb 并沒有壓縮到極限，float、double 浮點型都沒有壓縮；
相比 JSON 和 XML 少了 {、}、: 這些符號，體積也減少一些。再加上 varint、gzip 壓縮以后體積更小。
CRC 校驗
循環冗余校驗(Cyclic redundancy check)是一種根據網絡數據包或計算機文件等數據產生簡短固定位數校驗碼的一種散列函數，主要用來檢測或校驗數據傳輸或者保存后可能出現的錯誤。生成的數字在傳輸或者存儲之前計算出來并且附加到數據后面，然后接收方進行檢驗確定數據是否發生變化。
同樣是用于計算校驗值，相比 MD5 或者 SHA1，CRC 的計算效率較高，安全性較弱。考慮到文件系統、操作系統都有一定的不穩定性，MMKV 增加了 CRC 校驗，對無效數據進行甄別。
在 iOS 微信現網環境上，有平均約 70萬日次的數據校驗不通過。
初始化
在 v1.1.0 版本 Tencent 團隊重寫了整個 MMVK 項目，統一跨平臺核心庫。自此 MMKV 在 iOS/macOS, Android, Win32 共享同一份核心邏輯。在一定程度上提高了可維護性，以及優勢共享。也正是由于這一點，在 iOS/macOS 上可以實現 Multi-Process Access。
在代碼結構上，MMKV 獨立出單獨的 MMVKCore，Apple 平臺基于 MMKV Core 做了一層 Objc 的封裝。
原有的實現基本都遷移到 MMKV Core 中并替換成了 C++ 實現。對不同平臺的所獨有的 API 或邏輯通過不同的文件名和宏來隔離。以 MemoryFile 為例：
MemoryFile.h
MemoryFile.cpp
MemoryFile_Android.cpp
MemoryFile_OSX.cpp
MemoryFile_Win32.cpp
復制代碼
本篇我們重點關注 Apple 相關邏輯。
Class Initialize
MMKV 在使用前的準備工作分成兩個階段：
初始化 g_instanceDic 等靜態變量。它在應用啟動時的 pre_main 函數前，在 MMKV class 的 + initialize 里完成的。
需要用戶手動執行 +initializeMMKV 來完成 g_basePath 的指定，即 MMKV 的根目錄。
+ (void)initialize {
if (self == MMKV.class) {
g_instanceDic = [[NSMutableDictionary alloc] init];
g_lock = new mmkv::ThreadLock();
g_lock->initialize();
mmkv::MMKV::minimalInit([self mmkvBasePath].UTF8String);
/* 注冊啟動通知 */
}
}
復制代碼
在類的初始化中，做了四件事情：
g_instanceDic ：全局 MMKV 實例的容器，key 由多個字段混合生成的，后面會說明；
g_lock : 為 g_instanceDic 配了把線程鎖；
minimalInit：以 MMKV 默認的根目錄 (～/Document/mmkv) ，初始化 MMKV Core 中的全局變量；
注冊 App 生命周期相關的通知 (僅 iOS 應用主體)
這里之前有不明白之處，就是為什么這里沒有使用 dispatch_once 來保證不可重入呢？
當翻看該文件的 history 時，發現早期版本確實用到了 dispatch_once 來避免重入。而現在換成這種寫法難道是
用了什么新特性嗎？
我們知道 +initialize 是有可能被多次調用的，但是對其如何被多次調用，被誰多次調用，這里理解有誤。
以 MMKV 為例，假設我們聲明 MMKVTest 作為其 MMKV 的子類，但未實現 +initialize 或者 MMKVTest 在其 +initialize 中顯式的調用 [super initialize] 方法，那么 MMKV 的 +initialize 才會被調用多次。
但是忽略了很重要的一點，+initialize 是 class method，完全可以通過判斷 class 類型來避免重入。這也是第一行判斷 self == MMKV.class 的重要性和作用。
MinimalInit
protect from some old code that don't call initializeMMKV()
為了確保相關屬性訪問時已初始化完成，在類初始化時需要提前備好全局變量。
void MMKV::minimalInit(MMKVPath_t defaultRootDir) {
ThreadLock::ThreadOnce(&once_control, initialize);
int device = 0, version = 0;
GetAppleMachineInfo(device, version);
# ifdef __aarch64__
if ((device == iPhone && version >= 9) || (device == iPad && version >= 7)) {
CRC32 = mmkv::armv8_crc32;
}
# endif
g_rootDir = defaultRootDir;
mkPath(g_rootDir);
}
復制代碼
該方法以最低限度把必須要完成的事情放到了應用的啟動前，主要三件事：
執行 initialize 完成全局變量的 init。
確定 CRC 校驗的算法；
生成 mmkv 根目錄；
Initialize
ThreadLock::ThreadOnce 背后以 pthread_once 來保證單詞調用，以完成 initialize()，最后用 g_rootDir 創建對應的文件目錄。來看私有的 initialize 方法做了啥：
void initialize() {
g_instanceDic = new unordered_map;
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(::crc32(crc, buf, static_cast(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;
#else
using MMKVMap = std::unordered_map<: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(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 加載主要分三步：
校驗 CRC 文件、m_file 的有效性，初始化 AESCrypter；
檢查文件內部數據的有效性；
加載數據到內存。
文件有效性
在 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(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(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(1, m_dic.size());
size_t futureUsage = avgItemSize * std::max(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
bool set(T value, MMKVKey_t key) = delete;
bool set(NSObject *__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 的核心方法，承接了全部數據更新的入口，做了三件事情：
數據校驗，確認是否需要刷新緩存，重新加載文件；
將 buffer 數據寫入文件；
更新 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 的變更。具體處理：
m_sequence 代表了臟位數據 dirt bit 存在，此時需要 重新加載 m_file。
m_crcDigest 不同且 fileSize 不同，說明進行了擴容，也需要重新加載 m_file。
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 *__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<: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 的核心邏輯。
關于找一找教程網
本站文章僅代表作者觀點，不代表本站立場，所有文章非營利性免費分享。
本站提供了軟件編程、網站開發技術、服務器運維、人工智能等等IT技術文章，希望廣大程序員努力學習，讓我們用科技改變世界。
[淺析 - MMKV 1.1.1]http://www.zyiz.net/tech/detail-136521.html
總結
以上是生活随笔為你收集整理的MMKV_浅析 - MMKV 1.1.1的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 伍德里奇计量经济学第五版第四章计算机操作
- 下一篇： 我们应该搞清楚分支预测