当前位置：网站首页>腾讯持久化框架MMKV原理探究

腾讯持久化框架MMKV原理探究

2022-06-30 16:41:00 【失落夏天】

前言：

MMKV是腾讯18年底推出的一套持久化框架，有安卓，IOS，PC版本等等，微信的持久化功能使用的就是MMKV，项目地址：https://github.com/Tencent/MMKV

最大的特点就是高效，号称要比传统的持久化工具要高效100倍，目标是用来替代原生的SharedPreferences（后续SharedPreferences统称为SP）。本文主要是探究MMKV的实现原理以及为什么比SP高效。

本文主要基于安卓的项目进行分析和实验。

一.MMKV实测

1.1导入MMKV和简单实用方式

上面既然说MMKV高效，那我们就实际做一个例子验证一下。

MMKV的使用方式十分简单，首先build.gradle种导入MMKV的包，然后代码中初始化一下即可。

 implementation 'com.tencent:mmkv:1.2.13'

val initialize = MMKV.initialize(context)

使用方式和SP几乎一样，如下：

val kv = MMKV.defaultMMKV()
//写入key=i1,value=1的值
kv.encode("i1", 1)
//读区key=i1的值，返回结果是1
val decodeInt = kv.decodeInt("i1")

1.2和SP做对比

为了数据上显示更明显，所以我们分别存储字符串，数字，Boolean，1000次，然后看花费时间对比。

代码如下：

override fun clickItem(position: Int) {
        val random = Random(1000)
        if (position == 0 || position == 2 || position == 4) {
            val sp = when (position) {
                0 -> {
                    requireContext().getSharedPreferences("sp_int", MODE_PRIVATE);
                }
                2 -> {
                    requireContext().getSharedPreferences("sp_boolean", MODE_PRIVATE);
                }
                else -> {
                    requireContext().getSharedPreferences("sp_string", MODE_PRIVATE);
                }
            }
            val edit = sp.edit()
            val currentTimeMillis = System.currentTimeMillis()
            for (i in 0 until 1000) {
                when (position) {
                    0 -> {
                        edit.putInt("key$i", random.nextInt())
                    }
                    1 -> {
                        edit.putBoolean("key$i", true)
                    }
                    else -> {
                        edit.putString("key$i", "key$i")
                    }
                }
                edit.commit()
            }
            Log.i(TAG, "SP spendTime:${System.currentTimeMillis() - currentTimeMillis}")
            return
        }
        if (position == 1 || position == 3 || position == 5) {
            val kv = when (position) {
                1 -> {
                    MMKV.defaultMMKV(0, "sp_int")
                }
                3 -> {
                    MMKV.defaultMMKV(0, "sp_boolean")
                }
                else -> {
                    MMKV.defaultMMKV(0, "sp_string")
                }
            }
            val currentTimeMillis = System.currentTimeMillis()
            for (i in 0 until 1000) {
                if (position == 1) {
                    kv.putInt("key$i", random.nextInt())
                } else if (position == 3) {
                    kv.putBoolean("key$i", true)
                } else {
                    kv.putString("key$i", "key$i")
                }

            }
            Log.i(TAG, "MMKV spendTime:${System.currentTimeMillis() - currentTimeMillis}")
        }
    }

验证下来，1000次操作，最终的结果如下：

//第一次写入随机Int
2022-06-29 16:50:54.211 30092-30092/com.xt.client I/MMKVFragment: SP spendTime:14289
2022-06-29 16:50:56.399 30092-30092/com.xt.client I/MMKVFragment: MMKV spendTime:24

//第二次写入随机Int
2022-06-29 16:50:54.211 30092-30092/com.xt.client I/MMKVFragment: SP spendTime:14189
2022-06-29 16:50:56.399 30092-30092/com.xt.client I/MMKVFragment: MMKV spendTime:25

//第一次写入Boolean
2022-06-29 16:51:10.612 30092-30092/com.xt.client I/MMKVFragment: SP spendTime:12485
2022-06-29 16:51:12.810 30092-30092/com.xt.client I/MMKVFragment: MMKV spendTime:30

//第二次写入Boolean
2022-06-29 16:51:14.567 30092-30092/com.xt.client I/MMKVFragment: SP spendTime:36
2022-06-29 16:51:16.192 30092-30092/com.xt.client I/MMKVFragment: MMKV spendTime:9

//第一次写入String
2022-06-29 16:51:33.950 30092-30092/com.xt.client I/MMKVFragment: SP spendTime:12718
2022-06-29 16:51:38.381 30092-30092/com.xt.client I/MMKVFragment: MMKV spendTime:12

通过结果，我们可以发现这样两个现象：

1.首次写入时，MMKV的效率是极其高的，在20多毫秒，而SP则需要14000毫秒。

2.第二次写入时，如果数据没有发生变化，则SP的效率也是比较高的。在100毫秒以内，无论Int，Boolean还是String。而MMKV一如既往的高效，仍然是20多毫秒。（原因在第二章会分析）

总结一下，就是如果数据发生改变的情况下，MMKV的效率是大幅好于SP的（甚至达到了上百倍的级别），如果数据没有发生改变，因为SP有缓存机制的存在，所以影响则不大。

二.SharedPreferences有哪些问题

都说MMKV是用来替代安卓原生的SharedPreferences的，那么我们自然要探究一下，原生的SP有什么缺陷？

2.1 SP实现原理-写

首先简单了解一下SP的原理。SP的实现类是SharedPreferencesImpl，Editor的实现类是SharedPreferencesImpl.EditorImpl。

我们putString时，最终调用到EditorImpl.putString()，逻辑很简单，就是把key，value存储到Map中。

 @Override
        public Editor putString(String key, @Nullable String value) {
            synchronized (mEditorLock) {
                mModified.put(key, value);
                return this;
            }
        }

我们在看一下最终提交编辑时，commit方法（apply类似），核心都是commitToMemory方法，只不过commit多了一个CountDownLatch的锁。

 private MemoryCommitResult commitToMemory() {
            long memoryStateGeneration;
            boolean keysCleared = false;
            List<String> keysModified = null;
            Set<OnSharedPreferenceChangeListener> listeners = null;
            Map<String, Object> mapToWriteToDisk;
            //1.加锁操作，避免多线程
            synchronized (SharedPreferencesImpl.this.mLock) {
                // We optimistically don't make a deep copy until
                // a memory commit comes in when we're already
                // writing to disk.
                if (mDiskWritesInFlight > 0) {
                    // We can't modify our mMap as a currently
                    // in-flight write owns it.  Clone it before
                    // modifying it.
                    // noinspection unchecked
                    //2.拷贝一个新的Map，存放原来所有的Map数据。
                    mMap = new HashMap<String, Object>(mMap);
                }
                mapToWriteToDisk = mMap;
                mDiskWritesInFlight++;

                boolean hasListeners = mListeners.size() > 0;
                if (hasListeners) {
                    keysModified = new ArrayList<String>();
                    listeners = new HashSet<OnSharedPreferenceChangeListener>(mListeners.keySet());
                }

                synchronized (mEditorLock) {
                    boolean changesMade = false;

                    if (mClear) {
                        if (!mapToWriteToDisk.isEmpty()) {
                            changesMade = true;
                            mapToWriteToDisk.clear();
                        }
                        keysCleared = true;
                        mClear = false;
                    }
                    //3.遍历这次修改的内容Map，对比老的全量Map，进行合成。如果值不变则跳过，如果变化了则存到全量的Map中。
                    for (Map.Entry<String, Object> e : mModified.entrySet()) {
                        String k = e.getKey();
                        Object v = e.getValue();
                        // "this" is the magic value for a removal mutation. In addition,
                        // setting a value to "null" for a given key is specified to be
                        // equivalent to calling remove on that key.
                        if (v == this || v == null) {
                            if (!mapToWriteToDisk.containsKey(k)) {
                                continue;
                            }
                            mapToWriteToDisk.remove(k);
                        } else {
                            if (mapToWriteToDisk.containsKey(k)) {
                                Object existingValue = mapToWriteToDisk.get(k);
                                if (existingValue != null && existingValue.equals(v)) {
                                    continue;
                                }
                            }
                            mapToWriteToDisk.put(k, v);
                        }

                        changesMade = true;
                        if (hasListeners) {
                            keysModified.add(k);
                        }
                    }

                    mModified.clear();
                    //4.如果changesMade=false，则说明数据没有变化。
                    if (changesMade) {
                        mCurrentMemoryStateGeneration++;
                    }

                    memoryStateGeneration = mCurrentMemoryStateGeneration;
                }
            }
//5.最终生成MemoryCommitResult对象返回，最终写入的其实就是MemoryCommitResult对象。它是对map的封装类
            return new MemoryCommitResult(memoryStateGeneration, keysCleared, keysModified,
                    listeners, mapToWriteToDisk);
        }

主要包含以下几步：

1.加锁操作，避免多线程

2.拷贝一个新的Map，存放原来所有的Map数据。

3.遍历这次修改的内容mModified，对比老的全量mapToWriteToDisk，进行合成。如果值不变则跳过，如果变化了则存到全量的Map中。

4.如果修改了值，则记录changesMade=true。此时mCurrentMemoryStateGeneration+1；

5.最终生成MemoryCommitResult对象返回，最终写入的其实就是MemoryCommitResult对象。它是对map的封装类

最终写入的方法是writeToFile，代码就不贴了，简单来说，就是说没有修改并且原来文件存在的话，则直接回调无需写入操作（这也对应了第一章的实验结果2，为什么无修改时效率也不低）。否则，则写入到XML文件当中。

最终的文件保存在data/data/包名/shared_prefs/文件夹下：

内容格式如下：

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
    <int name="key1251" value="-832759317" />
    <int name="key1252" value="1723359929" />
    <int name="key1253" value="469068865" />
    <int name="key1254" value="-836324061" />
    <int name="key1250" value="129252392" />
</map>

2.2 SP实现原理-读

初始化SharedPreferencesImpl的时候，就会去指定文件里面读了，通过startLoadFromDisk方法。

 SharedPreferencesImpl(File file, int mode) {
        mFile = file;
        mBackupFile = makeBackupFile(file);
        mMode = mode;
        mLoaded = false;
        mMap = null;
        mThrowable = null;
        startLoadFromDisk();
    }

新起一个线程去读取文件内容，然后把读取到的内容放到Map上。

private void startLoadFromDisk() {
        synchronized (mLock) {
            mLoaded = false;
        }
        new Thread("SharedPreferencesImpl-load") {
            public void run() {
                loadFromDisk();
            }
        }.start();
    }

然后我们在看getString方法，其余的类似。

 @Override
    @Nullable
    public String getString(String key, @Nullable String defValue) {
        synchronized (mLock) {
            awaitLoadedLocked();
            String v = (String)mMap.get(key);
            return v != null ? v : defValue;
        }
    }

等待上面文件内容，读取完成后才会继续执行，否则会被阻塞住。

2.3 SP存在的问题

通过对原理啊的了解，我们会发现这样做有很多问题。总一下，主要有如下几个问题：

1.最终写入XML文件实用的是IO操作，IO操作需要两次拷贝，效率是比较低的。（原因自行百度，这里就不再赘述了）

2.实用XML格式进行存储，并且全部以字符串的形式进行保存，浪费存储空间。比如value="469068865"。需要占用17个字节，utf-8一个英文字符占用1个字节，则存储该值需要17个字节。

3.每次编辑时，都需要对文件进行全量的写入操作。因为每次都是对完整的数据Map进行写入操作，哪怕只修改了一个值。这样做无疑是极大的浪费。

4.SP虽然支持多进程访问，但是多进程的读取是相当不安全的，因为进程间内存不能共享，而SP的多进程是每个进程一个对象进行操作。所以我们安全的使用方式仍然是使用一个进程去读取，并提供ContentProvider的方式供其它进程访问或者增加文件锁的方式，这样做无疑增加了我们使用复杂度。

5.线程阻塞问题。上面我们看到，只有全部加载完xml中的内容后，getString的函数才能继续往下执行。所以线程会被阻塞。

三.MMKV如何解决这些问题

既然SP存在这么多的问题，所以腾讯才会放弃SP，新建MMKV项目去解决这些问题，那么MMKV是如何解决这些问题的呢？

3.1 实现高效的文件操作

IO操作是需要进行两次内存拷贝的，第一次从用户内存空间拷贝到内核空间，第二次从内核空间拷贝到磁盘。尤其第一次拷贝，是很浪费CPU性能的。

熟悉binder原理的都知道，binder实现了一次拷贝，其底层原理就是mmap。所以MMKV也使用了mmap的原理。把用户内存的一部分空间和内核内存的一部分空间映射到同一块物理内存上，这样用户对这部分的内存操作，就会直接反映到内核空间上，然后由内存完成最终的写操作，少了一次拷贝，则效率就会大幅上升。而且由于内核的拷贝是发生在系统进程，不会阻塞用户进程的操作。所以实际上mmap的写入执行效率，接近于直接进行内存操作的效率。