一、实现

先看一下metadata内部是什么样子：

可以看出，metadata 内部是一块连续的内存空间。
其内存分布大致可概括为：
区域一 ：存 camera_metadata_t 结构体定义，占用内存 96 Byte
区域二 ：保留区，供未来使用
区域三 ：序号为 0 ~ entry_count-1 的 camera_metadata_buffer_entry_t 结构体对象，简
称 metadata_entry 结构体对象，每个对象有自己的 tag。
区域四 ：剩余未使用的 Tag 结构体的内存保留，该区域大小为(entry_capacity – entry_count)
个 TAG，也就是(entry_capacity – entry_count)个 camera_metadata_buffer_entry_t 的空间
区域五 ：所有 Tag 对应的具体 metadata 数据
区域六 ：剩余未使用的 Tag 占用的内存

可以简单记成：Head 区、Entry 区、Data 区。

在这其中，TAG 又是个什么玩意儿？
其实我们既然了解了 metadata 是用来描述图像特征的参数，比如常见的曝光、ISO 等等，
就不难理解它的数据结构应该是由 N 个 key 和 value 组成的。

二、TAG

camera_metadata_buffer_entry_t 和 camera_metadata_data_t

所谓TAG，就是camera_metadata_buffer_entry

 按行依次注释来看，其中，
tag 就是 TAG 的 key 值
count 就是 TAG 的 value 对应的 data 的数量
offset 标记当前的 key 值对应的 value 在 data_start 中的位置
当 value 占用的字节数小于等于 4 的时候，直接存储到 value[4]中（省空间）

tag

我们既然知道了 key 就是 camera_metadata_buffer_entry 里的 tag，那么这个 tag（key）到底
有哪些呢？
tag 很多，会按功能分组，每组叫做一个 section：
为了更方便快捷，常使用宏定义，一般目录系统默认定义 26 个 TAG：

注意这里最后一个 VENDOR_SECTION，它在枚举中的值为 0x8000,这是因为 vendor 可能还会
自己定义一些别 tag，这些 vendor 在 0x8000 后面 enum 值就不会冲突了。

定义各个 TAG 对应详细的参数，每个 TAG 用 START 开头、END 结尾。所有的 tag，都是以 section 中的名称为前缀，从 START 开始，以 END 结束

data

说完了 key，再来看一下 value，也就是每个 tag 对应的 data。
为了设计出 API，定义了这样的结构体，在这其中，tag 为 key，data 就是 union 中的指针指
向的 data（metadata_data_t），也就是 kv 模型中的 value。

再看 system/media/camera/src/camera_metadata.c 中的这个结构体：

这个结构体定义了每个 tag 的名字以及它的类型

（注意这里的类型不是说 Value 的类型，tag_info_t 的数组会分别定义这个 section 每个 tag 的实际 Value 类型）

每个 tag 不仅可以通过唯一的 key 找到，也可通过唯一的名字找到，进而获取 Value。