什麼是平台可更新性？
Fuchsia 是從核心開始建構，可滿足現今不斷擴大的連網裝置生態系統需求。 產品擁有者 產品需求會隨著時間而變更，因此 Fuchsia 必須能夠變更以符合需求。
新平台版本可能會提供新功能和錯誤修正。與 Fuchsia 平台整合的產品擁有者，可能需要在新的平台版本上重新設定現有產品組合。根據產品性質和更新方式，最終使用者甚至可以直接從 Fuchsia 專案接收平台更新。視組合產品的性質而定，產品擁有者可能無法將現有應用程式軟體移植至新平台版本，且必須依賴現有應用程式預先建構項目，才能繼續使用新平台預先建構項目。
Fuchsia 的設計可讓平台的各種元素隨時間變更及更新，同時支援現有和新產品。參與產品生命週期的不同軟體供應商，可能會各自有獨立的開發和發布時程。本文將說明支援這種分離式更新機制的機制。
平台更新功能如何運作？
Fuchsia 提供多種機制，可提升平台隨時間更新的能力。以下將介紹最常見的機制及其應用方式。
嚴格定義的介面
介面可視為不同軟體之間的契約。Fuchsia 會在平台和執行的軟體之間定義這類合約。平台的應用程式二進位檔介面 (ABI) 途徑已明確定義並列舉。ABI 途徑包括進入核心的進入點、與平台服務的所有互動，以及其他慣例和通訊協定。開發人員可以編寫軟體與 Fuchsia 互動，例如使用以 Fuchsia Integrator Development Kit (IDK) 為基礎的軟體開發套件 (SDK)。Fuchsia IDK 包含介面定義和用戶端程式庫，可提供從相同平台合約衍生的應用程式程式設計介面 (API)。
介面定義語言
Fuchsia ABI 主要以 Fuchsia 介面定義語言 (FIDL) 定義。
- 系統呼叫 (系統呼叫) 和 核心 vDSO 中的系統呼叫 ABI 會以 FIDL 表示。請注意，目前 FIDL 中並未定義傳遞至系統呼叫和從系統呼叫傳遞的結構體。
- 系統會使用多種 FIDL 通訊協定與使用者模式平台服務通訊。
- 常見的 API 是以 FIDL 實作。
FIDL 工具鍊可為用戶端和伺服器產生多種程式設計語言的繫結程式碼。工具鍊的設計可讓您輕鬆擴充支援更多語言。
FIDL 的設計目的是支援跨版本相容性，並簡化介面變更作業。FIDL 提供相容性保證，並列出具體的變更內容，以便二進位檔相容 (ABI 穩定) 和/或原始碼相容 (API 穩定)。
作為介面定義語言，FIDL 具有特殊的操作元素，可協助開發人員隨著時間變更通訊協定和類型，同時維持回溯和前向相容性。這類轉場有時也稱為「軟轉場」。
- 開發人員可能會隨時間新增及移除方法。
- 開發人員可以使用彈性聯集類型，讓舊版用戶端忽略新資料。
- 開發人員可以重新命名類型，而不會破壞 ABI 相容性。
透過以 FIDL 定義大部分 Fuchsia 系統介面 (尤其是預期會隨時間變更的部分)，Fuchsia 就能更充分運用 FIDL 的特殊修訂功能。
版本管理和相容性中繼資料
Fuchsia 定義了平台版本命名方案，用於表示 Fuchsia IDK 的 API 級別，以及 Fuchsia 平台的 ABI 修訂版本。Fuchsia IDK 或 Fuchsia 平台的每個版本都可能分別推出 API 或 ABI 修訂版，在這種情況下，版本會以遞增版本表示。版本化版本可能會支援一系列版本，做為回溯/前向相容性視窗。
Fuchsia 介面的屬性可能會加上相應的版本中繼資料註解。
- 在特定版本中，系統會新增屬性，也可能會移除屬性。這會以編號版本定義該資源的支援時間範圍。
- 在特定版本中，屬性可能會標示為已淘汰。已淘汰的屬性表示最終會移除該屬性，但不會影響 ABI。
- 已淘汰的資源可能會以人類可讀的格式附帶額外的附註。這類附註通常會向開發人員說明，在移除資源後，他們應採取哪些措施，以免造成中斷。
介面中的不同元素可能會加上不同的註解。舉例來說，在不同版本中，通訊協定或聯集中的不同方法可能已新增、已淘汰或已移除。
FIDL 是 Fuchsia 上介面定義的通用語言，支援版本註解。為協助對平台 FIDL 檔案進行變更的開發人員，偵測其變更是否會導致 API 引進可能不相容的修訂版本，系統會從 FIDL 檔案產生 API 摘要。您可以將摘要與已儲存的參考資料 (即黃金檔案) 進行比較，找出重大變更，並確保這些變更是經過明確意圖導入的。
命名空間
傳統上，程序是執行緒和受保護資源的容器，例如虛擬記憶體區域。在 Fuchsia 上，處理程序還可以指派本機 命名空間。命名空間是沙箱的基礎，可確保程式只能存取所提供的資源，且以所提供的條件存取，例如核心物件、FIDL 通訊協定或檔案。這些會形成不同的功能，可能會在執行階段由程式使用。
沙箱通常會以元件資訊清單的形式定義。元件資訊清單集合可定義沙箱中提供哪些功能，以及如何滿足這些功能。不過，這些詳細資料不會顯示在沙箱中的元件中。元件的父項可能會將某項能力路由至由某個元件或其他元件提供的子項，隨著時間變更實作詳細資料，但不變更沙箱的形狀。
沙箱可促進鬆散耦合，並允許實作細節變更，而無須讓客戶察覺。舉例來說，當 Netstack3 取代 Netstack2 時，使用網路功能的元件在理想情況下不會察覺差異。這也對測試有所助益，因為測試作者可能會將測試雙重注入元件，而測試中的元件不會偵測到這項操作。
包裝
套件是 Fuchsia 上的軟體發行單位。套件會在指定的目錄版面配置中包含一或多個檔案。這些可能符合包裝系統 ABI 的慣例。
封裝作業會與命名空間合作，建立某種沙箱環境。從套件解析的元件將存取其命名空間中的已封裝內容。因此，元件作者可以將其他檔案 (例如本地化素材資源) 與元件一併套件。相反地，他們通常無法直接存取其他套件中的檔案。舉例來說，系統字型是透過 FIDL 通訊協定提供，而不是直接存取檔案。或者，開發人員也可以自行套件字型檔案。
違規處置
如果可以避免在兩個系統之間使用特定介面，兩個系統可能就會更加緊密結合，並且無法獨立變更。Fuchsia 會使用各種機制，確保平台介面受到監控和尊重。
- 核心會定義 ABI，以便從使用者模式程式碼進入核心，也就是系統呼叫 ABI。不過，ABI 位於核心和 vDSO 之間。應用程式必須呼叫 vDSO 匯出的符號，而非直接執行系統呼叫。由於核心和 vDSO 可能會一起版本化，因此要求應用程式呼叫 vDSO 可讓系統呼叫 ABI 無縫變更，而應用程式開發人員不會察覺。為了強制這項屬性，核心會在系統呼叫入口點檢查呼叫端的位址，並確保該位址位於 vDSO 在呼叫端位址空間中對應的範圍內。
- 核心提供用於建立程序的系統呼叫。不過，程式載入作業的詳細資料相當複雜，因此會在程序啟動器實作中抽象化。為確保應用程式開發人員不會暴露這些詳細資料，元件不得直接建立程序，而是可能會提供在 FIDL 通訊協定後方啟動的程序啟動器。這樣一來，程式載入的詳細資料就會隨時間變更。
- 任何檔案系統目錄都可以用來做為程序命名空間的根目錄。這些命名空間可確保程式只能存取已知且經枚舉的檔案集，避免形成非預期的 ABI。為確保目錄路徑可做為不可避免的根目錄，Fuchsia 檔案系統不會實作「..」。