Android新特性virtualAB总结

一、原理

（一）Virtual A/B分区布局

上面这个表是Virtual A/B分区布局

其中

这些分区对于引导非常重要，它是由引导加载程序直接加载的。

所有启动关键分区都有一个A和一个B副本。大多数启动关键分区都很小。例如，vbmeta是64KiB, boot是64MiB, dtbo是8MiB等等。创建这些分区的A/B副本所需的空间相对较少。

 

其他这些分区是动态的，所以它们包含在super中。

（二）virtualAB新特性：快照合并

1、名字解释

先解释几个名词

（1）、解释snapshot快照

Ok，这里出现一个名词需要解释一下snapshot——快照技术

我不想把百度百科上面一堆看不懂的句子放在这。简单解释一下

快照技术本身可以看做是一种备份技术，但快照技术和传统备份技术有区别

区别在于打个比方

我有一串数据“ABCDEF”，存储的地址是从0x0到0x5

备份就是我找一块空间0x7到0x12，我把数据完全的拷贝到这块空间

从这里看备份的缺点很明显，如果数据比较大，但改动又不多或者集中在某个区域，就很占用空间

而且比如我就1000位数据我常改其中50位的数据，你就都备份，那有浪费了950位数据的额空间

而快照技术并不备份所有数据，我只记录上次对这部分数据进行写操作的时间点和改动的数据（不是全部数据），这样我要记录的数据比起把数据全部备份就少的多了。

快照技术分为两种：写时复制和 I/O 重定向

 

写时复制就是比如我要把“ABCDEF”这串数据（存储的地址是从0x0到0x5）改为“ABCMEF”，只把其中的D改为M

如果是写时复制，就是我先把元数据读出来（从0x3读出D），然后把D改成M，然后改动的数据写在另一个位置（快照），然后再把改动的数据写到元数据处（0x3）

所以可以看到一次写时复制进行快照需要一次读操作，两次写操作，如果数据改动非常频繁，我改一次数据却需要花3次I/O时间

所以如果写操作过于分散且频繁，那么 COW造成的开销则是不可忽略的，有时甚至是无法接受的。因此在应用时，则需要综合评估应用系统的使用场景，以判断这种方式的快照是否适用。

然后读数据的时候，因为元数据的位置已经改动了，所以我无需去读快照空间的数据来获取，直接读元数据的位置就好

这是写时复制

 

如果是I/O重定向，还以比如我要把“ABCDEF”这串数据（存储的地址是从0x0到0x5）改为“ABCMEF”，只把其中的D改为M举例

首先从先把元数据读出来（从0x3读出D），然后把D改成M，然后改动的数据写在另一个位置（快照），

注意到这就不一样了，不改动元数据位置的数据，就是说0x3处还是D

所以这样一次快照就是一次读操作，一次写操作

然后下次写操作还是一样。