基礎理解#
我們可以直接把 v-a/b 分區理解成，當你在使用手機，進行系統升級，系統會把升級內容存放在 A 分區，你繼續使用 B 分區，前面的 V 就是虛擬的意思（virtual）。在盡量不影響你使用的開機情況下進行升級，取消了在 rec 分區進行升級的複雜操作。
詳細理解（我的淺見）#
首先說結構。傳統結構中，存在rec，boot，system分區，在 V-ab 結構中，捨棄了提到的這三個分區，取而代之的是：boot_a,system_a,boot_b,system_b。這就是 v-ab。
首先要介紹 Δ（delta，小寫 δ）文件。Δ 文件就是 cow (copy-on-write) 文件，字面意思，具體可以看wikipedia 的解釋。然後我們首先打開谷歌的官方文檔：https://source.android.com/devices/tech/ota/virtual_ab#device-mapper ，裡面請看：這個 super 分區（超級分區）
這個分區，就是用來儲存 Δ 文件的。那麼在進行一些比較大的升級的時候，Δ 文件可能比較大，預分的 super 分區可能存在不足的現象。這個時候，會把多餘的文件儲存到 /data 下。這個情況基本只發生在 Android11 上，因為 Android10 預留了兩倍邏輯分區的空間。Android10 的 VAB 分區本身就不是原生的，是根據動態分區改裝而來的。
那麼，當你在 Android11 手機上，開機狀態下進行升級時，在哪裡查看文件呢？你可以查看下面這個路徑：/data/gsi/ota，下面存在一些列的帶有cow的.img文件。至於存在與哪裡，就看系統分配的super分區的邏輯空間大小了。
現在再看官方文檔：https://source.android.com/devices/tech/ota/virtual_ab#dm-snapshot-overview ，下面的 DM 概述。其中：
快照設備是使用 snapshot 目標創建的。寫入快照設備將寫入 COW 設備。從快照設備讀取是從基本設備讀取還是從 COW 設備讀取，具體取決於快照是否更改了所訪問的數據。
這就說明了，為什麼在生成完 cow 文件之後，系統把bootContral.hal的合併狀態改為 snapshoted 了。如果當前你在操作 a 空間，那麼系統會把你當前的系統分區從system_a改為system_a_cow，然後會開始把你切換到 B 分區，你至此仍然可以正常使用手機，只是切換過程中你使用手機，可能會有一點點卡感覺。
在生成完 cow 文件之後，系統這時提示我們重啟。我們發現，重啟依然會有一個時間需要等待，和之前的 rec 讀 cmd 安裝差不多啊。那麼到底這個時間系統在做什麼呢？
首先我們默認你升級前使用的是 a 分區。在你關機後，由於之前的 hal 文件改為了 snapshoted，這個時候系統會把對應的舊系統分區和 Δ 文件進行合併。不過這個時候單純是加載到內存中，不是合併的二進制文件。如果這個時候重啟成功，那麼系統會在開機後，偷偷地合併剩餘的二進制文件，這個時候系統會把bootContral.hal的合併狀態改為 merging，合併中。如果存在開機失敗的狀態，那麼系統則直接讀取舊系統文件進行回滾（其實不是回滾，直接讀取就完事了）。直至開機成功，hal 文件的合併狀態才會被置空，等待下一次升級。
看到這裡你會問了，這個邏輯其實和之前的讀取刷機腳本進行升級差不多啊。其實這裡最大的差別，除了分區升級外，就是一個最厲害的點：在bootContral.hal的狀態為合併中（merging）的時候，你可以隨意重啟手機。而只有在bootContral.hal的狀態為合併中的時候，也才算是真正的系統升級狀態。接下來解釋為什麼很多手機看起來依然和之前的手機升級效果差不多？其實很多廠商會估計把這個合併過程加上動畫…… 讓你看起來手機沒有進入系統，實際上手機是進入系統了，只是沒有啟動桌面，給你看這個合併進度而已。如果這個時候你重啟，在重啟後，手機會繼續合併剩餘的文件，減少了崩潰的情況。即使崩潰，手機也會直接讀取舊系統文件，你依然可以重新進行升級！
總結#
其實這只是我簡單的理解。也看了網上的一些文章。因為谷歌對 v-ab 的描寫基本等於沒說… 看了大神們對 v-ab 的解釋之後，我才知道這玩意其實挺糊弄（中間替換系統分區名字那一段…），也挺牛的，減少了你每月一次可能由於升級導致系統崩潰的情況，也開始逐漸捨棄 bl……
唯一對不起的就是刷機佬，刷機學習成本再次提高…