RFC-0271：锚定软件包

问题陈述

目前，Fuchsia 中的系统更新（“OTA”）实现需要同时存储两组完整的 blob。这很简单，但对于磁盘空间不足的设备来说，这会造成问题。

摘要

此 RFC 提出了锚定软件包的实现方案，该方案最初在 RFC-212 中进行了介绍。这些软件包集满足以下不变性：

• 在系统更新 (OTA) 期间，系统只会下载永久锚定的软件包（bootfs、根据 RFC-212 定义的 base）。
• 软件包及其 blob 由其 Merkle 哈希进行唯一标识。对于自动锚定和按需锚定软件包，更新软件包中包含包含此信息的 meta.far 归档哈希。
• 自动锚定和按需锚定软件包会在应用系统更新并设备启动到新系统版本后某个时间下载。
• 上一点与 RFC-145 中的提前更新（根据 RFC-212 映射到一组可自动升级和永久可升级软件包）特别不相符：锚定软件包不会将确定“正确”软件包的身份验证委托给其他方：提前更新允许软件包独立于系统 OTA 进行更新，而锚定软件包则不允许。

这些不变性对锚定软件包集产生以下影响：

• 由于所有软件包的加密哈希值仍随系统更新分发，因此无法在不执行系统更新的情况下将其更新到较新版本。
• 从应用的角度来看，软件包是随 OTA 分发还是作为锚定软件包分发无关紧要。不过，在访问尚未解析的软件包提供的功能时，应用可能会出现一些延迟。如需了解详情，请参阅“效果”部分。
• 自动锚定软件包不会按需下载，这与工程 build 中的 TUF 代码库中的软件包和按需锚定软件包不同。而是在启动到更新后的系统后下载。

可以利用自动锚定和按需锚定软件包，避免在 OTA 期间需要将系统中的每个软件包存储两次在设备的非易失性存储空间中，从而提高存储效率，尤其是在存储空间受限的设备上。

设计初衷

在正式版 Fuchsia 系统上，常用的系统更新机制目前会通过三分区“ABR”方案执行完整更新。分区 A 和 B 各包含一个完整的系统映像。R 分区包含一个最小恢复分区，不在本 RFC 的适用范围内。

分区 A 或 B 中的某个分区是任何时间点的活动分区，即引导加载程序会在设备开机时将系统引导到活动分区。目前，对于用户 buildtype，软件包管理系统知道的所有软件始终可在设备上使用。

执行 OTA 时，系统更新程序会将完整的新系统映像写入非活动分区 A 或 B。此外，它还可确保将所有已知 blob 下载到由 A 和 B 槽共享的 fxblob/blobfs 存储空间。成功完成后，它会翻转指示哪个分区是活动分区的位，并重新启动到新的系统映像。这意味着，在任何给定时间，一个完整的系统映像都会占用空间，但完全不会被使用，并且在一个时间范围内，fxblob/blobfs 必须同时保留当前运行的设备软件版本和新版本的 blob。这样可以更高效地使用设备资源。RFC-212 定义并概述了 Fuchsia 软件包管理系统扩展的命名法和概念，以缩减系统映像的占用空间。它通过允许将软件包从系统映像中排除，并在系统更新后将其下载到 fxblob/blobfs 存储空间来实现此目的。这样，就无需在旧版和新版软件包同时占用 fxblob/blobfs 空间的时间段内进行处理。

支持锚定软件包的另一个动机是希望尽量减少不必要的网络流量。如果基于 Fuchsia 的系统的大多数用户根本不使用某些软件组件，从 OTA 中排除这些组件并仅按需下载这些组件，可能会大幅减少要传输的数据量，从而减少服务器和网络所需的容量。

定义

以下术语和定义适用 RFC-212 中的定义：基础、Bootfs 软件包、缓存、提前更新、垃圾回收、软件包、软件包集、软件包版本、父级软件包、永久性软件包、产品、产品 build、产品版本、子软件包、系统更新、Universe、版本控制权威。

利益相关方

教员：

jamesr@google.com

审核者：

• etryzelaar@google.com（荷兰）
• amituttam@google.com（项目经理）
• awolter@google.com（软件组装）
• markdittmer@google.com（安全）
• gtsai@google.com（基础架构）

社交：

此 RFC 在软件交付团队内部的一系列设计讨论中得到了讨论。此 RFC 文本的早期版本已交由软件交付团队、构建和汇编团队以及潜在客户的利益相关方进行审核。

要求

• 锚定软件包的传送机制不得需要额外的服务或基础架构，即将系统更新 (OTA) 传送到目标设备的机制也适用于锚定软件包。
• 哪些软件包属于哪个锚定软件包集的规范是手动完成的。不会根据此 RFC 实现任何尝试自动确定哪个软件包可以属于哪个软件包集的机制。
• 实现的范围受 RFC-212 中定义的限制所限，如下图所示。具体而言，自动或按需锚定软件包不会涵盖或支持以下场景：
  • 支持委托版本控制。
  • 支持对产品开箱即用体验 (OOBE) 工作流至关重要的软件包。
  • 这意味着，如果对 OOBE 至关重要的软件包被标记为自动软件包或按需锚定软件包，软件包管理堆栈无法保证在需要时能够提供成功完成 OOBE 工作流所需的所有软件包。这是因为在许多情况下，OOBE 工作流包括设置网络。因此，无法保证在 OOBE 完成之前就能解析自动和按需锚定软件包。

设计

锚定的软件包集

软件包集是指一组软件包，所有这些软件包均使用相同的策略进行传送和更新。在生产设备中，最常用的软件包集是永久（base 和 bootfs）集，它们具有以下主要特征：始终可用且由产品定义设置：

• 用于描述软件包并确保其完整性的 Merkle 哈希
• 以及软件包本身

在重新启动到更新的产品版本之前，在 OTA 更新流程中下载。因此，结合 Fuchsia 的默认 ABR 分区方案（其中 A 分区和 B 分区都包含完全可启动的系统），基础 set 的软件包可能会在 fxblob/blobfs 中存储两次：如果它们不同，则存储区中会包含 A 分区中产品的一个版本，以及 B 分区中产品的一个版本。在运行的系统中，基准软件包的 data/static_packages 文件会反映基准软件包集中的软件包列表。在软件包解析过程中，这些软件包由 pkg-cache 的一部分 base resolver 解析。换句话说，它们在本地解析，不需要网络连接。

自动和按需 锚定软件包集与 bootfs 和基础软件包集具有一些共同的特征，但在根本上有所不同：

• 与基本软件包一样，描述锚定软件包的 Merkle 哈希会在重新启动到新系统版本之前下载到预期的系统分区。
• 与 base 和 bootfs 软件包不同，在重新启动到新系统之前，blob 本身不会下载到 fxblob/blobfs。

这样可以优化 OTA 更新的下载阶段，以缩减存储空间，因为这样可以避免在非易失性存储空间中保留软件包的多个版本。下文中的“使用自动锚定软件包的启动顺序”介绍了这一点。

自动和按需 锚定软件包之间的区别在于触发器，该触发器会导致软件包解析器提取软件包：

• 只要有任何有权在运行的 Fuchsia 系统上查询解析器的符合条件的组件请求解析软件包，系统就会立即提取按需锚定软件包。
• 在执行 OTA 后，系统会在重新启动到新的 Fuchsia 系统后尽早解析自动锚定软件包。

锚定软件包的垃圾回收

本 RFC 建议，在未来垃圾回收算法可能进行修订之前，收集锚定软件包时应遵循以下规则：

• 自动锚定软件包下载到 fxblob/blobfs 后，将受到保护，不会被垃圾回收，直到下次重新启动到较新系统。
• 只有当系统版本（以及 Merkle 哈希）发生变化，并且不再属于当时运行的系统版本时，自动锚定的软件包才会被垃圾回收。
• 按需锚定文件包不会获得额外的垃圾回收保护，并且将遵循 RFC-217 中关于开放文件包跟踪的规则。

解决了按需锚定软件包的问题

软件包解析器已经具备下载软件包并按需将其提供给正在运行的系统的功能。因此，将此功能用于按需锚定软件包非常简单：一旦系统上不可用的软件包解析完毕，软件包解析器就会下载 blob，这些 blob 将经过验证，并通过 fxblob/blobfs 提供。

始终可用软件包集与自动/按需 锚定软件包之间的主要区别在于，对于后两者，解析器需要连接到互联网。

从运行系统的角度来看，按需锚定软件包不必明确标记为此类软件包。请求软件包时，解析器只会注意到软件包缓存中没有其 blob，并启动下载流程。

不过，确定软件包是否应作为按需锚定软件包包含在产品中，取决于开发者，并且必须在产品定义中将其标记为此类软件包：

• Fuchsia 产品定义将接受 on_demand_anchored 软件包的列表。
• ffx assembly product 工具将能够将列表发送到映像汇编配置。

在产品组装期间：

• 该软件包（blob 和清单）包含在主商品套装中。
• 这些 blob 不包含在用于刷写设备的 fxblob/blobfs 中。
• 按需锚定集中的软件包列表的构建方式与基本软件包类似。该列表将是 AssemblyManifest 的一部分，并包含在更新软件包中。正在运行的 Fuchsia 系统会在基本软件包的 data/anchored_packages 文件中找到此集合的软件包列表。

解决了自动锚定软件包的问题

与按需锚定软件包一样，确定软件包是否应作为自动锚定软件包包含在商品中，取决于开发者，并且必须在商品定义中将其标记为此类软件包：

• Fuchsia 产品定义将接受 automatic_anchored 软件包的列表。
• ffx assembly product 工具将能够将列表发送到映像汇编配置。

在产品组装期间：

• 该软件包（blob 和清单）包含在主商品套装中。
• 这些 blob 不包含在用于刷写设备的 fxblob/blobfs 中。
• 自动锚定集中的软件包列表的构建方式与基本软件包类似。该列表将是 AssemblyManifest 的一部分，并包含在更新软件包中。正在运行的 Fuchsia 系统将在系统更新软件包的 data/anchored_packages 文件中找到此软件包集的软件包列表。

重启到新的或升级后的 Fuchsia 系统后，此组中的软件包会解析。如前所述，这与 data/static_packages 中的软件包明显不同，后者始终存在且为 pkg-cache 所知。

包含自动锚定软件包的启动顺序

包含一组自动更新软件包的系统的启动顺序如下：

• 在设备首次启动或在 OTA 更新后重新启动后，确认网络连接后：
  • 系统将执行 fxblob/blobfs 垃圾回收，以驱逐之前系统版本中存在的悬空 blob。
  • 如果网络连接不佳，系统会延迟垃圾回收，直到网络可用为止。
• 启动序列会照常完成，并且基础软件包的所有软件包都已可用。
• 在启动顺序完成时，软件包解析器将检查自动锚定集的每个 blob 是否存在，并开始下载 fxblob/blobfs 中不存在的所有 blob。
• 如果发生下载错误，解析器会继续检查自动锚定集合中是否缺少 blob，并在系统累积正常运行时间时重新尝试下载缺少的 blob。

软件包可能无法使用

与仅提供永久软件包的系统不同，一旦按需或自动锚定软件包开始发挥作用，系统便无法再保证所有软件包始终可用。

默认情况下，除非产品明确要求并正确实现此行为，否则启动过程不会因下载失败或下载速度缓慢而阻塞。这主要有以下两个原因：

• 设备可能尚未配置网络连接，并且必须先完成开箱体验 (OOBE) 工作流，然后才能下载按需或自动锚定软件包。
• 可能会给用户带来不良体验。例如，在下载一组自动 锚定软件包时，设备可能会丢失互联网连接，而用户希望使用通过基础软件包集轻松提供的设备简单功能。

请注意，由于软件包至少可能会间歇性不可用，因此依赖于这些软件包的组件必须能够妥善处理这种情况。具体而言，对于可能需要通过网络提取的组件，对其进行调用无法保证会在特定时间内完成，因为大多数用例的网络延迟时间和速度都是未知的。如需了解详情，请参阅“报告软件包的可用性”部分。

报告软件包的可用性

与设备上始终可用所有已知软件包的情况相比，OTA 后下载和 OTA 存储空间节省的好处是可预测性。这可能会产生相关要求，例如：

• 在调用特定函数之前，组件可能需要知道依赖项是否可用或是否仍在下载。
• 尤其是需要与用户互动的应用，可能需要实现一种机制，以监控调用某项功能的提供程序时是否出现意外的长等待时间，并向用户显示消息以管理他们的预期。
• 跟踪或调试工具可能需要检查有关软件包可用性的详细数据或指标，例如软件包是否存在、是否正在下载、下载速度、延迟时间、重试次数等。

在撰写此 RFC 时，我们尚不完全了解具体详细要求以及对 Fuchsia 平台所产生的更改的影响。因此，本文档不介绍此类监控和可用性报告的详细设计。未来的 RFC 或实现中可能会解决此问题。

根据目前的规划，工具（例如 debug_agent 或 zxdb）可能是最早利用某种可用性报告和监控功能的组件。这有助于更好地了解未来需要解决的要求、差距和必要的变化。与交互式界面互动、向最终用户报告进度等复杂用例不在这组初始用例的范围内。

实现

实现将分为多个阶段，以便参与的团队之间进行同步，并在为基于 Fuchsia 的产品启用该功能之前对该功能进行验证。

第 1 阶段将涵盖在软件包解析器和软件包缓存中实现纯功能，这需要：

• SWD
  • 支持在启动时从基础软件包的 data/anchored_packages 获取自动锚定软件包的列表，并提供自动锚定软件包的 blob。
• build、assembly
  • 支持在产品构建期间处理所需的自动和按需锚定软件包列表，并向映像提供 data/anchored_packages。
  • 更新了大小检查工具，以支持锚定型软件包并正确反映 build 和图片大小。
• 安全性
  • 对自动锚定和按需锚定软件包解析的面向互联网的代码路径进行技术审核。

第二阶段将涵盖为基于 Fuchsia 的产品启用新功能的准备工作。这需要：

• SWD
  • 准备现有商品配置的变体，将部分软件包从基础集移至自动或按需锚定集。
• 服务器端打包基础架构
  • 用于存储软件包并与 blob 存储空间集成。

在第三阶段，我们将在基于 Fuchsia 的产品中采用自动或按需锚定软件包，并提供第一个应用。此决定超出了 RFC 的范围。不过，从概念上讲，这需要：

• 所选应用 / 维护团队和测试团队
  • 请检查并调整应用，以便在依赖项暂时不可用时进行处理。
  • 创建和调整测试和测试计划，以模拟和运行可能出现的一组错误状态（下载速度缓慢、DNS 问题、连接中断、开箱即用体验等）。
• 版本管理
  • 确保已实施端到端产品测试，以确保 OTA 和 OOBE 工作流不依赖于按需软件包。
  • 负责管理包含固定软件包的版本，确保其顺利完成所有阶段，并最终面向基于 Fuchsia 的产品用户发布。

data/anchored_packages 文件

实现的核心要素是系统如何识别自动锚定和按需锚定软件包。如前所述，它们将在 data/anchored_packages 中列出，类似于 data/static_packages 文件。不过，与 static_packages 文件的简单键值对格式不同，此格式在开始时会为自动锚定软件包和按需锚定软件包传达更多信息：

• 是自动还是按需。
• 软件包，由其网址标识。
• 软件包哈希值。

因此，从概念上讲，data/anchored_packages 文件将是一个 JSON 文件，其中包含以下信息：

{
  "on_demand": {
    "fuchsia-pkg://fuchsia.com/package1": {
      "hash": "d5eb4bb8a394176f20a266bac7cd8a077579f57119c5e1ed0981cd5ea563c183"
    },
    "fuchsia-pkg://fuchsia.com/package2": {
      "hash": "d33da6cb5fc8787ae1386e85ff08a32c6e846668d5eb4bb8a394176f20a2681c"
    }
  },
  "automatic": {
    "fuchsia-pkg://fuchsia.com/package3": {
      "hash": "d189658d88636999abe2c4375409ace94fd0408d338e96692b8b8bad07c484d4"
    },
    "fuchsia-pkg://fuchsia.com/package4": {
      "hash": "e6c22775bac3301f18d012493ffc6c7fe442b59cd5eb4bb8a394176f20a266ba"
    }
  }
}

性能

此 RFC 的性能影响可分为以下几个方面：

1. 在 fxblob/blobfs 上可用的软件包在基于 Fuchsia 的产品中的运行时性能。我们预计此方面的运行时性能不会有明显变化，因为对于锚定集的已解析软件包，它们与基本软件包在软件包缓存提供方式或运行方式方面没有区别。

2. 在运行时，对于软件包管理系统已知但尚未下载的软件包，基于 Fuchsia 的产品的性能。从 CPU 和内存消耗方面来看，解决方案（下载、验证）对基于 Fuchsia 的产品的整体性能影响预计不大。不过，如果产品用户想要执行依赖于仍在下载的软件包的功能，则影响可能会明显。在这种情况下，用户体验会受到一定程度的影响，具体取决于下载速度。该程度主要取决于用户互联网连接的速度和延迟时间，因此不在本 RFC 的讨论范围之内。请注意，如果设备端应用依赖于仍在下载的软件包，则可以向用户说明情况，例如通过传达一条消息来表明所需的下载仍在进行中。从用户体验的角度来看，这比设备无响应或处于未知状态要好。

3. 对于使用自动锚定软件包的产品，OTA 流程的总时长会发生变化。我们预计，平均而言，“开始下载系统更新软件包”和“新 build 正在运行”之间的时间会缩短，“开始下载系统更新软件包”和“所有软件包均已解析”之间的时间会延长。如上一个关于解析 fxblob/blobfs 上尚不可用的软件包的要点中所述，建议依赖于非永久性软件包的软件做好管理用户预期的准备。对于某些类型的设备，时长变化可能不是问题，例如，在设备闲置的深夜定期更新设备。

4. 与以单个 OTA 形式分发更新的产品相比，在为采用自动或按需锚定软件包的产品分发时，软件包分发基础架构最有可能遇到不同的负载模式。例如，这取决于设备在收到更新软件包后是否会重新启动（如果是自动锚定软件包），或者用户首次请求某项功能时是否会重新启动（如果是按需锚定软件包）。此外，与仅提供静态软件包的产品相比，地理位置和用户是否会使用某些功能等其他因素也会导致软件包分发基础架构的负载不同。“未来工作”部分将讨论这方面的一些方面。

5. 鉴于上述几点，建议您提供以下指标：(i) 更新软件包的下载和安装时长；(ii) 首次重新启动到新 build 后自动锚定软件包的解析时长。这样可以更好地了解在系统更新成功应用后，用户体验出现不稳定的互联网连接或下载速度缓慢的情况有多频繁。

基准

利用锚定软件包的产品在用户可见的活动方面可能会有所不同。因此，对于此类产品，我们建议定期收集其他基准，以确保用户体验不会下降，并在基准显示以下情况时采取相应措施：

• 在定义的各种网络条件（上行 / 下行速度、延迟时间、数据包丢失等）下，给定商品的一组自动锚定和按需锚定文件包的解析时间。
• 在定义的各种网络状况下，锚定软件包解析失败尝试的频率。
• 基于 Fuchsia 的产品请求依赖于尚未解析的软件包的功能的频率。

这些指标旨在提供数据，以便做出合理的决策，确定是否可以将某个软件包移出基准组，或者是否应将锚定软件包移回基准组。

工效学设计

工程工作流

工程工作流程与目前可通过 eng build 实现的工作流程基本相同，其中软件包会从代码库服务器动态提供，并提供 TUF 代码库。一般来说，组件不必处理其依赖项的提供方式的低级别细节，软件包解析过程会抽象出这些细节。

如果发现缺口，我们预计会扩展围绕 ffx 的现有工具，以支持围绕锚定软件包的测试和开发工作流。

向后兼容性

这项工作将向后兼容软件分发堆栈的现有用法。软件包网址命名空间结构或解析概念不会发生变化。

这项工作不会废弃现有功能。因此，除非使用锚定软件包，否则更改完全透明。

安全注意事项

此提案存在安全注意事项。它们与 RFC-145 略有重叠，但从根本上讲，此提案更为温和。

• 与 RFC-145 一样，我们会在系统运行时解析软件包，即软件包解析器需要连接到互联网的权限，至少在所有软件包都解析完毕且 blob 存储在 fxblob/blobfs 中之前。
• 与 RFC-145 不同，此提案不会委托对一组可运行软件包的权限。启动到新的 OTA 后，系统会知道整个软件包宇宙的所有哈希值。因此，产品定义和有效软件包的构成与仅使用基本软件包的产品相同。

隐私注意事项

我们认为，该提案不包含任何会影响隐私权的新功能。不过，应考虑以下几点：

我们建议在“基准”部分中更早地介绍新指标。这些指标旨在导致用户体验回归原有水平。如果此类基准测试是从生产设备收集的，则在引入时必须经过隐私权审核。

测试

现有测试套件中的扩展将涵盖软件交付堆栈中的新扩展，并涵盖单元测试、集成测试和 e2e 测试，涵盖所有新代码路径。

测试还将涵盖以下场景：锚定软件包的解析取决于之前成功完成的垃圾回收，以及遇到磁盘接近满载的情况。

如需评估利用锚定软件包的 Fuchsia 产品的用户体验，应对关键用户工作流进行验证，尤其是在网络状况不佳的情况下。

文档

接受此 RFC 后，我们将：

• 更新了“package”（软件包）的术语表条目。
• 更新了“概念”中的软件包部分。
• 更新了“IDK 中的软件包”页面。
• 更新“使用入门指南”中关于商品套餐的页面。
• 添加了有关使用锚定软件包时如何配置更新的信息。

缺点、替代方案和未知情况

替代方案：为基于 Fuchsia 的产品使用其他分区方案

此替代方案不涵盖与之前侧重于软件交付机制相同的语义范围，并且与此 RFC 大致是相互独立的。但它重点介绍了自动和按需锚定软件包的一个重要原因：为了节省基于 Fuchsia 的产品的非易失性存储设备上的空间。

通常假定这些产品基于 ABR 分区方案构建：

• A 和 B 作为可容纳整个系统映像的分区
• 将 R 用作紧急情况的恢复分区，以便在 A 和 B 均不可用时使用

虽然它已被证明是一种可行的方法，并被广泛用于各种类型的设备，但它绝不是唯一的选择。至少还有两种可以节省近一半空间的方案：

• AR 方案：只有一个系统分区 (A)。OTA 是通过启动到恢复映像 (R) 来执行的，然后系统分区 (A) 会被覆盖。
• AB 方案：A 和 B 都包含可用于重新刷写其他系统分区的恢复软件，而无需单独的分区来进行恢复。

虽然这些备选分区方案旨在解决在受限设备上提供更多可用磁盘空间的问题，但它们与专注于软件包本身的方式截然不同，从节省空间的角度来看，它们可以被视为相互独立的。不过，锚定软件包还可以满足其他目标，例如减少网络流量，因此，更改分区方案是一种应独立于此提案进行评估的方案。

后续工作

移除了 data/static_packages 文件

我们可能会选择弃用并移除 data/static_packages 文件，并使用更通用且可扩展的 data/anchored_packages 文件包含该文件中列出的软件包。

Notification API

我们可能会在未来选择实现某种形式的通知 API，以便组件可以查询软件包解析状态、下载速度或预计下载完成时间等信息，但这不在本文档的讨论范围之内。

在系统更新软件包中包含软件包内容 blob

根据未来的要求，我们可能会选择在更新软件包中不仅包含软件包的 meta.far 文件，还包含软件包内容 blob。例如，这可能有助于估算自动锚定型软件包和按需锚定型软件包的下载时间。

针对特定工作流的优化

借助软件包集，您或许可以针对特定工作流进行优化。不过，这些优化可能需要额外付费，或者实现起来可能很复杂，尤其是在考虑所有极端情况时。因此，这些注意事项不在本 RFC 的讨论范围内。不过，为了提供背景信息，我们列出了一些可能的优化措施：

• 积极利用按需软件包可使用比指定产品的组合软件包更小的 fxblob/blobfs 存储空间。在这种情况下，按需软件包可能会经常被垃圾回收，并且需要使用的软件包会被重新下载。虽然可能，但需要仔细设计此类产品上的可能工作流，以确保始终有足够的存储空间来容纳任何给定时间使用的所有软件包。
• 您可以在用于刷写的初始 fxblob/blobfs 映像中添加自动或按需锚定的软件包（甚至是其中的大部分），从而无需在初始开箱体验后下载这些软件包。虽然可能，但这会导致初始映像和后续 OTA 之间存在细微差异，并可能导致组装和测试复杂化。

其他开发者工具

通过添加自动或按需锚定软件包，我们有望为开发者提供更多工具。决定要构建哪些工具不在本 RFC 的讨论范围之内，但一些可能的工具包括：

• 报告和美化显示软件包依赖关系图，突出显示对非始终可用软件包的直接依赖项和传递依赖项。
• 模拟通过 ffx repository serve 向开发目标提供软件包时的不理想网络状况，例如网络速度缓慢或连接不稳定问题。

重新审视软件包分发基础架构

根据从采用自动和按需锚定软件包的产品收集的网络指标，负责运营软件包分发基础架构的团队可以获得有助于优化分发基础架构的数据分析，从而缩短下载时间或减少用户延迟时间。例如，预期要解决的问题包括：

• 在云区域中分布软件包工件的存储分区。
• 负载均衡，以最大限度地缩短客户端的访问延迟时间，使用 IP 地理定位等方法确定最近的软件包服务器。
• 在发布较大更新时动态扩缩软件包服务器的实例数量。
• 在发布次要版本和主要版本之前预测预期的负载模式。

在先技术和参考文档

• fuchsia.dev 中的软件包
• “提前软件包更新”RFC
• 子软件包 RFC
• 早期启动软件包 RFC
• 软件包集 RFC