元件設定頁面介紹如何在 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 實驗和強制執行企業政策，類似於其他大型平台中的實驗系統。
元件的結構化設定定義僅適用於該元件。沒有全域「設定版本」，系統也不保證元件版本之間的前瞻或回溯相容性，相容性由元件開發人員決定。因此，如果元件可能是根據不同設定版本建構，目前不適合使用結構化設定做為元件之間的通訊方式。
結構化設定非常靈活，適用於大多數情況，但有些設定問題不適合使用結構化設定：
- 設定值必須在大量不同的元件中保持一致。結構化設定金鑰是在元件的資訊清單中本機定義。產品組件可用於在幾個不同元件之間設定一致的設定值，但這會帶來維護性挑戰，且無法妥善擴充。如果設定值必須在大量不同元件之間保持一致，以套件為基礎的設定或以服務為基礎的設定是更好的解決方案。
- 大型設定。當設定變得非常大 (例如超過幾 KB) 時，結構化設定提供的設定和查看設定值工具就會變得不方便。結構化設定的實作方式不會優先處理大型值。以套件為基礎的設定是大型設定資料的較佳解決方案。
- 在執行階段頻繁變更的設定。元件會在啟動時接收結構化設定值，也就是說，必須重新啟動元件執行個體，才能套用新設定。如果設定必須在執行階段頻繁變更，服務式設定是更好的解決方案。
- 由使用者設定。與開發人員不同，使用者需要使用者介面來控制設定。這個使用者介面代表 UI 元件、設定中的元件和本地化資料庫，都必須同意設定的定義，因此設定必須集中定義在某個版本化構件中。服務型設定是較佳的解決方案，可讓使用者控管設定。
以套件為基礎的設定
套件式設定支援在發布時固定的設定資料，方法是將資料檔案建構至 同一個套件可以轉送至多個不同的元件，且設定檔的大小不受限制。
套件設定通常不如結構化設定符合人體工學；檔案必須手動開啟和剖析，元件可能需要處理遺失或格式錯誤的設定，且無法與標準工具整合，以測試、偵錯或檢查設定。
套件設定不適用於下列問題：
- 需要在執行階段變更設定。請在上述追蹤錯誤中留言，要求在結構化設定中支援動態設定，和/或改用服務式設定。
套件式設定有三種不同變化版本，取決於用於儲存設定的套件：
全域 (又稱「config_data」) 套件設定
單一全域 config_data 套件包含許多不同元件的設定資料。每個元件的資料都是使用「config_data」建構規則新增。這個全域套件是 CFv1 中使用套件式設定的唯一方式，但在 CFv2 中，由於必須透過元件拓撲手動轉送 config-資料目錄，因此不靈活且繁瑣。
config_data 的使用者應遷移至結構化設定或網域/套件內設定，這兩者都提供更佳的人體工學和更多彈性。
網域套件設定
網域中元件的開發人員可以定義自己的設定資料套件，並將其目錄轉送至他們控制的元件。與全域套件設定不同，這項機制可用於不同的建構系統和花瓣。
套件內設定
設定檔也可以放在與所設定元件相同的套件中。這樣一來，設定就會與元件一起發布，不需要複雜且不穩定的轉送。不過，這也表示如果不重新封裝元件，就無法變更設定。詳情請參閱為元件提供資料檔案指南。
套件內容會儲存在 blobfs 中，這是一種內容定址檔案系統，可刪除重複的 blob。也就是說，如果多個套件包含相同的設定 blob，系統只會儲存一份。
服務設定
Fuchsia 元件可編寫為透過 FIDL 收集、維護及發布網域的設定資料。Fuchsia 平台的設定服務就是一個很好的例子，該服務會維護各種使用者設定，例如語言代碼：設定服務會在電源週期內維護這些使用者設定的狀態，並公開 fuchsia.settings FIDL 通訊協定，其他元件可能會使用這些通訊協定讀取目前的設定資料，或要求變更設定資料。
服務式設定非常靈活且強大，但導入伺服器元件通常比其他選項更費工，且執行階段成本較高。只有在額外費用能帶來附加價值時，才應使用服務型設定。
元件可能會使用多種不同的輸入內容，判斷正確的設定。例如：驗證及合併用戶端要求的商業邏輯、從某些伺服器收集的設定，或透過其他機制 (例如結構化設定) 提供的預設設定值。如果必須在多個用戶端之間共用設定，服務式設定會是很好的選擇，因為設定是由用於傳送設定的 FIDL 介面正式定義和版本化。如果設定可能經常變更，服務式設定也相當適用。
服務式設定不適用於下列問題：
- 大型設定。設定會透過 FIDL 訊息傳送，而訊息大小受限於 Zircon 管道寫入的大小。雖然 FIDL 通訊協定可以將設定分割成多個區塊，或傳送 VMO 來解決這個問題，但這會破壞用戶端的簡易性和明確定義，而這正是服務式設定的優勢。處理大型設定時，套件式設定是較佳的解決方案。