「元件設定」頁面會介紹如何在 Fuchsia 上設定元件，並說明需要設定元件的不同情況。
本頁面將介紹 Fuchsia 提供的各種設定機制，並說明各機制的優缺點，以及在何種情況下使用何種機制。
結構化設定
結構化設定是元件架構提供的現代化、人體工學與彈性設定系統。結構化設定已與許多 Fuchsia 工具整合，包括 ffx、檢查 和產品組合，因此在多數情況下，您應優先選擇。
元件開發人員會在元件的資訊清單中定義設定鍵，每個鍵都會附上名稱和資料類型，以便使用結構化設定。系統保證在元件啟動時，會提供所有設定鍵的值。系統會自動產生程式庫，方便您在執行階段讀取設定值。元件不必關心系統所提供結構化設定值的哪個部分，也不需處理缺少的設定。
結構化設定值可透過一系列不同的路徑提供，例如：
- 套件建構規則。建構規則設定的設定值會與元件一併納入相同的套件中。這項設定在建構時是固定的，因此可在版本簽署期間驗證。
- Realm 建構工具。整合 Realm builder 後，即可輕鬆測試設定值。這兩個主要用途是驗證可設定的行為，以及變更設定以利測試。
- 產品組裝。產品組合可讓平台定義設定鍵，其值由產品提供。產品整合商會在產品設定中提供相關值，且這些值已內建於元件套件中，可在發布簽署期間驗證。
- 開發覆寫值。這個 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 來解決這個問題，但這會破壞以服務為基礎的設定的優點，也就是簡單的用戶端和明確的定義。處理大型設定時，套件式設定是更好的解決方案。