「元件設定」頁面會介紹如何在 Fuchsia 上設定元件，並說明需要設定元件的不同情況。
本頁面將介紹 Fuchsia 提供的各種設定機制，並說明各機制的優缺點，以及在何種情況下使用何種機制。
結構化設定
結構化設定是元件架構提供的現代化、符合人體工學且靈活的設定系統。結構化設定已整合許多 Fuchsia 工具，包括 ffx、inspect 和產品組合，因此在大多數情況下，這應是您的首選。
元件開發人員會在元件的資訊清單中定義設定鍵，每個鍵都會附上名稱和資料類型，以便使用結構化設定。系統會保證，在元件啟動時，會為所有這些設定鍵提供值。系統會自動產生程式庫，方便您在執行階段讀取設定值。元件不需要關心系統的哪個部分提供結構化設定值，也不需要處理缺少的設定。
結構化設定值可透過一系列不同的路徑提供，例如：
- 套件建構規則。建構規則設定的設定值會與元件一併納入相同的套件中。設定會在建構期間固定，因此可在發布簽署期間驗證。
- Realm 建構工具。Realm 建構工具整合功能可讓測試輕鬆設定設定值。這兩個主要用途是驗證可設定的行為，以及變更設定以利測試。
- 產品組裝。產品組合可讓平台定義設定鍵，其值由產品提供。產品整合服務供應商會在產品設定中提供值，這些值會建構至元件套件中，以便在發布簽署期間進行驗證。
- 開發人員覆寫值。這個 ffx 工具可讓開發人員在工程版本的執行階段變更設定，例如使用預先發布功能。
RFC-0127 說明瞭幾種其他方法，可用來指定結構化設定值，但這些方法尚未建構，因為我們正在等待近期的使用案例。如果您的用途需要任何這些功能，請針對下方連結的追蹤錯誤提供意見，以便我們為該功能提供支援：
- Vbmeta (https://fxbug.dev/42178359)。這樣一來，您就可以修改已簽署的設定，以便發布，而無須建構新的映像檔。
- 父項元件 (https://fxbug.dev/42178351)。這樣一來，元件在建立動態集合中的子項時，就能為這些子項指定設定。這項功能需要在兩個元件之間定義一致的設定，因此只能支援相同映像檔或套件中的元件。
- 車隊和企業管理 (https://fxbug.dev/42055769)。這可讓結構化設定用於逐步推出、執行 A/B 實驗和企業政策強制執行，類似於其他大型平台的實驗系統。
元件的結構化設定定義是該元件本機的設定。系統沒有全域「設定版本」，也不會保證元件各版本之間的前向或向後相容性，相容性由元件開發人員自行負責。因此，結構化設定目前不適合用於在可能已根據不同設定版本建構的元件之間進行通訊。
結構化設定非常靈活，可在大多數情況下運作，但有些設定問題不適用結構化設定，因此不是最佳解決方案：
- 設定值必須在大量不同元件中保持一致。結構化設定鍵是在元件的資訊清單中定義。產品組合可用於在幾個不同的元件中設定一致的設定值，但這會帶來維護上的困難，且無法順利擴充。如果設定值必須在大量不同元件中保持一致，則以套件為準的設定或以服務為準的設定會是較佳的解決方案。
- 大型設定。當設定變得非常大 (超過幾千位元) 時，結構化設定提供的設定值設定和檢視工具就會變得相當不方便。結構化設定的實作方式不會優先處理大型值。以套件為基礎的設定是處理大量設定資料的更佳解決方案。
- 在執行階段經常變更的設定。元件會在啟動時接收結構化設定值，這表示必須重新啟動元件執行個體才能接收新設定。如果設定必須在執行階段經常變更，以服務為基礎的設定會是更合適的解決方案。
- 由使用者設定的設定。與開發人員不同，使用者需要使用者介面來控制設定。這個使用者介面表示 UI 元件、要設定的元件和本地化資料庫都必須同意設定定義，因此設定必須在某個有版本控制的構件中集中定義。如果設定是由使用者控制，以服務為基礎的設定會是更適合的解決方案。
以套件為基礎的設定
套件設定可透過建構資料檔案至 同一個套件可導向至多個不同的元件，且設定檔可任意調整大小。
以套件為基礎的設定通常不如結構化設定那麼符合人體工學；檔案必須手動開啟及剖析，元件可能需要處理遺漏或格式錯誤的設定，而且不會整合標準工具來測試、偵錯或檢視設定。
以套件為基礎的設定無法有效解決下列問題：
- 需要在執行階段變更設定。請在上述追蹤錯誤中加上註解，以便在結構化設定中支援動態設定，並/或改用以服務為基礎的設定。
根據用於儲存設定的套件，有三種不同的套件設定：
全域 (又稱「config_data」) 套件設定
單一全域 config_data 套件包含許多不同元件的設定資料。使用「config_data」建構規則新增每個元件的資料。這個全域套件是使用 CFv1 中以套件為基礎的設定的唯一方法，但在 CFv2 中，由於必須透過元件拓樸手動路由設定資料目錄，因此這種做法在 CFv2 中不夠靈活，也相當麻煩。
config_data 使用者應遷移至結構化設定或網域/內建設定，這兩種設定都能提供更符合人體工學的彈性。
網域套件設定
網域中元件的開發人員可以定義自己的設定資料套件，並將其目錄導向所控管的元件。與全域套件設定不同，這個機制可用於不同的建構系統和花瓣。
套件內設定
設定檔也可以與所設定元件放置在同一套件中。這可確保設定會隨元件分發，且不需要複雜且不穩定的路由。不過，這也表示如果未重新包裝元件，就無法變更設定。如需更多詳細資訊，請參閱為元件提供資料檔案指南。
套件內容會儲存在 blobfs 中，這是一個內容位址檔案系統，可移除重複的 blob。也就是說，如果多個套件包含相同的設定 Blob，系統只會儲存一個副本。
以服務為基礎的設定
您可以編寫 Fuchsia 元件，透過 FIDL 收集、維護及發布網域的設定資料。一個很好的例子是 Fuchsia 平台的設定服務，可維護各種使用者設定，例如語言代碼：設定服務會在各個電源週期中維護這些使用者設定的狀態，並公開 fuchsia.settings FIDL 通訊協定，其他元件可使用這些通訊協定讀取目前的設定資料，或要求變更設定資料。
以服務為基礎的設定雖然非常靈活且功能強大，但引入伺服器元件通常比其他選項需要更多工作，且會產生較高的執行階段成本。只有在額外費用可帶來價值時，才應使用以服務為基礎的設定。
元件可能會使用多個不同的輸入內容，判斷正確的設定。例如：用於驗證及結合用戶端要求的商業邏輯、從某些伺服器收集的設定，或是透過其他機制 (例如結構化設定) 提供的預設設定值。當設定必須在廣泛的用戶端之間共用時，以服務為基礎的設定就非常實用，因為系統會使用用於提供設定的 FIDL 介面，正式定義並為設定建立版本。在設定可能經常變更的情況下，以服務為基礎的設定也能發揮良好的效果。
服務型設定無法有效解決下列問題：
- 大型設定。配置會透過 FIDL 訊息傳送，而這些訊息受到 zircon 管道寫入大小的限制。雖然 FIDL 通訊協定可以透過將設定分割成多個區塊或傳送 VMO 來解決這個問題，但這會破壞以服務為基礎的設定的優點，也就是簡單的用戶端和明確的定義。處理大型設定時，以套件為基礎的設定是較佳的解決方案。