本頁面由 Cloud Translation API 翻譯而成。

RFC-0144：大小檢查工具

RFC-0144：大小檢查工具
狀態	已接受
區域	開發人員
說明	提議重新編寫 size_checker.go，以建立更一致的樹狀結構內樹狀結構和樹狀結構外開發人員體驗。
問題	85371
變更	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

編輯此 RFC

編輯 RFC 中繼資料

摘要

本文件建議開發即將新增至 SDK 的全新大小檢查工具，方便開發人員和產品擁有者確認套件和產品並未超過指定的大小預算。雖然我們刻意排除實作詳細資料，但由於樹狀結構外組合會持續改變基礎，同時說明設計需求和目標。

提振精神

在軟體開發期間，建議您先瞭解軟體是否符合目標的大小限制。Fuchsia 具備大小檢查工具，可分析不同軟體群組耗用的空間，並為每個群組強制執行預算。這項工具與 fuchsia.git 的實作詳細資料密切相關，因此如果沒有 fuchsia.git 結帳功能，就無法使用這項工具。因此，如 Chromium 等 Fuchsia 的使用者，自己特別實作了自己的專屬方法來檢查軟體大小。將大小檢查工具重新編寫為 ffx 外掛程式，並將其新增至 Fuchsia SDK，藉此在 Fuchsia 軟體上強制執行大小預算的方法，讓未來的開發人員能夠更輕鬆地開始使用 Fuchsia。

背景

本 RFC 假設您瞭解下列主題。

兩種尺寸檢查口味

大小檢查可分為兩類：

刷新時圖片不會超過目標分區大小。
Blob 會在更新期間計入 FVM 預算範圍內。

閃爍：開發人員可將新圖片刷新至 Fuchsia 目標。刷新映像檔時，分區的內容會完全替換為新映像檔的位元組。為確保刷新成功，新映像檔不得大於分區的大小。

更新：Fuksia 目標可能需要無線更新。為確保更新成功，blob 耗用的總空間不得超過 FVM 設定的預算上限。通常，FVM 中的空間會預留給 UpdatePackage 和其他 blob，這表示這項工具無法直接填滿 FVM，然後再檢查最終圖片是否與分區相符。

目前的工具

Fuchsia 提供兩項工具協助完成尺寸檢查：

size_checker.go
blobfs 壓縮

`size_checker.go`

來源連結

這項工具可用於樹狀結構內 (在 fuchsia.git 內)，確保 blob 能在預算範圍內。size_checker.go 會判斷 Fuchsia 存放區中 blob 壓縮和對齊的大小，藉此執行上述操作。預算可依產品定義，但目前不適用於 fuchsia.git 中的任何產品。這項工具會特別檢查 fuchsia.git 中的目錄，因此如果未進行 fuchsia.git 結帳，就無法使用這項工具。

首先，Fuchsia 建構會產生 blobs.json 檔案，其中會列出 blobf 中每個 blob 壓縮和對齊的大小，以及列出這些 blob 的 Merkle 和來源路徑的 blob.manifest 檔案。

接下來，size_checker.go 會執行並執行下列操作：

讀取 blobs.json 以收集每個 blob 的壓縮大小：compressed_size。
讀取 blob.manifest 以收集所有套件。
計算套件中包含 blob 的次數：share_count。
計算每個 blob 的共用大小：shared_size = compressed_size / share_count。由於多筆預算可能包含同一個 blob，因此我們使用 blob 的 shared_size，將大小用量平均分配給各預算。
將每個 blob 的 shared_size 新增至 blob 路徑中的節點，建構一個 Nary 總和樹狀結構，代表建構輸出內容中的每個目錄耗用的空間。
逐一疊代每個預算，並斷言目錄的預算大小大於耗用的空間。
疊代預算中的每個非 blobfs 套件，使用 blobfs-compression 計算 blob 大小的總和，並斷言它在預算範圍內。
列印結果。

加總樹

`blobfs-compression`

來源連結

這項工具可以估算一組 blob 的壓縮和對齊大小，但並非 100% 準確，且有時可能會高估 blob 的大小。工具絕不會低估 blob 的大小。

blobfs-compression 會透過 Fuchsia SDK 傳送至用戶端，目前只有 fuchsia.git 之外為 Fuchsia 建構的程式碼大小是唯一可行的方法。Chromium 是這項工具的用戶端。

現有工具相關問題

用於檢查套件大小的內階和極端方法。
這兩種工具都無法直接檢查圖片大小，以確保閃爍。
size_checker.go
- 未記錄。
- 視 Fuchsia 版本的實作詳細資料而定，這並非穩定版合約。
- 無法使用樹狀結構外。
blobfs-compression
- 不保證會傳回正確的 blob 壓縮大小。
- 在 blob 層級執行，效果不如在套件層級運作。開發人員可依個別套件將軟體新增至產品。
- 因為沒有標準輸出格式，所以不易編寫指令碼，自動化使用也很脆弱。

設計

一致的開發人員體驗

系統將在 Rust 中編寫新的 ffx 外掛程式，並執行兩種大小檢查。如 CLI Rubric 所述，建議將其整合至 ffx 以鼓勵共用工作流程，並提高曝光度。此外，Google 不會開發新的檔案格式，並優先擴充現有的檔案格式。

可編寫指令碼

這項工具主要用於建構系統，因此輸出內容應可進行剖析。輸出格式可能會使用 json5 做為輸出格式，但隨著 Assembly 專案的進展，可能會考慮替代格式。

圖片大小

圖片大小檢查工具應與建構 Flash 資訊清單時同時執行，也就是組合的圖片會對應至分區。目前 Flash 資訊清單建立作業是在 Fuchsia 建構系統中完成，因此 ffx 外掛程式會透過 GN 動作叫用。未來，Google 可能會提供用於建構 Flash 資訊清單的 SDK 工具；而做為 ffx 外掛程式的系統，大小檢查工具應能在該情況下順暢運作。

只要開啟檔案並在中繼資料讀取長度，就能輕鬆測量圖片大小。這適用於任何未壓縮或稀疏的映像檔。這個方法不適用於「稀疏 FVM」，且目前還沒有程式庫來計算稀疏 FVM 的展開大小，因此工具會忽略稀疏 FVM 的大小檢查。

套件大小

Blob 和套件大小檢查應與 Assembly 密切整合，因為在組合期間，工程師會將套件分組，並結合這些組合以指定產品。

大小檢查工具會使用 blobs.json 檔案列出每個 blob 的壓縮及對齊大小。開發人員可以為工具提供多個 blobs.json 檔案做為輸入。如果在提供的 blobs.json 檔案中找不到套件的 blob，大小檢查工具就會使用 blobfs 工具產生一個額外的 blobs.json 圖片，供所有遺漏的 blob 產生。大小檢查工具會讀取產生的 blobs.json，以取得缺少的 blob 大小。

與現有的 size_checker.go 工具類似，新的大小檢查工具會將大小除以使用該 blob 的套件數量，藉此計算每個 blob 的共用大小。這個共用大小是預算設定時使用的共用大小。

實作

這項工具的實作和整合程序將在數個階段中完成。

宣告套件組合的預算。請參閱下方的說明。
編寫 ffx 外掛程式，確保套件集不超過預算
確保 ffx 外掛程式的輸出內容與建構系統中前一個工具的輸出內容相符。如果輸出不同，建構應該會失敗。請參閱下方的說明。
宣告圖片的預算
新增功能，確保圖片大小不超過預算
停用 size_checker.go 並設定新的 ffx 外掛程式載入方位
刪除 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,
    },
]

當新的大小檢查工具為建構載入完成時，系統會在存放區中檢查產生的預算檔案，並刪除產生的程式碼。

輸出比較

在轉換至新的大小檢查工具時，建構系統會斷言新工具的輸出內容與新工具的相符。因此將編寫指令碼來剖析這兩項工具的輸出內容，並確保每個套件群組 (或目錄) 的預算和計算的用量相等。為了和兩種輸出格式建立關聯，指令碼會假設用來識別套件組合的名稱。由於舊工具和新工具都是以相同的基礎機制計算 blob 大小 (使用 blobfs)，因此計算的使用量也相同。

效能

大小檢查工具適用於建構系統，因此相較於網路堆疊，大小檢查工具對效能不穩定的容忍度較高。另一方面，縮短建構時間對於開發人員工作效率至關重要。此外，這項工具位於建構作業的關鍵路徑，因為這項工具必須等待所有套件建構完畢，且映像檔必須經過組合才能開始執行，因此無法平行執行。

目前的 size_checker.go 工具需要約 1 至 2 秒才能執行，而新工具的建議持續時間應相近。

人體工學

請參閱「設計」一節。

回溯相容性

這項設計不一定要與回溯相容。

安全性考量

此設計不會對安全性造成任何影響。

隱私權注意事項

這項設計不會對隱私權造成任何影響。

測試

在 Fuchsia 版本中，新的大小檢查工具將與 size_checker.go 一起執行，並會比較輸出內容，確保兩者的預算和計算的儲存空間使用量相同。

單元測試也會做為功能新增至工具後寫入的。

說明文件

說明文件會新增至 fuchsia.dev。

缺點、替代方案和未知

還有幾種不理想的替代方案。

不採取任何行動：這會要求客戶自行建立臨時方法來完成大小檢查，但這種做法無法隨著用戶端數量增加而擴充。

重構現有工具：size_checker.go 可以重構為支援樹狀結構外的支援。根據 CLI Rubric，偏好的做法是將公開工具新增至 ffx，以鼓勵共用工作流程並提升探索品質。此外，重構目前程式碼所需的變更過於嚴苛，因此實際上重寫工具的工作較少。

使用 blobfs-compression：如要計算每個 blob 的壓縮和對齊大小，您可以使用 blobfs-compression 工具，而非產生新的 blobfs 圖片。這個替代方案有主要的缺點，blobfs-compression 工具不保證的壓縮或對齊方式正確無誤。為了具體明確，blobfs-compression 工具會假設是非密集棉樹，這通常會導致 blob 大小比真實性更大。此外，blobfs-compression 工具一次只能測量一個 blob，因此較難使用，而且可能比執行 blobfs 工具慢一次。產生 blobfs 映像檔比目前的 size_checker.go 更加內嵌，而且更準確。

先前的圖片和參考資料

請參閱「背景」一節。