RFC-0147：檢視系統

RFC-0147：檢視系統
狀態	已接受
區域	顯示卡 HCI 查看系統
說明	說明 Fuchsia 平台的視窗化系統，並說明其在平台中的角色。
問題	83310
變更	602783 年
作者	dworsham@google.com jaeheon@google.com neelsa@google.com
審查人員	reveman@google.com jjosh@google.com emircan@google.com quiche@google.com ypomortsev@google.com kostyak@google.com wez@google.com
提交日期 (年/月)	2021-11-03
審查日期 (年/月)	2022-01-05

摘要

本 RFC 概略說明 Fuchsia View 系統，這是一組用來說明視覺區域 (「檢視畫面」) 及其生命週期的 API，在其他平台上，通常將這組功能稱為視窗系統。這個 RFC 的範圍僅適用於具有單一螢幕的產品。為了因應無頭裝置和/或多個螢幕而所做的變更，將會在未來的 RFC 中生效。

檢視畫面是圖像內容的地區，是 Fuchsia 上圖像和使用者互動的基本單位，檢視表會連結至 View 樹狀結構，提供專屬的根檢視畫面。Fuchsia 的圖形合成器「Scenic」會轉譯 View 樹狀結構中每個檢視畫面的圖形內容，以產生畫面的輸出內容。風景和輸入管道負責轉送指定 UI 的使用者輸入內容，例如鍵盤、滑鼠和輕觸到正確的檢視畫面。

檢視系統是 Fuchsia 平台支援「自行導入執行階段」支援的重要部分，而產品開發人員可利用多個執行階段中的圖像內容，在 Fuchsia 上打造安全的視覺使用者體驗。Fuchsia 的組合 API (Flatland 和 GFX) 以 View 系統為基礎建構而成。

提振精神

這項 RFC 的目標是記錄檢視系統的「世界狀態」資料，並進行統整。我們具體來看，我們想要大致說明以下決定。

1. 想要在 Fuchsia 上顯示圖形的元件必須使用檢視系統建立檢視畫面。唯一的例外是 Virtcon 和復原 UI 等單一視窗公用程式 UI。這種 UI 不會使用視窗功能，而且會在資源未執行時於資源有限的情況下執行。這些 UI 會直接與顯示控制器通訊。
2. 檢視系統是元件與 Fuchsia 平台支援使用者觸控、滑鼠、鍵盤及無障礙服務支援的唯一方式。
3. 視所用的組合策略 (GFX 與 Flatland) 而定，檢視系統可為 Fuchsia 上的所有合成器實作提供共同的基礎。

修改這些決策需要額外的 RFC 和/或更新到這個 RFC。

相關人員

講師：

hjfreyer@google.com

審查者：

這個部分預計在審查期間需要更新

• 圖形：reveman@google.com、jjosh@google.com、emircan@google.com
• 輸入：quiche@google.com
• 元件：ypomortsev@google.com
• 安全性：kostyak@google.com
• 一般：wez@google.com

顧問：

sanjayc@google.com、hjfreyer@google.com、jjosh@google.com、lindkvist@google.com、geb@google.com

社群媒體化：

文件草稿已傳送給景觀團隊和輸入團隊進行討論。

詞彙解釋

• Scenic
  • Fuchsia 平台中的圖形「合成」元件
  • View System API 的唯一實作項目，包括其圖像組合 API 和 HCI API 的對應功能。
• 查看
  • 圖像內容的視覺化區域。
  • 它具備座標系統、定界框，以及透過 View 樹狀結構與祖系定義的空間關係。
• 查看樹狀結構
  • 系統上的檢視畫面結構，由父項與子項關係連結。檢視區塊樹狀結構的根層級檢視通常會附加至顯示器。
• 螢幕
  • Pixel 輸出裝置，也稱為螢幕。檢視系統目前支援一次連接至一個系統。
  • 螢幕是透過顯示控制器管理。
• 顯示控制器
  • 可管理連接至電腦螢幕畫面的驅動程式。
  • 只會與景觀網站對話。
  • 不適用於樹狀結構用戶端。
• 場景管理員
  • 將根層級檢視畫面附加至螢幕畫面的平台元件。
• 無障礙管理工具
  • 實作無障礙 API 的平台元件。
  • 它擁有檢視系統的權限。
• 系統殼層 (「Sys UI」、「系統 UI」)
  • 負責處理產品使用者體驗的元件，例如 Ermine。這項元件通常用於特定產品。
  • 系統殼層會負責視窗管理，包括頂層檢視區塊的焦點處理和管理，而 View 系統則會處理視窗系統。
• 開發人員殼層 (「tiles」、「present_view」)
  • 用於測試的系統殼層。一般來說，這可讓開發人員獨立啟動 Fuchsia 元件。
• UI 用戶端
  • 這是參照 View 擁有者的一般方式，會在這個 RFC 中使用。
  • 範例：Flutter 應用程式、具有多個頂層檢視畫面的 Chromium。

設計

檢視畫面的定義

Fuchsia View 是 Fuchsia 上圖像和互動的基本單位，View 定義可向使用者顯示圖形內容的視覺區域。並非所有檢視畫面在特定時間都會顯示。每個檢視畫面的圖形內容是由 Fuchsia「元件」提供。用於管理 View 以及將內容組合在螢幕上的平台支援，是由 View 實作。

每項資料檢視：

• 可納入另一個檢視畫面的內容 (其子項檢視畫面)，形成檢視畫面樹狀結構。
• 定義用於放置子項內容的座標系統。
• 具有定界框，可定義該檢視畫面的可見 (及選擇性互動) 部分。
• 可連線且中斷與「景觀檢視樹狀結構」的連線。(未連結的 View 可能存在，但沒有轉譯至畫面的內容，也不會接收輸入內容)。

View 支援的任何圖形組合 API (例如 fuchsia.ui.composition 和 fuchsia.ui.scenic)，都必須提供建立檢視區塊及管理生命週期的方法。日後的組合 API 也必須在 View 系統上運作。Fuchsia 平台 HCI API (例如指標和鍵盤) 會使用檢視畫面轉送輸入。(詳情請參閱下方的「輸入內容」一節)。

查看樹狀結構

這裡有一個全球檢視樹狀圖，該樹狀圖由「風景」所有，並由他們執行。「View Tree」有可連接至螢幕的明確根檢視區塊。風景是唯一會直接操控所有檢視畫面及其位置的 Fuchsia 元件。

在 View 樹狀圖中，每個檢視畫面都有在各自的座標系統中定義邊界，以及在父項檢視畫面的座標系統中表示的位置和方向。同時決定了畫面上最後顯示圖形內容的區域，以及能回應使用者輸入內容的區域。

子檢視畫面

檢視畫面可以在其座標系統中建立空白的預留位置，藉此嵌入其他檢視畫面的其他圖形內容；預留位置稱為「可視區域」。這兩個檢視區塊會在 View 樹狀結構中形成父項與子項關係，而父項 View 的可視區域會嵌入子項檢視畫面的圖形內容。如要建立關係，父項和子項必須在建立檢視畫面和可視區域時提供相符的權杖。這些符記會實作為核心物件，且不具責任。父項和子項可透過 View 系統以外的各種方式，取得這些比對權杖。

在「View Tree」中附加或卸離父項檢視畫面也會附加/卸離其子項檢視畫面。即使子樹狀結構從全域 View 樹狀結構卸離，子樹狀結構中的檢視畫面仍會保持連結。

查看隔離

雖然 View 可以嵌入另一個檢視畫面，但 View 系統不會授予任何其他 View 圖像內容的 View 存取權。此隔離保證是檢視安全性的其中一個基礎。

風景優美的畫面地圖

「風景」是與螢幕控制器通訊的單一元件，此方法會擷取整個 View Tree 的圖形內容，以及樹狀結構中編碼的關係，會建立單一圖片 (可能包含多層)。然後程式會設定硬體來顯示最後的螢幕圖片。

查看擁有權

View 中的內容由單一 FIDL 管道提供至由 View 實作的圖形組合 API。從 FIDL 管道到 View 的每個用戶端端點都稱為「UI 用戶端」，因此 UI 用戶端最多只能建立一個檢視畫面。

檢視畫面可能來自各種元件，包括面向使用者的元件 (例如瀏覽器)、系統 UI，以及屬於 Fuuchsia 平台的元件，例如無障礙管理工具。元件可以建立多個管道，因此可以有多個檢視區塊。因此在某些情況下，單一元件可能會同時具有父項檢視畫面和該 View 的子項檢視畫面。

為了合併多個元件的圖形，開發人員應在每個元件中建立 View 或 View，並使用子項 View 和 View Tree 組合。請務必注意，View Tree 階層不需要與元件執行個體階層相符。在許多情況下，這些結構會刻意看起來截然不同。

Runtimes

如果是以較高階語言 (例如 Dart 或 JavaScript) 編寫的元件，執行器通常負責建立及管理 View。使用這些語言的開發人員可能不知道基礎 OS 的許多細節；執行元件負責將 View 生命週期轉譯為語言專屬或執行階段專屬機制。

視窗管理、視窗系統與組合

Fuchsia 將三個有時會與其他平台合併的函式分開。

• 視窗管理整合了產品專屬政策和視窗行為的特定選擇。在 Fuchsia 中，這是系統 UI 的責任，而且完全居住在平台之外。
• 視窗系統是指低階視窗管理。在 Fuchsia 上，這項作業會由檢視系統處理。
• 「組成」是指合併多個來源的圖片，產生要顯示的映像檔。這同時也是皮膚元件的責任，但日後可能會改變。

選擇將視窗系統和組合分開，就能提供圖形呈現的快速路徑，進而有效率的實作方式。雖然 View 系統和合成器目前主要在 View 中實作，但在 API 和程式碼方面兩者各自獨立。這種分隔讓檢視系統支援多個組合策略 (Flatland 和 GFX)。

將視窗管理視為產品層級的疑慮後，我們會把政策邏輯保留在平台外，確保平台和產品之間能夠保持一致。

輸入

檢視系統是 Fuchsia 平台決定如何轉送使用者輸入內容 (例如指標事件或鍵盤事件) 的主要機制。Fuchsia 的使用者輸入 API 都設計成每個管道的範圍，也就是特定檢視畫面。系統會根據目前的 View 焦點 (如鍵盤事件) 和/或與輸入事件位置 (例如觸控或滑鼠事件) 對應的檢視畫面或檢視畫面，將輸入內容轉送至 View。檢視畫面「只能」在解讀至檢視畫面樹時收到使用者輸入內容。

相同事件的多個檢視畫面可能會參與輸入處理。特定產品的視窗管理員可根據產品政策設定這項轉送作業，例如授予系統 UI 滑鼠事件的全域存取權。詳情請參閱使用者輸入架構。這個系統可讓來自多個執行階段的 View 流暢使用者體驗，包括區分觸控手勢的功能。

這種做法的一個重要影響，是 Fuchsia 平台以外的元件無法直接從驅動程式庫存取輸入事件。且必須接收由檢視系統中介的資訊。

查看重點

無論何時，檢視畫面樹狀結構都有一個不同的檢視畫面，稱為「聚焦」檢視畫面。聚焦的檢視畫面通常是使用者預期會收到使用者輸入內容的檢視畫面。Fuchsia 的輸入子系統仰賴 View 焦點來判斷輸入路徑的位置。詳情請參閱聚焦鏈說明文件。父項 View 擁有者可在子樹狀結構中控制檢視畫面焦點。

ViewRef

平台會使用名為 ViewRefs 的權杖來識別 View 並傳達相關資訊。ViewRef 是特定檢視區塊的不重複參照，在系統重新啟動前保持唯一性。它是以核心物件的形式實作，這個處理常式可以自由複製，並透過任意通訊協定傳送至其他元件。

View System API 會大量使用 ViewRefs，為各個檢視畫面提供穩定的跨元件參考資料。ViewRefs 也可用來發出與相關檢視畫面相關的生命週期事件信號。這可讓平台內外的其他元件傳達 View 相關資訊、其生命週期，以及將使用者輸入內容和無障礙通訊協定轉送至 View。

實作

「風景」是檢視系統的授權來源，因為 View Tree 和核心 View 管理 API 是在觀賞中實作。每個用戶端都會使用其 ViewRef 註冊，以接收相關聯檢視畫面的使用者輸入內容和無障礙功能事件。View 目前支援兩種圖形組合 API：fuchsia.ui.scenic (舊版) 和 fuchsia.ui.composition (開發中)。檢視系統彼此獨立，但可與各種檢視系統搭配運用。

API 實作詳細資料不在這個 RFC 的適用範圍內，但您可以在下方找到相關的 API。值得注意的是，這些 API 數年來逐步發展。有些層面未來可能會簡化。

檢視系統涉及的平台元件

• 風景
• 輸入管道
• 場景管理員 (或舊版系統上的 Root 簡報者)
• 無障礙管理工具
• 文字管理工具

資料檢視管理的 API

• fuchsia.ui.views
  • 查看參照、查看權杖定義
  • 查看焦點管理
• fuchsia.ui.composition
  • 建立檢視畫面、移動檢視畫面、調整檢視畫面大小、連結/取消連結檢視畫面
• fuchsia.ui.policy
  • 將系統 UI 檢視畫面連線至根層級檢視畫面
• fuchsia.ui.app.ViewProvider
  • 從元件建立途徑檢視畫面
• fuchsia.web.Frame
  • 建立網路用戶端檢視畫面

使用者輸入內容的 API

• fuchsia.ui.pointer
  • 指標事件
• fuchsia.ui.input3
  • 鍵盤輸入
• fuchsia.ui.shortcut
  • 鍵盤快速鍵

無障礙 API

• fuchsia.accessibility.semantics
  • 允許 View 傳送語意資訊給無障礙功能
• fuchsia.ui.annotation
  • 允許無障礙功能醒目顯示焦點的 UI 元件

效能

檢視系統的許多方面都會影響圖形和輸入效能。下文將說明幾個重要面向。

• 所有執行階段都相同：Fuchsia 根據「自備執行階段」原則，表示 Fuchsia 中的所有執行階段都使用相同的事件轉送，且執行階段不會獲得首選處理方式。
• 僅顯示一次：風景可以合併不同 View 的圖形內容，而不必重新轉譯，因為其瞭解檢視位置，且能將圖形內容正確轉送給顯示驅動程式庫。
• 有效率的調度：View 會公開焦點資訊，允許不血腥的使用者輸入內容 (例如鍵盤事件) 直接從處理過程中的元件傳送。

安全性和隱私權注意事項

檢視系統提供多項保證，可安全地在 Fuchsia 上編寫圖形內容，而這些保證是提供安全使用者體驗的基礎。然而，只使用 View 系統無法保證每個使用者體驗都安全無虞，只有 View 系統會遵循其自身的安全性保證。

View System 會嘗試透過以下方式啟用安全的使用者體驗：

• 將擁有及操控 View 樹狀結構的唯一責任委派給煙火。
• 將螢幕上圖像內容的唯一責任委派為 View。
• 禁止 UI 用戶端在沒有相符 Viewport 或 ViewRef 的情況下操控其他 View。
• 禁止 UI 用戶端使用 View 系統檢查任何其他 UI 用戶端的檢視畫面內容。
• 僅允許 UI 用戶端將輸入內容插入其檢視畫面子樹狀結構。
• 僅允許檢視畫面在連結至檢視區塊樹狀結構時取得焦點及接收輸入內容。

UI 安全性仰賴元件架構針對能力轉送提供的保證。我們會在日後的 RFC 中解決有關 View 安全性的細節。

測試

檢視系統在多層抽象層實作，因此使用分層方法進行測試。

在 fuchsia.git 中：

• View 樹狀結構和 View 生命週期的單元測試 (位於風景元件的程式碼集中)。
• /src/ui/tests 中的 UI 整合測試，會執行 View System API 的合約。
  • 這些 API 會由 View 元件、Scene Manager、輸入管道、無障礙管理工具和文字管理工具等平台元件更新，並由這些元件使用。
• fuchsia.ui.observation.test API 可在樹狀結構整合測試中使用，以檢查 View 系統行為。

樹狀結構外：

• Chromium 和 Flutter 等執行階段會將整合測試寫入運動 View System API
• 產品撰寫了間接執行 View 系統的端對端測試。

說明文件

本 RFC 提供檢視系統的角色和責任概要總覽。系統會撰寫文件和可能的其他 RFC 以處理細節。

為了因應這個 RFC，以及 Flatland 即將實施的異動，部分 Scenic 說明文件還需要更新。

缺點、替代方案和未知

已知限制

檢視系統目前缺少在多個檢視畫面之間同步更新的機制。

View System 負責將功能轉送至公開檢視畫面的執行階段 (使用 ViewRefs)。這與透過 Fuchsia 元件架構的能力轉送有一些概念重疊，但目前完全分開。在日後，支援在元件架構中支援 View 功能或許會對您有所助益。

目前的 API 僅允許 View 擁有者建立子檢視畫面。對於想要建立多個頂層視窗的應用程式等方式，這並不適合使用這個方法。

由於 View System API 多年來不斷演進，且有多位不同的貢獻者，因此目前執行階段開發人員的認知負擔也相當高。我們日後應透過更好的說明文件和範例以及可能的 API 簡化程序，降低這項錯誤。

替代選項

檢視系統架構提供多種架構選擇。

• 含有圖形的產品都必須使用檢視系統。
  • 此外，風景也可以是選用，產品也可以包含自己的合成器。這就必須從樹狀結構中公開許多低層級的 API。
  • 目前做法的優點：
  • 不同執行階段的同質行為 (包括無障礙功能和輸入)
  • 一致的安全性保證
  • Display API 可在不中斷用戶端的情況下不斷進化
  • 目前方法的缺點：
  • 較少自訂產品
  • 執行階段整合作業的複雜度
  • 日後如果需要在 Fuuchsia 建構產品，這個值日後可能會改變。
• 檢視系統分散於數個元件，包括「風景」和「輸入管道」。
  • 或者，我們也可以將整個 View 系統建構成「風景」。
  • 目前做法的優點：
  • 關注點分離：圖形組合、視窗管理和產品政策都是各自獨立的。
  • 允許透過委派組合提供高效能的圖形路徑
  • 與 UI 相關的元件可獨立演變
  • 允許圖像在子系統 (例如文字輸入) 當機時保持運作
  • 目前做法的缺點：
  • 多個程序可能會使處理序間通訊 (IPC) 增加延遲
  • 增加元件之間的協調/同步處理作業複雜度

先前的圖片和參考資料

• 檢視系統和風景與 X Windows 系統具有一定的架構相似。
• 其他層面更與 Wayland 通訊協定相輔相成。
• 輸入架構 RFC 詳細說明瞭檢視畫面系統如何與 Fuchsia 的使用者輸入子系統互動。