MMKV

MMKV——基于 mmap 的高性能通用 key-value 組件散罕，底層序列化/反序列化使用 protobuf 實(shí)現(xiàn)分歇，性能高，穩(wěn)定性強(qiáng)欧漱。
github

MMKV 是基于 mmap 內(nèi)存映射的移動(dòng)端通用 key-value 組件职抡，底層序列化/反序列化使用 protobuf 實(shí)現(xiàn)，性能高误甚，穩(wěn)定性強(qiáng)缚甩。
從 2015 年中至今，在 iOS 微信上使用已有近 3 年窑邦，其性能和穩(wěn)定性經(jīng)過了時(shí)間的驗(yàn)證擅威。
近期已移植到 Android 平臺(tái)。在騰訊內(nèi)部開源半年之后冈钦，得到公司內(nèi)部團(tuán)隊(duì)的廣泛應(yīng)用和一致好評(píng)郊丛。

通過 mmap 內(nèi)存映射文件，提供一段可供隨時(shí)寫入的內(nèi)存塊瞧筛，App 只管往里面寫數(shù)據(jù)厉熟，
由操作系統(tǒng)負(fù)責(zé)將內(nèi)存回寫到文件，不必?fù)?dān)心 crash 導(dǎo)致數(shù)據(jù)丟失较幌。

XML揍瑟、JSON 更注重?cái)?shù)據(jù)結(jié)構(gòu)化，關(guān)注人類可讀性和語義表達(dá)能力乍炉。
ProtoBuf 更注重?cái)?shù)據(jù)序列化月培，關(guān)注效率嘁字、空間、速度杉畜，人類可讀性差，語義表達(dá)能力不足（為保證極致的效率衷恭，會(huì)舍棄一部分元信息）

特點(diǎn)

• 高性能 實(shí)時(shí)寫入

• 穩(wěn)定 防crash

• 多進(jìn)程訪問
  通過與 Android 開發(fā)同學(xué)的溝通此叠，了解到系統(tǒng)自帶的 SharedPreferences 對(duì)多進(jìn)程的支持不好。
  現(xiàn)有基于 ContentProvider 封裝的實(shí)現(xiàn)随珠，雖然多進(jìn)程是支持了灭袁，但是性能低下，經(jīng)常導(dǎo)致 ANR窗看。
  考慮到 mmap 共享內(nèi)存本質(zhì)上的多進(jìn)程共享的茸歧，我們?cè)谶@個(gè)基礎(chǔ)上，深入挖掘了 Android 系統(tǒng)的能力显沈，提供了可能是業(yè)界最高效的多進(jìn)程數(shù)據(jù)共享組件软瞎。

• 匿名內(nèi)存
  在多進(jìn)程共享的基礎(chǔ)上，考慮到某些敏感數(shù)據(jù)(例如密碼)需要進(jìn)程間共享拉讯，但是不方便落地存儲(chǔ)到文件上涤浇，直接用 mmap 不合適。
  我們了解到 Android 系統(tǒng)提供了 Ashmem 匿名共享內(nèi)存的能力魔慷，發(fā)現(xiàn)它在進(jìn)程退出后就會(huì)消失只锭，不會(huì)落地到文件上，非常適合這個(gè)場(chǎng)景院尔。
  我們很愉快地提供了 Ashmem MMKV 的功能蜻展。

• 數(shù)據(jù)加密
  不像 iOS 提供了硬件層級(jí)的加密機(jī)制，在 Android 環(huán)境里邀摆，數(shù)據(jù)加密是非常必須的纵顾。
  MMKV 使用了 AES CFB-128 算法來加密/解密。我們選擇 CFB 而不是常見的 CBC 算法隧熙，
  主要是因?yàn)?MMKV 使用 append-only 實(shí)現(xiàn)插入/更新操作片挂，流式加密算法更加合適。

• 數(shù)據(jù)有效性

MMKV 原理

• 內(nèi)存準(zhǔn)備
  通過 mmap 內(nèi)存映射文件贞盯，提供一段可供隨時(shí)寫入的內(nèi)存塊音念，App 只管往里面寫數(shù)據(jù)，由操作系統(tǒng)負(fù)責(zé)將內(nèi)存回寫到文件躏敢，不必?fù)?dān)心 crash 導(dǎo)致數(shù)據(jù)丟失闷愤。
• 數(shù)據(jù)組織
  數(shù)據(jù)序列化方面我們選用 protobuf 協(xié)議，pb 在性能和空間占用上都有不錯(cuò)的表現(xiàn)件余。
• 寫入優(yōu)化
  考慮到主要使用場(chǎng)景是頻繁地進(jìn)行寫入更新讥脐，我們需要有增量更新的能力遭居。我們考慮將增量 kv 對(duì)象序列化后，append 到內(nèi)存末尾旬渠。
  這樣同一個(gè) key 會(huì)有新舊若干份數(shù)據(jù)俱萍，最新的數(shù)據(jù)在最后；那么只需在程序啟動(dòng)第一次打開 mmkv 時(shí)告丢，不斷用后讀入的 value 替換之前的值枪蘑，就可以保證數(shù)據(jù)是最新有效的。
• 空間增長(zhǎng)
  使用 append 實(shí)現(xiàn)增量更新帶來了一個(gè)新的問題岖免，就是不斷 append 的話岳颇，文件大小會(huì)增長(zhǎng)得不可控。我們需要在性能和空間上做個(gè)折中颅湘。
  以內(nèi)存 pagesize 為單位申請(qǐng)空間话侧，在空間用盡之前都是 append 模式；當(dāng) append 到文件末尾時(shí)闯参，進(jìn)行文件重整瞻鹏、key 排重，嘗試序列化保存排重結(jié)果赢赊；
  排重后空間還是不夠用的話乙漓，將文件擴(kuò)大一倍，直到空間足夠释移。
• 數(shù)據(jù)有效性
  考慮到文件系統(tǒng)叭披、操作系統(tǒng)都有一定的不穩(wěn)定性，我們另外增加了 crc 校驗(yàn)玩讳，對(duì)無效數(shù)據(jù)進(jìn)行甄別涩蜘。

更詳細(xì)的設(shè)計(jì)原理參考 MMKV 原理。

快速上手

dependencies {
    implementation 'com.tencent:mmkv:1.0.23'
    // replace "1.0.23" with any available version
}

MMKV的使用非常簡(jiǎn)單熏纯，
所有變更立馬生效同诫，無需調(diào)用 sync、apply樟澜。
在 App 啟動(dòng)時(shí)初始化 MMKV误窖，設(shè)定 MMKV 的根目錄
(默認(rèn)/data/data/xxx.xxx/files/mmkv/)
(sp存儲(chǔ)在/data/data/xxx.xxx/shared_prefs/)

支持從SP遷移數(shù)據(jù)importFromSharedPreferences

MMKV 還額外實(shí)現(xiàn)了一遍 SharedPreferences、SharedPreferences.Editor 這兩個(gè) interface

// 可以跟SP用法一樣
SharedPreferences.Editor editor = mmkv.edit();
// 無需調(diào)用 commit()
//editor.commit();

MMKV 的使用非常簡(jiǎn)單秩贰，所有變更立馬生效霹俺，無需調(diào)用 sync、apply毒费。 在 App 啟動(dòng)時(shí)初始化 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 提供一個(gè)全局的實(shí)例觅玻，可以直接使用：

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");

使用完畢的幾個(gè)方法

    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);
    }

性能對(duì)比

我們將 MMKV 和 SharedPreferences想际、SQLite 進(jìn)行對(duì)比, 重復(fù)讀寫操作 1k 次培漏。相關(guān)測(cè)試代碼在 Android/MMKV/mmkvdemo/。結(jié)果如下圖表胡本。

單進(jìn)程性能

可見牌柄，MMKV 在寫入性能上遠(yuǎn)遠(yuǎn)超越 SharedPreferences & SQLite，在讀取性能上也有相近或超越的表現(xiàn)侧甫。

多進(jìn)程性能

可見友鼻，MMKV 無論是在寫入性能還是在讀取性能，都遠(yuǎn)遠(yuǎn)超越 MultiProcessSharedPreferences & SQLite & SQLite闺骚，
MMKV 在 Android 多進(jìn)程 key-value 存儲(chǔ)組件上是不二之選。

補(bǔ)充適用建議

如果使用請(qǐng)務(wù)必做code19版本的適配妆档，這個(gè)在github官網(wǎng)有說明

依賴下面這個(gè)庫(kù)僻爽，然后對(duì)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);
}

限制

可看到，一個(gè)鍵會(huì)存入多分實(shí)例贾惦，最后存入的就是最新的胸梆。
MMKV 在大部分情況下都性能強(qiáng)勁，key/value 的數(shù)量和長(zhǎng)度都沒有限制须板。
然而 MMKV 在內(nèi)存里緩存了所有的 key-value碰镜，在總大小比較大的情況下（例如 100M+），App 可能會(huì)爆內(nèi)存习瑰，觸發(fā)重整回寫時(shí)绪颖，寫入速度也會(huì)變慢。
支持大文件的 MMKV 正在開發(fā)中甜奄，有望在下一個(gè)大版本發(fā)布柠横。

問題

數(shù)據(jù)變化監(jiān)聽 怎么獲取课兄？

// content change notification of other process
// trigger by getXXX() or setXXX() or checkContentChangedByOuterProcess()

多進(jìn)程 issue
//CallStaticVoidMethod 錯(cuò)誤寫成 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 是單進(jìn)程SINGLE_PROCESS_MODE
使用MULTI_PROCESS_MODE創(chuàng)建多進(jìn)程

帶來的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)

只打包需要的平臺(tái)對(duì)應(yīng).so

    ndk {
            abiFilters "armeabi-v7a", 'x86'
        }

.so加載問題

implementation 'com.getkeepsafe.relinker:relinker:1.3.1'

log太多

初始化可以設(shè)置log打印層級(jí) initialize(rootDir, MMKVLogLevel.LevelInfo);
設(shè)置log轉(zhuǎn)發(fā)，控制log輸出格式烟阐、文件 MMKVHandler wantLogRedirecting=true

多進(jìn)程

鎖 lock unlock tryLock

注意如果一個(gè)進(jìn)程lock住搬俊，另一個(gè)進(jìn)程mmkvWithID獲取MMKV時(shí)就阻塞住，直到持有進(jìn)程釋放蜒茄。

        // 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() {
                //阻塞住 直到其他進(jìn)程釋放
                MMKV mmkv1 = MMKV.mmkvWithID(LOCK_PHASE_1, MMKV.MULTI_PROCESS_MODE);
                mmkv1.lock();
                Log.d("locked in child", LOCK_PHASE_1);
            }
        };

注意：如果其他進(jìn)程有進(jìn)行修改唉擂，不會(huì)立即觸發(fā)onContentChangedByOuterProcess，
checkLoadData如果變化扩淀，會(huì)clearMemoryState楔敌，重新loadFromFile。//數(shù)據(jù)量大時(shí)不要太頻繁
讀取decodeXXX會(huì)阻塞住驻谆，先回調(diào)onContentChangedByOuterProcess卵凑，再返回值庆聘，保證值是最新的。

mmkvWithAshmemID 匿名共享內(nèi)存

可以進(jìn)行進(jìn)程間通信勺卢，可設(shè)置pageSize
// a memory only MMKV, cleared on program exit
// size cannot change afterward (because ashmem won't allow it)

測(cè)試

write速度 mmkv > cryptKV >> sp
read速度 sp > cryptKV > mmkv

Binder MMAP（一次拷貝）

Linux的內(nèi)存分用戶空間跟內(nèi)核空間伙判，同時(shí)頁表有也分兩類，用戶空間頁表跟內(nèi)核空間頁表黑忱，每個(gè)進(jìn)程有一個(gè)用戶空間頁表宴抚，但是系統(tǒng)只有一個(gè)內(nèi)核空間頁表。
而Binder mmap的關(guān)鍵是：更新用戶空間對(duì)應(yīng)的頁表的同時(shí)也同步映射內(nèi)核頁表甫煞，讓兩個(gè)頁表都指向同一塊地址菇曲，
這樣一來，數(shù)據(jù)只需要從A進(jìn)程的用戶空間抚吠，直接拷貝到B所對(duì)應(yīng)的內(nèi)核空間常潮，而B多對(duì)應(yīng)的內(nèi)核空間在B進(jìn)程的用戶空間也有相應(yīng)的映射，這樣就無需從內(nèi)核拷貝到用戶空間了楷力。

copy_from_user() //將數(shù)據(jù)從用戶空間拷貝到內(nèi)核空間
copy_to_user() //將數(shù)據(jù)從內(nèi)核空間拷貝到用戶空間

Liunx進(jìn)程隔離

傳統(tǒng)IPC

image

Binder通信

image

普通文件mmap原理

普通文件的訪問方式有兩種：

第一種是通過read/write系統(tǒng)調(diào)訪問喊式，先在用戶空間分配一段buffer，然后萧朝，進(jìn)入內(nèi)核岔留，將內(nèi)容從磁盤讀取到內(nèi)核緩沖，最后检柬，拷貝到用戶進(jìn)程空間献联，至少牽扯到兩次數(shù)據(jù)拷貝；
同時(shí)厕吉，多個(gè)進(jìn)程同時(shí)訪問一個(gè)文件酱固，每個(gè)進(jìn)程都有一個(gè)副本，存在資源浪費(fèi)的問題头朱。

另一種是通過mmap來訪問文件盲再，mmap()將文件直接映射到用戶空間绸栅，文件在mmap的時(shí)候璃氢，內(nèi)存并未真正分配丈秩，
只有在第一次讀取/寫入的時(shí)候才會(huì)觸發(fā)，這個(gè)時(shí)候烁巫，會(huì)引發(fā)缺頁中斷署隘，在處理缺頁中斷的時(shí)候，完成內(nèi)存也分配亚隙，同時(shí)也完成文件數(shù)據(jù)的拷貝磁餐。
并且，修改用戶空間對(duì)應(yīng)的頁表，完成到物理內(nèi)存到用戶空間的映射诊霹，這種方式只存在一次數(shù)據(jù)拷貝羞延，效率更高。
同時(shí)多進(jìn)程間通過mmap共享文件數(shù)據(jù)的時(shí)候脾还，僅需要一塊物理內(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ǔ)上實(shí)現(xiàn)的怔蚌，其實(shí)就是基于tmpfs文件系統(tǒng)的普通mmap巩步。