FHO (Fuchsia 主機物件) 是一組程式庫介面，可將 ffx 連結至子工具，無論編譯為 ffx CLI 二進位檔，還是建構樹狀結構或 SDK 中的獨立二進位檔。這個系統的設計相當可以進行快速疊代和回溯相容性，讓以 FHO 建構的二進位檔透過大型版本之間相互通訊。
在 ffx 子工具 (具有 ffx 前置字串的頂層指令執行) 中，FHO 最好將其視為程式與搭載 Fuchsia 的裝置/虛擬機器之間的相容性層，讓工具忽略連線至裝置所需的所有設定、在裝置上建立 FIDL 管道及記錄互動的相關實用資訊。
FHO 主機端 (ffx CLI)
在 FHO 架構中，主機二進位檔 (ffx) 負責探索子工具即將執行的環境重要資訊。這可能包含下列詳細資訊：
- 使用者和專案設定檔及其內容。
- 管理使用中的 Daemon 及其提供的服務。
- 探索目標裝置並建立連線，包括設定預設裝置時更應如此。
- 找出專案和/或 SDK 中的子工具位置。
- 探索 SDK，並確認裝置、SDK 和子工具之間的版本限制。
大多數工具都應建構為外部程序，並透過 SDK 或建構輸出目錄找到，但有些工具仍會建構在 ffx 二進位檔中。這些工具不一定與單獨編譯的工具完全相同，但相容性限制有限。不過，即使沒有 SDK，還是能存取某些工具很有幫助。
本文件的其餘部分主要是關於個別編譯的子工具，以及如何找出和執行這些子工具。
FHO 工具側
在理想情況下，FHO 式子工具只會是專為 Fuchsia 編寫的程式，但在主機上執行，會與用於在裝置上連線至服務的 ffx 主機二進位檔的內容資訊一併執行。
不過，可透過 ffx 執行的工具有特殊的進入點，以便傳達工具正確執行所需的背景資訊。他們也需要提供一些中繼資料，讓 ffx 用來探索、驗證相容性並加以執行。
工具中繼資料
工具通常具有與這些工具相關聯的 JSON 中繼資料檔案，如下所示：
{
"name": "echo",
"description": "run echo test against the daemon",
"requires_fho": 0,
"fho_details": {
"FhoVersion0": {}
}
}
這個 JSON 檔案旨在提供版本管理資訊給 ffx，以及執行 ffx help 或 ffx commands 時將會輸出的資訊。上述檔案是「版本 0」的 FHO 說明，這是子工具介面最少的起始點。
FHO 中繼資料版本
FHO 版本將依序編號。任何指定子工具支援的版本都可以由 requires_fho 鍵範圍到 fho_details 對應中最高值項目結尾的數字範圍。子工具應能做為這兩個值之間的任何版本執行。
在上述範例中，子工具只支援 FHO 版本 0。如果主機工具不支援第 0 版，則必須忽略子工具的執行個體，以便改用在其他位置找到的新版本；如果沒有相符的版本，則系統會發生錯誤。
主機工具應使用 fho_details 中下一個最高 (或等) 的項目，使其高於支援的最高 FHO 版本。舉例來說，假設您針對下列中繼資料執行原生支援的 ffx 版本 3：
{
"name": "echo",
"description": "run echo test against the daemon",
"requires_fho": 0,
"fho_details": {
"FhoVersion2": { "some_thing": "is_something" },
"FhoVersion4": { "some_thing_else": "is_something_else" },
}
}
一般來說，主機工具會從 FhoVersion4 提取中繼資料，並以 FhoVersion3 程式的形式執行程式。
如此一來，就能隨著時間對中繼資料進行漸進式和破壞性變更，同時讓工具本身支援各種版本。只需將漸進式變更新增至目前版本的中繼資料欄位，較舊版本的主機工具會忽略這些變更，而較新的版本將使用這些變更。
當中繼資料需要破壞時，可以同時建立新項目，先前的版本將繼續使用舊版中繼資料結構。
即使 requires_fho 較高，子工具也允許加入 FhoVersion0 區段，並以較簡單的模式直接叫用工具。FhoVersion0 區段不應包含任何金鑰。
您可以在原始碼樹狀結構中找到目前的 FHO 中繼資料 JSON 結構定義。
工具探索
目前系統會在下列位置搜尋子工具：
- FFX 二進位檔本身。
- 專案專屬建構輸出位置。
- 在已設定的 SDK 的中繼資料中。
以路徑為基礎的探索
如果已使用建構輸出目錄或其他位置設定 ffx 來搜尋子工具，它可能會搜尋這些位置，尋找符合以下模式的二進位檔：
/ffx-([-_a-zA-Z0-9]/) 或 ffx-toolname，其中 toolname 是叫用的子指令名稱。請注意，系統不會將進一步的連字號視為更深層的巢狀結構，例如。ffx-some-sub-tool 會以 ffx some-sub-tool 執行，而非 ffx some sub tool。子工具負責自身的巢狀指令層，但 FHO 程式庫本身可能會提供執行這項操作的輔助程式。
這些檔案必須附帶相同名稱和 .json 副檔名後置字串的檔案。這個檔案是前幾節所述的中繼資料，而且當中的詳細資料必須與正在執行的二進位檔相符 (例如，頂層的 name 鍵必須與二進位檔和中繼資料檔案名稱中的 toolname 相同)。
系統不會將符合這個模式的檔案視為子工具，而會忽略這些檔案。
SDK 探索
在 SDK 中，工具會透過中繼資料搜尋探索。SDK 資訊清單會搜尋類型為 ffx_tool 的 atoms，指向中繼資料和可執行二進位檔的 SDK 相對位置。
如要執行子指令，系統會掃描符合 ffx_tool 類型的 SDK 項目，直到找到相符的名稱為止。與以路徑為基礎的搜尋一樣，名稱中的連字號不會建立指令名稱的更深層巢狀結構。
主機工具可將來自 SDK 的主要 ffx host_tool 二進位檔視為沒有子工具的「預設」指令，進而將其推遲為 FHO 版本 0 (基本上會以 FHO 版本的形式叫用子工具，就像僅透過一個子指令叫用 ffx)。
工具介面
如上所述，中繼資料宣告 ffx 二進位檔和正在執行的子工具之間的版本化介面。這麼做的用意是隨著時間推移在這個介面上更加結構，但一開始就比較簡單，以免破壞子工具中現有的任何期望。
如果 FHO 介面支援較在中繼資料中的舊版 FHO 介面，特別是在 ffx 不再支援版本 0 後，子工具可能必須繼續實作 0，視其在建構指令碼等項目中的用途而定。
FHO 版本 0
FHO 第 0 版是最簡易的 FHO 版本。SDK 中不應納入僅支援 0 版的工具，但 SDK 內含的工具可能額外支援版本 0。
FHO 第 0 版子工具的叫用程序非常簡單。系統只會直接使用呼叫 ffx 時指定的引數 (包括對 ffx 本身的所有引數) 執行。也就是說，如果您叫用：
> ffx --isolate-dir "/tmp/blah" echo stuff
在您執行 ffx 二進位檔搜尋相符的 ffx-echo 二進位檔時，如果其最高支援版本為零，將叫用該二進位檔：
> ffx-echo --isolate-dir "/tmp/blah" echo stuff
子工具必須支援所有頂層 ffx 引數，這些引數用於其建構的 ffx 版本。這麼做也會使用環境變數 FFX_BIN_ENV 執行，指向執行時執行的 ffx 頂層叫用檔案系統路徑 (但不應覆寫)，或者可執行這項變數，從執行子工具的相同情境環境重新開始處理作業。
否則，系統會為子項程序提供相同的 (stdin,stdout,stderr) 三元組，以及原始 ffx 叫用執行的環境變數。
為何這是第 0 版介面：
- 這樣做可讓直接叫用建構中的子工具，而無需建構主要
ffx二進位檔，從建構的重要路徑移除不必要的目標。 - 這不會幹擾現有外掛程式，是否預期外掛程式能完全控制正在執行的輸入和輸出環境。
- 因此，這個架構的第一個版本會專注於建構能力中較重要的面向。