IO優化是怎麼做的，使用 SharedPreferences為什麼這麼卡，mmkv原理是什麼

IO優化是怎麼做的，使用 SharedPreferences為什麼這麼卡，mmkv原理是什麼

心理分析：IO優化一直是每個企業必選項，每次聞到都很頭疼，面試官想問有沒有相關經驗，如果有的話，只有兩種答案sqlitedatabse， SharedPreferences。 這兩個很常見，肯定不是面試官想問的。 那只有一種答案了，對，就是最新的mmkv框架

接下來，會問你他的原理 你是怎麼看。 它的優缺點。為什麼比其他的好。從原理層來解析。這才是最難的。

這篇文章 從原理層說明他們的區別

1.1 MMKV的概念

mkkv是基於 mmap 的高效能通用 key-value 元件，底層序列化/反序列化使用 protobuf 實現，效能高，穩定性強。

1. MMKV 是基於 mmap 記憶體對映的移動端通用 key-value 元件，底層序列化/反序列化使用 protobuf 實現，效能高，穩定性強。
2. 從 2015 年中至今，在Android 微信上使用已有近 3 年，其效能和穩定性經過了時間的驗證。在騰訊內部開源半年之後，得到公司內部團隊的廣泛應用和一致好評。
3. 通過 mmap 記憶體對映檔案，提供一段可供隨時寫入的記憶體塊，App 只管往裡面寫資料，
   由作業系統負責將記憶體回寫到檔案，不必擔心 crash 導致資料丟失。
4. XML、JSON 更注重資料結構化，關注人類可讀性和語義表達能力。 ProtoBuf 更注重資料序列化，關注效率、空間、速度，人類可讀性差，語義表達能力不足（為保證極致的效率，會捨棄一部分元資訊）

1.2 特點

• 高效能 實時寫入
• 穩定 防crash
• 多程式訪問
  通過與 Android 開發同學的溝通，瞭解到系統自帶的 SharedPreferences 對多程式的支援不好。
  現有基於 ContentProvider 封裝的實現，雖然多程式是支援了，但是效能低下，經常導致 ANR。
  考慮到 mmap 共享記憶體本質上的多程式共享的，我們在這個基礎上，深入挖掘了 Android 系統的能力，提供了可能是業界最高效的多程式資料共享元件。
• 匿名記憶體
  在多程式共享的基礎上，考慮到某些敏感資料(例如密碼)需要程式間共享，但是不方便落地儲存到檔案上，直接用 mmap 不合適。
  我們瞭解到 Android 系統提供了 Ashmem 匿名共享記憶體的能力，發現它在程式退出後就會消失，不會落地到檔案上，非常適合這個場景。
  我們很愉快地提供了 Ashmem MMKV 的功能。
• 資料加密
  不像 iOS 提供了硬體層級的加密機制，在 Android 環境裡，資料加密是非常必須的。
  MMKV 使用了 AES CFB-128 演算法來加密/解密。我們選擇 CFB 而不是常見的 CBC 演算法，
  主要是因為 MMKV 使用 append-only 實現插入/更新操作，流式加密演算法更加合適。
• 資料有效性

1.3效能對比

我們將 MMKV 和 SharedPreferences、SQLite 進行對比, 重複讀寫操作 1k 次。相關測試程式碼在 Android/MMKV/mmkvdemo/。結果如下圖表。

單程式效能

可見，MMKV 在寫入效能上遠遠超越 SharedPreferences & SQLite，在讀取效能上也有相近或超越的表現。

可見，MMKV 無論是在寫入效能還是在讀取效能，都遠遠超越 MultiProcessSharedPreferences & SQLite & SQLite， MMKV 在 Android 多程式 key-value 儲存元件上是不二之選。

1.3 MMKV 原理

• 記憶體準備 通過 mmap 記憶體對映檔案，提供一段可供隨時寫入的記憶體塊，App 只管往裡面寫資料，由作業系統負責將記憶體回寫到檔案，不必擔心 crash 導致資料丟失。

• 資料組織 資料序列化方面我們選用 protobuf 協議，pb 在效能和空間佔用上都有不錯的表現。

• 寫入優化 考慮到主要使用場景是頻繁地進行寫入更新，我們需要有增量更新的能力。我們考慮將增量 kv 物件序列化後，append 到記憶體末尾。 這樣同一個 key 會有新舊若干份資料，最新的資料在最後；那麼只需在程式啟動第一次開啟 mmkv 時，不斷用後讀入的 value 替換之前的值，就可以保證資料是最新有效的。

• 空間增長 使用 append 實現增量更新帶來了一個新的問題，就是不斷 append 的話，檔案大小會增長得不可控。我們需要在效能和空間上做個折中。 以記憶體 pagesize 為單位申請空間，在空間用盡之前都是 append 模式；當 append 到檔案末尾時，進行檔案重整、key 排重，嘗試序列化儲存排重結果； 排重後空間還是不夠用的話，將檔案擴大一倍，直到空間足夠。

• 資料有效性 考慮到檔案系統、作業系統都有一定的不穩定性，我們另外增加了 crc 校驗，對無效資料進行甄別。

更詳細的設計原理參考 MMKV 原理。

1.4 快速上手

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

MMKV的使用非常簡單， 所有變更立馬生效，無需呼叫 sync、apply。 在 App 啟動時初始化 MMKV，設定 MMKV 的根目錄 (預設/data/data/xxx.xxx/files/mmkv/) (sp儲存在/data/data/xxx.xxx/shared_prefs/)

支援從SP遷移資料importFromSharedPreferences

MMKV 還額外實現了一遍 SharedPreferences、SharedPreferences.Editor 這兩個 interface

  // 可以跟SP用法一樣
  SharedPreferences.Editor editor = mmkv.edit();
  // 無需呼叫 commit()
  //editor.commit();

MMKV 的使用非常簡單，所有變更立馬生效，無需呼叫 sync、apply。 在 App 啟動時初始化 MMKV，設定 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);
      }

1.5 補充適用建議

如果使用請務必做code19版本的適配，這個在github官網有說明

依賴下面這個庫，然後對19區分處理
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);
  }

1.6 限制

可看到，一個鍵會存入多分例項，最後存入的就是最新的。
MMKV 在大部分情況下都效能強勁，key/value 的數量和長度都沒有限制。
然而 MMKV 在記憶體裡快取了所有的 key-value，在總大小比較大的情況下（例如 100M+），App 可能會爆記憶體，觸發重整回寫時，寫入速度也會變慢。
支援大檔案的 MMKV 正在開發中，有望在下一個大版本釋出。

1.7 多程式使用

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

​ 注意：如果其他程式有進行修改，不會立即觸發onContentChangedByOuterProcess，
checkLoadData如果變化，會clearMemoryState，重新loadFromFile。//資料量大時不要太頻繁
讀取decodeXXX會阻塞住，先回撥onContentChangedByOuterProcess，再返回值，保證值是最新的。

1.7.2 mmkvWithAshmemID 匿名共享記憶體

可以進行程式間通訊，可設定pageSize
// a memory only MMKV, cleared on program exit
// size cannot change afterward (because ashmem won't allow it)

1.7.3 測試結果

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

1.8 Binder MMAP（一次拷貝）

​ Linux的記憶體分使用者空間跟核心空間，同時頁表有也分兩類，使用者空間頁表跟核心空間頁表，每個程式有一個使用者空間頁表，但是系統只有一個核心空間頁表。
而Binder mmap的關鍵是：更新使用者空間對應的頁表的同時也同步對映核心頁表，讓兩個頁表都指向同一塊地址，
​ 這樣一來，資料只需要從A程式的使用者空間，直接拷貝到B所對應的核心空間，而B多對應的核心空間在B程式的使用者空間也有相應的對映，這樣就無需從核心拷貝到使用者空間了。

copy_from_user() //將資料從使用者空間拷貝到核心空間
copy_to_user() //將資料從核心空間拷貝到使用者空間

1.8.1 Liunx程式隔離

1.8.2 傳統IPC

1.8.3 Binder通訊

1.9 普通檔案mmap原理

普通檔案的訪問方式有兩種：

1. ​ 第一種是通過read/write系統調訪問，先在使用者空間分配一段buffer，然後，進入核心，將內容從磁碟讀 取到核心緩衝，最後，拷貝到使用者程式空間，至少牽扯到兩次資料拷貝；
   同時，多個程式同時訪問一個檔案，每個程式都有一個副本，存在資源浪費的問題。
2. ​ 另一種是通過mmap來訪問檔案，mmap()將檔案直接對映到使用者空間，檔案在mmap的時候，記憶體並未 真正分配，

​ 只有在第一次讀取/寫入的時候才會觸發，這個時候，會引發缺頁中斷，在處理缺頁中斷的時候，完成記憶體也分配，同時也完成檔案資料的拷貝。
並且，修改使用者空間對應的頁表，完成到實體記憶體到使用者空間的對映，這種方式只存在一次資料拷貝，效率更高。

同時多程式間通過mmap共享檔案資料的時候，僅需要一塊實體記憶體就夠了。

​ Android中使用mmap，可以通過RandomAccessFile與MappedByteBuffer來配合。
通過randomAccessFile.getChannel().map獲取到MappedByteBuffer。然後呼叫ByteBuffer的put方法新增資料。

  RandomAccessFile randomAccessFile = new RandomAccessFile("path","rw");
  MappedByteBuffer mappedByteBuffer= 
  randomAccessFile.getChannel().map(FileChannel.MapMode.READ_WRITE,0, 
  mappedByteBuffer.putChar('c');
  mappedByteBuffer.getC

作者：位元組走動_Android
連結：https://www.jianshu.com/p/088cd1d90a20
來源：簡書
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。