本頁面介紹 Fuchsia 提供的不同設定機制，說明其優點和弱點，並提供相關指引，協助您瞭解在什麼情況下該採用何種機制。
結構化設定
「結構化設定」是由元件架構提供的現代、人體工學和彈性設定系統。結構化設定已與許多 Fuchsia 工具整合，包括 ffx、inspect和產品組合，因此在多數情況下，這是您優先選擇的設定。
元件開發人員使用結構化設定的方式，是在元件的資訊清單中定義設定金鑰，每個金鑰都有名稱和資料類型。系統可以確保在元件啟動時，系統會為所有這些設定鍵提供值。程式庫會自動產生，以便在執行階段輕鬆讀取設定值。元件不需要處理系統的哪個部分提供結構化設定值，也不需處理遺漏的設定。
您可以透過不同路徑的範圍提供結構化設定值，例如：
- 套件建構規則。由建構規則設定的設定值會納入與元件相同的套件中。設定會在建構期間修正，因此可在版本簽署期間進行驗證。
- 領域建構工具。與 Realm builder 相互整合，測試您就能輕鬆設定設定值。兩種主要用途是驗證可設定的行為，以及變更設定以協助測試。
- 產品組合。產品組合可讓平台定義設定鍵，其值由產品提供。產品整合商會在產品設定中提供值，而這些值包含在元件套件中，可在版本簽署期間進行驗證。
RFC-0127 說明指定結構化設定值的其他方式，但這些方法尚未在近期建立的情況下使用。如果您的用途需要上述任何功能，請對下方連結的追蹤錯誤留言：
- Development overrides (https://fxbug.dev/42178358). 這可讓開發人員在工程建構的執行階段變更設定，例如使用預先發布版功能。
- 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_data 的使用者應改用結構化設定或網域/內套件設定，兩者皆可提供更佳人體工學且更具彈性。
網域套件設定
網域中的元件開發人員可以定義自己的設定資料套件，並將目錄轉送至控制的元件。與全域套件設定不同，這項機制可用於不同的建構系統與花瓣。
套件內設定
設定檔也可能位於與設定的元件相同的套件中。這樣可以確保設定會隨著元件一起發布，而且不需要複雜且清晰的轉送。但也代表必須重新封裝元件，才能變更設定。詳情請參閱將資料檔案提供給元件指南。
套件內容會儲存在 blobfs 中；blobfs 是可刪除重複 blob 的定址檔案系統。這表示如果多個套件包含相同的設定 blob，系統只會儲存一個副本。
以服務為基礎的設定
您可以編寫 Fuchsia 元件，藉此透過 FIDL 收集、維護和發布網域的設定資料。典型的例子就是 Fuchsia 平台的設定服務，維護各種使用者設定 (例如語言代碼)：設定服務會在各個電源週期內維護這些使用者設定的狀態，並公開 fuchsia.settings FIDL 通訊協定，其他元件可能會使用這些通訊協定讀取目前的設定資料或要求變更設定資料。
以服務為基礎的設定可以非常靈活且功能強大，但導入伺服器元件通常比其他選項更為有效，且執行階段成本較高。請僅在此額外費用能增添價值時，再使用以服務為基礎的設定。
這個元件可能會使用多種不同的輸入來決定正確的設定。例如：驗證及合併用戶端要求的商業邏輯、從某些伺服器收集的設定，或是透過其他機制 (例如結構化設定) 提供的預設設定值。當設定必須橫跨多方的用戶端共用時，服務型設定就能正常運作，因為設定是由用來提供服務的 FIDL 介面正式定義及版本。如果經常變更設定，服務型設定也能正常運作。
服務型設定不適用於下列問題：
- 大型設定。設定是由 FIDL 訊息傳送，該訊息會受限於 zircon 管道寫入的大小。雖然 FIDL 通訊協定可透過將設定分割成多個區塊或傳送 VMO 來解決這個問題，但這會影響用戶端的簡單明確定義，也就是服務型設定強度。以套件為基礎的設定在處理大型設定時是更好的解決方案。