RFC-0271：錨定套件

問題陳述

目前，在 Fuchsia 中實作系統更新 (「OTA」) 時，需要同時儲存兩組完整的 Blob。這個方法很簡單，但如果裝置磁碟空間不足，就會造成問題。

摘要

這項 RFC 提案是針對錨定套件的實作方式，最初的說明請見 RFC-212。這些套件組合符合下列不變量：

• 系統更新 (OTA) 時，只會下載永久錨定的套件 (啟動檔案系統、根據 RFC-212 的基礎)。
• 套件和 Blob 會透過 Merkle 雜湊值進行專屬識別。 對於自動錨定和隨選錨定套件，更新套件會包含攜帶這項資訊的 meta.far 封存雜湊。
• 系統套用更新並啟動新版系統後，就會在某個時間點下載自動錨定和隨選錨定套件。
• RFC-212 中定義的自動、可升級和永久、可升級套件集。錨定套件不會將「正確」套件的驗證作業委派給其他方，而急切更新則允許套件獨立於系統 OTA 更新，錨定套件則不允許。

不變量會對錨定套件集產生下列影響：

• 由於所有套件的加密雜湊仍會隨系統更新發布，因此必須執行系統更新，才能將這些套件更新至較新版本。
• 從應用程式的角度來看，套件是透過 OTA 發布還是以錨定套件形式發布，都無關緊要。不過，如果存取的功能是由尚未解析的套件提供，應用程式可能會出現延遲。詳情請參閱「成效」一節。
• 自動錨定套件不會依需求下載，這與工程建構中的 TUF 存放區套件和依需求錨定套件不同。而是在啟動更新後的系統時下載。

自動錨定和隨選錨定套件可避免在裝置的非揮發性儲存空間中，於 OTA 期間將每個套件儲存兩次，因此可提高儲存空間效率，尤其是在儲存空間受限的裝置上。

提振精神

目前，生產 Fuchsia 系統上常用的系統更新機制，會透過三分割區「ABR」架構執行完整更新。A 和 B 兩個分割區各包含一個完整的系統映像檔。R 分區包含最小復原分區，不在本 RFC 的範圍內。

在任何時間點，分割區 A 或 B 其中一個都是有效分割區，也就是說，裝置開機時，開機載入器會將系統開機至有效分割區。目前，對於 user buildtype，裝置上一律會提供套件管理系統所知的軟體。

執行 OTA 時，系統更新程式會在非使用中的 A 或 B 分割區上寫入完整的新系統映像檔。此外，這項作業可確保所有已知 Blob 都下載至 fxblob/blobfs 儲存空間，而 A 和 B 插槽都會共用這個儲存空間。成功完成後，系統會翻轉表示哪個是有效分割區的位元，並重新啟動至新的系統映像檔。這表示在任何時間點，都會有一個完整的系統映像檔佔用空間，但完全不會使用，而且在一段時間內，fxblob/blobfs 必須保留目前執行裝置軟體版本和新版本的 Blob。這樣就能更有效率地使用裝置資源。 RFC-212 定義並大致列出 Fuchsia 套件管理系統擴充功能的命名和概念，以減少系統映像檔的占用空間。方法是允許從系統映像檔排除套件，並在系統更新後下載至 fxblob/blobfs 儲存空間。這樣一來，新舊版本的套件就不會同時佔用 fxblob/blobfs 的空間。

支援錨定套件的另一個動機，是希望盡量減少不必要的網路流量。如果 Fuchsia 系統的大部分使用者完全不會使用特定軟體元件，則將這些元件排除在 OTA 之外，並僅在需要時下載，可能大幅減少資料傳輸量，進而降低伺服器和網路的容量需求。

定義

以下是根據 RFC-212 定義的適用術語和定義：Base、Bootfs 套件、快取、Eager update、垃圾收集、套件、套件集、套件版本、父項套件、永久套件、產品、產品建構、產品發布、子套件、系統更新、Universe、版本管理機構。

利害關係人

講師：

jamesr@google.com

審查者：

• etryzelaar@google.com (SWD)
• amituttam@google.com (PM)
• awolter@google.com (軟體組裝)
• markdittmer@google.com (安全性)
• gtsai@google.com (基礎架構)

社交：

軟體交付團隊內部進行了一系列設計討論，並討論了這項 RFC。本 RFC 的早期版本已由軟體交付、建構和組裝團隊的利害關係人，以及潛在客戶審查。

需求條件

• 錨定套件的傳送機制不得需要額外服務或基礎架構，也就是說，將系統更新 (OTA) 傳送至目標裝置的機制，也適用於錨定套件。
• 您必須手動指定哪些套件屬於哪些錨定套件集。根據這項 RFC，我們不會實作任何機制，嘗試自動判斷哪些套件可能屬於哪些套件集。
• 實作範圍受限於 RFC-212 定義的限制，如下圖所示。具體來說，自動或隨選錨定套件不支援下列情境：
  • 支援版本控管的委派作業。
  • 支援產品開箱即用體驗 (OOBE) 工作流程所需的套件。
  • 也就是說，如果 OOBE 必備的套件標示為自動或隨選錨定套件，套件管理堆疊就無法保證在需要時，所有 OOBE 工作流程所需的套件都能正常運作。這是因為在許多情況下，OOBE 工作流程包含設定網路。因此，系統無法保證在 OOBE 完成前，自動和隨選錨定套件可解析。

設計

錨定套件集

套件集是一組套件，所有套件都使用相同的策略傳送及更新。生產裝置中最常使用的套件集是永久 (基礎和 bootfs) 集，這些套件集的主要特徵是永遠可用，且由產品定義設定：

• 描述套件的 Merkle 雜湊，確保套件完整性。
• 以及套件本身

會在 OTA 更新程序中下載，然後重新啟動至更新後的產品版本。因此，加上 Fuchsia 的預設 ABR 分割配置 (A 和 B 分割區都包含可完整啟動的系統)，基本套件的封裝可能會在 fxblob/blobfs 中儲存兩次：如果兩者不同，則 A 分割區中產品的一個版本會儲存在商店中，B 分割區中產品的一個版本也會儲存在商店中。在執行中的系統中，基本套件組的套件清單會反映在基本套件的 data/static_packages 檔案中。在套件解析過程中，這些套件會由 基礎解析器 (pkg-cache 的一部分) 解析。換句話說，這些要求會在本地解析，不需要網路連線。

自動和隨選 錨定套件集與啟動檔案系統和基本集有一些共同特徵，但從根本上來說有所不同：

• 與基本套件相同，描述錨定套件的 Merkle 雜湊會在重新啟動至新系統版本前，下載至預期系統分割區。
• 與基礎和啟動檔案系統套件不同，在重新啟動至新系統之前，Blob 本身不會下載至 fxblob/blobfs。

這樣一來，由於系統可避免在非揮發性儲存空間中保留多個版本的套件，因此可針對儲存空間大小最佳化 OTA 更新的下載階段。詳情請參閱下方的「Boot sequence with automatic anchored packages」(使用自動錨定套件的開機順序)。

自動和隨選 錨定套件的差異在於觸發套件解析器擷取套件的原因：

• 只要有任何具備權限的合格元件，在執行中的 Fuchsia 系統上查詢解析器，要求解析套件，系統就會擷取隨選錨定套件。
• 在執行 OTA 後重新啟動至新的 Fuchsia 系統後，系統會盡快解析自動錨定套件。

錨定套件的垃圾收集

這項 RFC 建議，在未來可能修訂垃圾收集演算法之前，應適用下列錨定套件收集規則：

• 自動錨定套件下載至 fxblob/blobfs 後，會受到垃圾收集機制保護，直到下次重新啟動至較新系統為止。
• 只有在系統版本 (因此 Merkle 雜湊) 變更，且不再屬於當時執行的系統版本時，自動錨定套件才會進行垃圾收集。
• 隨選錨定套件不會受到垃圾收集的額外保護，且會遵循 RFC-217 中有關開放套件追蹤的規則。

解決隨選錨定套件的問題

套件解析器已具備下載套件的功能，並可視需要將套件提供給執行中的系統。因此，使用這項功能處理隨選錨定套件非常簡單：只要系統上沒有套件，套件解析器就會下載 Blob，並透過 fxblob/blobfs 驗證及提供 Blob。

一律可用的套件組合與自動/隨選 錨定套件的主要差異在於，後兩者需要網路連線才能解析。

從執行系統的角度來看，隨選錨定套裝組合不必明確標示為此類套裝組合。要求套件時，解析器只會注意到套件快取中沒有 Blob，並啟動下載程序。

不過，開發人員可以決定是否將套件納入產品做為隨選錨定套件，且必須在產品定義中標示：

• Fuchsia 產品定義會接受 on_demand_anchored 套件清單。
• ffx assembly product 工具會將清單發送至圖片組裝設定。

產品組裝期間：

• 套件 (二進位大型物件和資訊清單) 會納入主要產品套件。
• 這些 Blob 不會納入用於刷寫裝置的 fxblob/blobfs。
• 隨選錨定集中的套件清單建構方式與基本套件類似。這份清單會是 AssemblyManifest 的一部分，並納入更新套件。執行中的 Fuchsia 系統會在基礎套件的 data/anchored_packages 檔案中，找到這組套件的清單。

解析自動錨定套件

與隨選錨定套件相同，開發人員可決定是否要將套件納入產品做為自動錨定套件，且必須在產品定義中標記：

• Fuchsia 產品定義會接受 automatic_anchored 套件清單。
• ffx assembly product 工具會將清單發送至圖片組裝設定。

產品組裝期間：

• 套件 (二進位大型物件和資訊清單) 會納入主要產品套件。
• 這些 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) 可能是第一批採用某種形式的可用性報告和監控的元件。這樣才能進一步瞭解需求、差距和日後需要解決的必要變更。複雜的應用實例 (例如與互動式 UI 互動、向使用者回報進度，以及類似情況) 不屬於這組初始應用實例的範圍。

實作

實作作業將分為多個階段，以便參與團隊之間同步處理，並在為 Fuchsia 產品啟用這項功能前，先驗證功能。

第一階段將在套件解析器和套件快取中實作純功能，這需要：

• SWD
  • 支援在啟動時從基本套件的 data/anchored_packages 取得自動錨定套件清單，並提供自動錨定套件的 Blob。
• 建構、組裝
  • 支援在產品建構期間處理所需自動和隨選錨定套件清單，並為圖片提供 data/anchored_packages。
  • 更新大小檢查工具，支援錨定套件並正確反映建構和圖片大小。
• 安全性
  • 技術審查解析自動和隨選錨定套件的網際網路面向程式碼路徑。

第二階段將準備為 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. 在執行階段，以 Fuchsia 為基礎的產品會使用 fxblob/blobfs 提供的套件。我們預期這個領域的執行階段效能不會有明顯變化，因為就錨定集已解析的套件而言，無論是套件快取提供的套件，還是執行的套件，都與基本套件沒有差異。

2. 在執行階段，以套件管理服務已知但尚未下載的套件為基礎，評估 Fuchsia 產品的效能。就 CPU 和記憶體用量而言，封裝組合解析度 (下載、驗證) 對 Fuchsia 產品整體效能的影響應該不大。不過，如果產品使用者想執行的功能需要下載套件，可能會受到影響。在這種情況下，使用者體驗會受到一定程度的影響，具體程度取決於下載速度。這類問題主要取決於使用者網際網路連線的速度和延遲時間，因此不在本 RFC 的討論範圍內。請注意，視下載的套件而定，裝置上的應用程式仍可向使用者說明情況，例如傳達「必要下載作業仍在進行中」的訊息。從使用者體驗的角度來看，這比裝置顯示沒有回應或處於不明狀態更理想。

3. 如果產品使用自動錨定套件，OTA 程序總時間就會有所不同。我們預期「系統更新套件下載作業已開始」和「新版本正在執行」之間的平均時間會縮短，而「系統更新套件下載作業已開始」和「所有套件都已解決」之間的平均時間則會增加。如先前有關解決 fxblob/blobfs 尚未提供的套件的項目所述，建議軟體依附於非永久套件時，應準備好管理使用者的期望。對於某些類型的裝置，這項時間長度的變更可能不會造成太大問題，例如在夜間無人使用時定期更新的裝置。

4. 與以單一無線更新 (OTA) 形式發布更新的產品相比，為採用自動或隨選錨定套件的產品提供服務時，套件服務基礎架構最有可能會遇到不同的負載模式。這取決於多項因素，例如：裝置在收到更新套件後重新啟動的時間 (適用於自動錨定套件)，或是使用者首次要求使用特定功能的時間 (適用於隨選錨定套件)。但其他因素 (例如地理位置，以及使用者是否採用特定功能) 也會導致套件服務基礎架構的負載，與僅提供靜態套件的產品不同。「未來工作」一節將討論這方面的內容。

5. 基於上述幾點，建議您針對 (i) 更新套件的下載和安裝時間，以及 (ii) 首次重新啟動至新版本後，自動錨定套件的解決時間，設定相關指標。這樣一來，就能更瞭解系統更新成功後，使用者體驗受到網路連線不穩或下載速度緩慢影響的頻率。

基準

使用錨定套件的產品可能會出現使用者可見活動的差異。因此，建議您定期收集這類產品的額外基準，確保使用者體驗不會倒退，並在基準顯示下列情況時採取因應措施：

• 在特定網路條件 (上傳 / 下載速度、延遲、封包遺失等) 下，特定產品的一組自動和隨選錨定套件達到解決方案的時間。
• 在各種網路條件下，錨定套件解析嘗試失敗的頻率。
• 使用者要求依附於尚未解決套件的功能時，Fuchsia 產品的頻率。

這些指標旨在提供資料，協助您合理判斷特定套件是否可移出基本集，或是否應將錨定套件移回基本集。

人體工學

工程工作流程

工程工作流程大致與目前使用工程建構版本時相同，套件會從存放區伺服器動態提供，並提供 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

這份 RFC 刻意不納入通知 API，但我們可能會在日後實作某種形式的通知 API，讓元件查詢套件解析狀態、下載速度或預估下載完成時間等資訊。

在系統更新套件中納入套件內容 Blob

視日後需求而定，我們可能會選擇在更新套件中加入套件的 meta.far 檔案，以及套件內容 Blob。舉例來說，這項資訊可用於估算自動和隨選錨定套件的下載時間。

針對特定工作流程進行最佳化

使用套件集時，可針對特定工作流程進行最佳化。不過，這些最佳化措施可能會產生額外費用，或實作起來相當複雜，尤其是考慮所有極端情況時。因此，這些考量因素不在本 RFC 的討論範圍內。但為了提供背景資訊，以下列出一些可能的最佳化做法：

• 積極運用隨選套件，可使用比定義產品的合併套件組更小的 fxblob/blobfs 儲存空間。在這種情況下，隨選套件可能會經常遭到垃圾收集，並重新下載需要使用的套件。雖然可行，但必須仔細設計這類產品的可能工作流程，確保隨時都有足夠的儲存空間來存放所有使用的套件。
• 您可以在用於刷機的初始 fxblob/blobfs 映像檔中，加入自動或甚至 (大部分) 的隨選錨定套件，因此在初始開箱體驗後，就不需要下載這些套件。雖然可行，但這會在初始映像檔和後續 OTA 之間產生細微差異，可能導致組裝和測試複雜化。

其他開發人員工具

加入自動或隨選錨定套件後，開發人員可望獲得更多工具支援。本 RFC 不會決定要建構哪些工具，但以下是一些可能的工具：

• 回報並美化列印套件依附元件圖表，醒目顯示直接和轉換依附元件，以利套件不一定可用。
• 透過 ffx repository serve 將套件提供給開發目標時，模擬非完美網路狀況，例如網路速度緩慢或連線問題間歇發生。

重新檢視套件服務基礎架構

團隊可根據從採用自動和隨選錨定套件的產品收集到的網路指標，取得洞察資料，進而最佳化套件服務基礎架構，縮短使用者的下載時間或延遲時間。預期方面包括：

• 將套件構件的儲存空間 bucket 分散至各個雲端區域。
• 負載平衡，盡量縮短用戶端的存取延遲時間，例如使用 IP 地理位置判斷最接近的套件伺服器。
• 在推出大型更新時，動態調整套件伺服器執行個體數量。
• 在次要和主要版本發布前，預期負載模式。

先前技術和參考資料

• fuchsia.dev 中的套件
• Eager 套件 updates RFC
• 子檔案包 RFC
• 早期啟動套件 RFC
• 套裝組合 RFC