平台可更新性最佳做法

建議做法：使用 FIDL 類型和通訊協定定義任兩項可能會單獨更新的介面。在適用情況下，請採用 Fuchsia API 演進指南和 FIDL 評分量表。

不建議使用：避免使用 FIDL 以外的語言來定義獨立更新相關的介面。其中包括純文字、JSON 和通訊協定緩衝區。

查看替代方案時，請想想看替代方案會具備哪些可更新性。

  • 資料是否有結構定義？
  • 結構定義能否隨時間變更，同時提供回溯/前向相容性？操作方式：
  • 對結構定義進行哪些變更是 API/ABI 保留/破壞？在提交破壞性變更之前，您會如何知道？
  • 電線格式穩定嗎？

建議：在設計用於平台外部使用的平台 API 和 ABI 時，請務必謹慎。設計時須確保可更新性，並找到方法來強制執行用戶端使用目標介面，而且不會提供規避介面的方式。

不建議採用：請避免將用戶端公開給不綁約的實作詳細資料。常見錯誤包括公開範圍較廣的功能或命名空間，以及透過元件 ID (例如 fuchsia-pkg:// 網址) 和診斷選取器外洩實作詳細資料。