RFC-0144：大小检查工具

RFC-0144：大小检查工具
状态	已接受
领域	开发者
说明	提议重写 size_checker.go，以打造更一致的树内和树外开发者体验。
问题	85371
Gerrit 更改	609963
作者	awolter@google.com
审核人	sebmarchand@google.com amituttam@google.com samans@google.com atyfto@google.com rohpavone@google.com hjfreyer@google.com
提交日期（年-月-日）	2021-11-22
审核日期（年-月-日）	2021-12-10

摘要

本文档介绍了如何开发一种全新的大小检查工具， 以便开发者和产品所有者验证 其广告资源包和产品没有超出指定的尺寸预算。虽然 因为树外汇编和实现细节被有意排除 基础，设计要求和目标 。

设计初衷

在软件开发过程中，了解自己的软件是否适合 确保不超出目标尺寸限制Fuchsia 有一款尺寸检查工具 会分析不同软件组占用的空间， 每个组的预算。此工具与实现细节密切相关 为 fuchsia.git，因此无法在结账时使用 fuchsia.git。 因此，Chrome 等 Fuchsia 的消费者已实施了自己的 临时检查软件大小的方法。通过重写 作为 ffx 插件的检查工具并将其添加到 Fuchsia SDK 中， 对 Fuchsia 软件的规模预算执行将统一，这样更容易 以便开始使用 Fuchsia。

利益相关方

谁对是否接受此 RFC 有利。

教员：

• Hunter Freyer (hjfreyer@google.com)

审核者：

• Saman Sami (samans@google.com) - 功能
• Anthony Fadrianto (atyfto@google.com) - 与基础架构集成
• Sébastien Marchand (sebmarchand@google.com) - 与 基础设施
• Rohan Pavone (rohpavone@google.com) - 与 Chromium 集成
• Amit Uttamchandani (amituttam@google.com) - 集成到 ffx

已咨询：

• Aaron Wood (aaronwood@google.com) - 组装集成

社交化：

此项目作为内部文档进行社交讨论，并在会议上讨论 与相关方建立合作关系。要求已收集 是非常重要的

背景

此 RFC 假定您了解以下主题。

• 文件系统
• 软件包
• BlobFS
• OTA

两种形式的大小检查

尺寸检查可分为两类：

1. 刷写时映像不超过其目标分区大小。
2. Blob 在更新期间在 FVM 预算范围内。

刷写：开发者可以将新映像刷写到 Fuchsia 目标上。当 则分区的内容会完全替换为 新映像的字节。为确保成功刷写，新映像不得 大于分区的大小。

更新：Fucsia 目标可以通过无线下载进行更新。为确保 更新成功后，blob 消耗的总空间不得超过 为 FVM 设置的预算通常情况下，FVM 中的空间是为 UpdatePackage 和其他 Blob，这表示该工具 不能简单地填充 FVM，然后检查最终图像是否符合 。

当前工具

Fuchsia 提供了两种有助于检查大小的工具：

• size_checker.go
• blobfs-compression

size_checker.go

来源链接

此工具可以在树内（fuchsia.git 内）使用，以确保 blob 放入 预算。size_checker.go 通过确定压缩和 与 Fuchsia 存储区中 blob 目录的大小一致。预算可以 按商品定义，但目前不用于以下国家/地区中的任何商品： fuchsia.git。由于它会专门检查 fuchsia.git 中的目录， 工具无法在没有 fuchsia.git 结账的情况下使用。

首先，Fuchsia build 会生成一个 blobs.json 文件，其中会列出已压缩的 以及一个列出 blob 的 blob.manifest 文件， 这些 blob 的 Merkle 和源路径。

接下来，运行 size_checker.go 并执行以下操作：

1. 读取 blobs.json 以收集每个 blob 的压缩后大小： compressed_size。
2. 读取 blob.manifest 以收集所有软件包。
3. 计算 Blob 包含在软件包中的次数： share_count。
4. 计算每个 blob 的共享大小：shared_size = compressed_size / share_count。由于多项预算可能包含同一个 blob，因此我们使用 blob 的 shared_size，以便在 预算。
5. 构造一个 N 元和树，表示每 目录中，具体方法是将每个 blob 的 shared_size 添加到 节点的节点。
6. 遍历每项预算，并断言为 目录大小大于占用的空间。
7. 遍历预算中的每个非 blobfs 包，使用 blobfs-compression 计算 blob 大小的总和，并断言 以确保其在预算范围内
8. 输出结果。

blobfs-compression

来源链接

该工具可以估算一组 blob 的压缩和对齐大小， 准确率可能不是 100%，有时可能会偏高 blob 的大小。通过 工具永远不会低估 blob 的大小。

blobfs-compression 通过 Fuchsia SDK 传送给客户端， 估算为 Fuchsia 构建的代码大小的唯一方法， 位于 fuchsia.git 之外。Chromium 是此工具的客户端。

当前工具存在的问题

• 用于检查软件包大小的树内方法和树外方法不同 工具。
• 两种工具都无法直接检查映像大小以确保刷写 成功。
• size_checker.go
  • 未记录。
  • 取决于 Fuchsia build 的实现细节， 稳定的合同
  • 无法在树外运行。
• blobfs-compression
  • 不能保证返回准确的压缩后大小的 blob。
  • 在 blob 级别运行，这不如在 blob 级别运行 软件包级别开发者将软件添加到每个软件包中的产品 基础。
  • 没有标准的输出格式， 可编写脚本，自动使用很不稳定。

要求

1. 在 SDK 中提供可同时工作的树内和树外工具。
2. 工具支持当前工具的所有需要的现有应用场景。
3. 该工具可以执行两种类型的大小检查： <ph type="x-smartling-placeholder">
   </ph>
   • (a) 图片
   • (b) 一组软件包中的 Blob
4. 如果是第 (2) 种情况，请在所有软件包的所有软件包的集合中去重 blob 会执行什么操作
5. 当超出用户指定的预算时，工具将返回失败信息。
6. 这些工具可与其他 SDK 工具完美配合，例如 Image 汇编器 (RFC-0072)。
7. 该工具可在脚本中轻松使用，具有可解析的输出，并且 生成供 Gerrit Size 插件使用的输出。
8. fuchsia.dev 中会记录工具的用法和架构。

设计

统一的开发者体验

系统将使用 Rust 编写一个新的 ffx 插件，以执行两种类型的大小 检查。最好根据 ffx CLI 评分准则，鼓励共享工作流，并增加 提高曝光度此外，系统优先选择展开现有文件 而不必创建新视频

可编写脚本

此工具主要用于构建系统，因此输出应 可解析。输出格式可能会使用 json5 作为输出格式， 随着 Assembly 项目的推进，可以考虑其他格式。

图片尺寸

图片大小检查工具的运行时间应与构建 Flash 清单，其中将组建的映像映射到分区。目前， Flash 清单的创建是在 Fuchsia 构建系统中完成的，因此 ffx 插件 将通过 GN 操作调用。今后，我们可能会为 构建 Flash 清单，以及作为 ffx 插件的大小检查工具 在这些情况下应该能够无缝运行

测量图片大小很简单，只需打开文件并读取 元数据的长度。这适用于任何未压缩或 即 Sparse。此方法不适用的一个例子是稀疏 FVM； 因为目前没有可用于计算 则该工具会忽略对稀疏 FVM 的大小检查。

包装尺寸

Blob 和软件包大小检查应与 Assembly 紧密集成，因为 就是在组装过程中，工程师将包裹分成几组 以指定产品。

大小检查工具使用 blobs.json 文件，其中列出了经过压缩和对齐的 每个 blob 的大小。开发者可以提供多个 blobs.json 文件作为 输入到工具中。如果在提供的任何 blobs.json 中都找不到软件包的 blob 那么大小检查工具将为 使用 blobfs 工具，这会生成一个额外的 blobs.json。大小检查工具将读取生成的 blobs.json，以获取 缺少的 blob 的大小。

与现有的 size_checker.go 工具类似，新的大小检查工具 每个 blob 的共享大小除以大小除以 使用 blob 的软件包。此共享尺寸是在制定预算时使用的。

实现

此工具的实施和集成工作将在 阶段。

1. 声明软件包集的预算。请参阅 说明。
2. 编写一个 ffx 插件，确保软件包集不超出其预算
3. 确保 ffx 插件的输出与以前工具的输出一致 作为构建系统的一部分如果输出不同，则 build 应会失败。请参阅下文中的说明。
4. 声明映像的预算
5. 添加功能，以确保图片尺寸不超出预算
6. 停用 size_checker.go 并让新的 ffx 插件能够加载
7. 删除 size_checker.go 代码。

生成预算文件

为了避免重复性地为同一个广告系列 保持两组相同的预算 系统会更新构建系统以读取现有 size_limits.json 和汇编产品配置，并生成 新预算文件。系统会解析产品配置，以收集每个软件包 这些清单会根据它们所在的目录进行分类 在“size_limits.json”中设置的预算。

可能的预算文件格式为：

[
    {
        name: "name-of-package-set",
        packages: [
            "path/to/manifest1.json",
            "path/to/manifest2.json",
        ],
        budget_bytes: 12000,
    },
]

一旦新的大小检查工具能够承受 build 的负载，生成的 将签入到代码库中，并且生成的代码将 已删除。

输出比较

在过渡到新的大小检查工具期间，构建系统会断言： 新工具的输出与新工具的输出一致。脚本将 可解析这两种工具的输出，并确保预算和 计算的消耗量相等。在 为了关联这两种输出格式，脚本将假定名称 识别文件包是否完全相同。因为旧版工具和 这一新工具使用相同的底层机制来计算 一个 blob（使用 blobfs），则计算出的消耗也相同。

性能

大小检查工具适合在构建系统中使用，因此它具有 对性能不稳定性的容忍度高于网络堆栈等 另一方面，缩短构建时间对提高开发者的工作效率非常重要。 此外，该工具也处于构建的关键路径上，因为它必须 等到所有软件包构建完毕、映像组装完成后 可以开始运行，因此无法并行处理。

当前的 size_checker.go 工具大约需要 1-2 秒的运行时间， 我们的新工具应该尽量接近相同的持续时间。

工效学设计

请参阅设计部分。

向后兼容性

此设计不需要向后兼容。

安全注意事项

此设计对安全性没有任何影响。

隐私注意事项

此设计对隐私没有任何影响。

测试

在 Fuchsia 版本中，新的大小检查工具将与 size_checker.go，然后比较输出，以确保它们 相同的预算和计算出的空间消耗量。

在向该工具添加功能时，系统也会编写单元测试。

文档

相关文档将添加到 fuchsia.dev 中。

缺点、替代方案和未知问题

有一些不利的替代方案。

什么也不做：这需要客户针对 完成规模检查，但这并不能随着我们客户群的扩大而扩展。

重构现有工具：可以重构 size_checker.go，使其 支持树外规则。根据 CLI 评分准则， 在 ffx 中添加了一些公共工具，以鼓励共享工作流并 提升曝光度此外，重构当前代码所需的更改包括 完全改写该工具的工作实际上会更少。

使用 blobfs 压缩工具：为了计算经过压缩和校准的 每个 blob 的大小，则可以使用 blobfs-compression 工具， 生成新的 blobfs 图像。此替代方案的主要缺点是， blobfs-compression 工具不一定能进行准确的压缩或 对齐方式。具体而言，blobfs-compression 工具假定非紧凑 Merkle 树，通常会导致其 blob 大小大于 此外，blobfs-compression 工具只能测量一个 blob 因此使用起来更麻烦，并且可能 运行一次 blobfs 工具。生成 blobfs 图像更内联 当前的 size_checker.go 更加准确。

先验技术和参考资料

请参阅背景部分。