MMKV
MMKV——基于 mmap 的高性能通用 key-value 組件，底層序列化/反序列化使用 protobuf 實現(xiàn)，性能高，穩(wěn)定性強。
github
MMKV 是基于 mmap 內(nèi)存映射的移動端通用 key-value 組件，底層序列化/反序列化使用 protobuf 實現(xiàn)，性能高，穩(wěn)定性強。
從 2015 年中至今，在 iOS 微信上使用已有近 3 年，其性能和穩(wěn)定性經(jīng)過了時間的驗證。
近期已移植到 Android 平臺。在騰訊內(nèi)部開源半年之后，得到公司內(nèi)部團隊的廣泛應(yīng)用和一致好評。
通過 mmap 內(nèi)存映射文件，提供一段可供隨時寫入的內(nèi)存塊，App 只管往里面寫數(shù)據(jù)，
由操作系統(tǒng)負責將內(nèi)存回寫到文件，不必擔心 crash 導致數(shù)據(jù)丟失。
XML、JSON 更注重數(shù)據(jù)結(jié)構(gòu)化，關(guān)注人類可讀性和語義表達能力。
ProtoBuf 更注重數(shù)據(jù)序列化，關(guān)注效率、空間、速度，人類可讀性差，語義表達能力不足（為保證極致的效率，會舍棄一部分元信息）
特點
高性能 實時寫入
穩(wěn)定 防crash
多進程訪問
通過與 Android 開發(fā)同學的溝通，了解到系統(tǒng)自帶的 SharedPreferences 對多進程的支持不好。
現(xiàn)有基于 ContentProvider 封裝的實現(xiàn)，雖然多進程是支持了，但是性能低下，經(jīng)常導致 ANR。
考慮到 mmap 共享內(nèi)存本質(zhì)上的多進程共享的，我們在這個基礎(chǔ)上，深入挖掘了 Android 系統(tǒng)的能力，提供了可能是業(yè)界最高效的多進程數(shù)據(jù)共享組件。匿名內(nèi)存
在多進程共享的基礎(chǔ)上，考慮到某些敏感數(shù)據(jù)(例如密碼)需要進程間共享，但是不方便落地存儲到文件上，直接用 mmap 不合適。
我們了解到 Android 系統(tǒng)提供了 Ashmem 匿名共享內(nèi)存的能力，發(fā)現(xiàn)它在進程退出后就會消失，不會落地到文件上，非常適合這個場景。
我們很愉快地提供了 Ashmem MMKV 的功能。數(shù)據(jù)加密
不像 iOS 提供了硬件層級的加密機制，在 Android 環(huán)境里，數(shù)據(jù)加密是非常必須的。
MMKV 使用了 AES CFB-128 算法來加密/解密。我們選擇 CFB 而不是常見的 CBC 算法，
主要是因為 MMKV 使用 append-only 實現(xiàn)插入/更新操作，流式加密算法更加合適。數(shù)據(jù)有效性
MMKV 原理
-
內(nèi)存準備
通過 mmap 內(nèi)存映射文件，提供一段可供隨時寫入的內(nèi)存塊，App 只管往里面寫數(shù)據(jù)，由操作系統(tǒng)負責將內(nèi)存回寫到文件，不必擔心 crash 導致數(shù)據(jù)丟失。 -
數(shù)據(jù)組織
數(shù)據(jù)序列化方面我們選用 protobuf 協(xié)議，pb 在性能和空間占用上都有不錯的表現(xiàn)。 -
寫入優(yōu)化
考慮到主要使用場景是頻繁地進行寫入更新，我們需要有增量更新的能力。我們考慮將增量 kv 對象序列化后，append 到內(nèi)存末尾。
這樣同一個 key 會有新舊若干份數(shù)據(jù)，最新的數(shù)據(jù)在最后；那么只需在程序啟動第一次打開 mmkv 時，不斷用后讀入的 value 替換之前的值，就可以保證數(shù)據(jù)是最新有效的。 -
空間增長
使用 append 實現(xiàn)增量更新帶來了一個新的問題，就是不斷 append 的話，文件大小會增長得不可控。我們需要在性能和空間上做個折中。
以內(nèi)存 pagesize 為單位申請空間，在空間用盡之前都是 append 模式；當 append 到文件末尾時，進行文件重整、key 排重，嘗試序列化保存排重結(jié)果；
排重后空間還是不夠用的話，將文件擴大一倍，直到空間足夠。 -
數(shù)據(jù)有效性
考慮到文件系統(tǒng)、操作系統(tǒng)都有一定的不穩(wěn)定性，我們另外增加了 crc 校驗，對無效數(shù)據(jù)進行甄別。
更詳細的設(shè)計原理參考 MMKV 原理。
快速上手
dependencies {
implementation 'com.tencent:mmkv:1.0.23'
// replace "1.0.23" with any available version
}
MMKV的使用非常簡單，
所有變更立馬生效，無需調(diào)用 sync、apply。
在 App 啟動時初始化 MMKV，設(shè)定 MMKV 的根目錄
(默認/data/data/xxx.xxx/files/mmkv/)
(sp存儲在/data/data/xxx.xxx/shared_prefs/)
支持從SP遷移數(shù)據(jù)importFromSharedPreferences
MMKV 還額外實現(xiàn)了一遍 SharedPreferences、SharedPreferences.Editor 這兩個 interface
// 可以跟SP用法一樣
SharedPreferences.Editor editor = mmkv.edit();
// 無需調(diào)用 commit()
//editor.commit();
MMKV 的使用非常簡單，所有變更立馬生效，無需調(diào)用 sync、apply。 在 App 啟動時初始化 MMKV，設(shè)定 MMKV 的根目錄（files/mmkv/），例如在 MainActivity 里：
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
String rootDir = MMKV.initialize(this);
System.out.println("mmkv root: " + rootDir);
//……
}
MMKV 提供一個全局的實例，可以直接使用：
import com.tencent.mmkv.MMKV;
//……
MMKV kv = MMKV.defaultMMKV();
kv.encode("bool", true);
boolean bValue = kv.decodeBool("bool");
kv.encode("int", Integer.MIN_VALUE);
int iValue = kv.decodeInt("int");
kv.encode("string", "Hello from mmkv");
String str = kv.decodeString("string");
使用完畢的幾個方法
public native void clearAll();
// MMKV's size won't reduce after deleting key-values
// call this method after lots of deleting f you care about disk usage
// note that `clearAll` has the similar effect of `trim`
public native void trim();
// call this method if the instance is no longer needed in the near future
// any subsequent call to the instance is undefined behavior
public native void close();
// call on memory warning
// any subsequent call to the instance will load all key-values from file again
public native void clearMemoryCache();
// you don't need to call this, really, I mean it
// unless you care about out of battery
public void sync() {
sync(true);
}
性能對比
我們將 MMKV 和 SharedPreferences、SQLite 進行對比, 重復讀寫操作 1k 次。相關(guān)測試代碼在 Android/MMKV/mmkvdemo/。結(jié)果如下圖表。
單進程性能
可見，MMKV 在寫入性能上遠遠超越 SharedPreferences & SQLite，在讀取性能上也有相近或超越的表現(xiàn)。
多進程性能
可見，MMKV 無論是在寫入性能還是在讀取性能，都遠遠超越 MultiProcessSharedPreferences & SQLite & SQLite，
MMKV 在 Android 多進程 key-value 存儲組件上是不二之選。
補充適用建議
如果使用請務(wù)必做code19版本的適配，這個在github官網(wǎng)有說明
依賴下面這個庫，然后對19區(qū)分處理
implementation ‘com.getkeepsafe.relinker:relinker:1.3.1’
if (android.os.Build.VERSION.SDK_INT == 19) {
MMKV.initialize(relativePath, new MMKV.LibLoader() {
@Override
public void loadLibrary(String libName) {
ReLinker.loadLibrary(context, libName);
}
});
} else {
MMKV.initialize(context);
}
限制
可看到，一個鍵會存入多分實例，最后存入的就是最新的。
MMKV 在大部分情況下都性能強勁，key/value 的數(shù)量和長度都沒有限制。
然而 MMKV 在內(nèi)存里緩存了所有的 key-value，在總大小比較大的情況下（例如 100M+），App 可能會爆內(nèi)存，觸發(fā)重整回寫時，寫入速度也會變慢。
支持大文件的 MMKV 正在開發(fā)中，有望在下一個大版本發(fā)布。
問題
數(shù)據(jù)變化監(jiān)聽 怎么獲取？
// content change notification of other process
// trigger by getXXX() or setXXX() or checkContentChangedByOuterProcess()
多進程 issue
//CallStaticVoidMethod 錯誤寫成 CallStaticIntMethod，方法匹配crash
registerOnSharedPreferenceChangeListener not support
//官方推薦使用event方式通知更新
Data-change-listener is not supported by design.
We suggest using something like event-bus to notify any interesting clients.
Doing this inside a storage framework smells really bad.
defaultMMKV 是單進程SINGLE_PROCESS_MODE
使用MULTI_PROCESS_MODE創(chuàng)建多進程
帶來的APK尺寸增加問題
libc++_shared.so 252.5k
libmmkv.so 43.5k
implementation 'com.tencent:mmkv:1.0.23'
// implementation 'com.tencent:mmkv-static:1.0.23' (無libc++_shared.so)
只打包需要的平臺對應(yīng).so
ndk {
abiFilters "armeabi-v7a", 'x86'
}
.so加載問題
implementation 'com.getkeepsafe.relinker:relinker:1.3.1'
log太多
初始化可以設(shè)置log打印層級 initialize(rootDir, MMKVLogLevel.LevelInfo);
設(shè)置log轉(zhuǎn)發(fā)，控制log輸出格式、文件 MMKVHandler wantLogRedirecting=true
多進程
鎖 lock unlock tryLock
注意如果一個進程lock住，另一個進程mmkvWithID獲取MMKV時就阻塞住，直到持有進程釋放。
// get the lock immediately
MMKV mmkv2 = MMKV.mmkvWithID(LOCK_PHASE_2, MMKV.MULTI_PROCESS_MODE);
mmkv2.lock();
Log.d("locked in child", LOCK_PHASE_2);
Runnable waiter = new Runnable() {
@Override
public void run() {
//阻塞住 直到其他進程釋放
MMKV mmkv1 = MMKV.mmkvWithID(LOCK_PHASE_1, MMKV.MULTI_PROCESS_MODE);
mmkv1.lock();
Log.d("locked in child", LOCK_PHASE_1);
}
};
注意：如果其他進程有進行修改，不會立即觸發(fā)onContentChangedByOuterProcess，
checkLoadData如果變化，會clearMemoryState，重新loadFromFile。//數(shù)據(jù)量大時不要太頻繁
讀取decodeXXX會阻塞住，先回調(diào)onContentChangedByOuterProcess，再返回值，保證值是最新的。
mmkvWithAshmemID 匿名共享內(nèi)存
可以進行進程間通信，可設(shè)置pageSize
// a memory only MMKV, cleared on program exit
// size cannot change afterward (because ashmem won't allow it)
測試
write速度 mmkv > cryptKV >> sp
read速度 sp > cryptKV > mmkv
Binder MMAP（一次拷貝）
Linux的內(nèi)存分用戶空間跟內(nèi)核空間，同時頁表有也分兩類，用戶空間頁表跟內(nèi)核空間頁表，每個進程有一個用戶空間頁表，但是系統(tǒng)只有一個內(nèi)核空間頁表。
而Binder mmap的關(guān)鍵是：更新用戶空間對應(yīng)的頁表的同時也同步映射內(nèi)核頁表，讓兩個頁表都指向同一塊地址，
這樣一來，數(shù)據(jù)只需要從A進程的用戶空間，直接拷貝到B所對應(yīng)的內(nèi)核空間，而B多對應(yīng)的內(nèi)核空間在B進程的用戶空間也有相應(yīng)的映射，這樣就無需從內(nèi)核拷貝到用戶空間了。
copy_from_user() //將數(shù)據(jù)從用戶空間拷貝到內(nèi)核空間
copy_to_user() //將數(shù)據(jù)從內(nèi)核空間拷貝到用戶空間
Liunx進程隔離
傳統(tǒng)IPC
Binder通信
普通文件mmap原理
普通文件的訪問方式有兩種：
第一種是通過read/write系統(tǒng)調(diào)訪問，先在用戶空間分配一段buffer，然后，進入內(nèi)核，將內(nèi)容從磁盤讀取到內(nèi)核緩沖，最后，拷貝到用戶進程空間，至少牽扯到兩次數(shù)據(jù)拷貝；
同時，多個進程同時訪問一個文件，每個進程都有一個副本，存在資源浪費的問題。
另一種是通過mmap來訪問文件，mmap()將文件直接映射到用戶空間，文件在mmap的時候，內(nèi)存并未真正分配，
只有在第一次讀取/寫入的時候才會觸發(fā)，這個時候，會引發(fā)缺頁中斷，在處理缺頁中斷的時候，完成內(nèi)存也分配，同時也完成文件數(shù)據(jù)的拷貝。
并且，修改用戶空間對應(yīng)的頁表，完成到物理內(nèi)存到用戶空間的映射，這種方式只存在一次數(shù)據(jù)拷貝，效率更高。
同時多進程間通過mmap共享文件數(shù)據(jù)的時候，僅需要一塊物理內(nèi)存就夠了。
Android中使用mmap，可以通過RandomAccessFile與MappedByteBuffer來配合。
通過randomAccessFile.getChannel().map獲取到MappedByteBuffer。然后調(diào)用ByteBuffer的put方法添加數(shù)據(jù)。
RandomAccessFile randomAccessFile = new RandomAccessFile("path","rw");
MappedByteBuffer mappedByteBuffer= randomAccessFile.getChannel().map(FileChannel.MapMode.READ_WRITE,0, randomAccessFile.length());
mappedByteBuffer.putChar('c');
mappedByteBuffer.getChar();
共享內(nèi)存中mmap的使用
共享內(nèi)存是在普通文件mmap的基礎(chǔ)上實現(xiàn)的，其實就是基于tmpfs文件系統(tǒng)的普通mmap。
