| RFC-0189：視窗管理 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 說明用於視窗管理的平台架構和標準 API。 |
| 問題 | |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2022-08-12 |
| 審查日期 (年-月-日) | 2022-09-20 |
摘要
這份 RFC 提出了一個模型，說明 Fuchsia 平台、產品工作階段和工作階段殼層如何合作，支援具有多個視窗的複雜圖形應用程式。請特別注意以下幾點：
- 雖然平台負責提供機制，可將圖像顯示在螢幕上並轉送輸入內容，但產品元件必須指定產品專屬的政策，說明圖像的顯示時機和方式。
- 平台會定義用於視窗管理的標準化 API 介面1，以便應用程式和產品之間達到最佳相容性。
這項做法的重大影響是，應用程式會與 Fuchsia 平台整合，而非與特定 Fuchsia 產品整合，因此與某個 Fuchsia 產品搭配運作的應用程式，應可與任何支援相同一組視窗功能的 Fuchsia 產品搭配運作。特別是，針對一個 Fuchsia 桌面產品執行的應用程式，應針對任何此類產品執行，無論特定產品工作階段或系統殼層實作為何。
本 RFC 是 RFC-0092：工作階段的擴充內容。它描述的是預期狀態，而非目前的運作方式。本 RFC 中所述的方法會取代先前的所有嘗試 (模組化、工作階段架構)，並成為日後記錄的計畫。
提振精神
目前的 Fuchsia API 讓產品和應用程式難以實作豐富的視窗管理和多視窗應用程式。平台和產品責任的差異令人困惑，而且平台提供的 API 來自早期 Fuchsia 願景，缺少目前工作所需的部分重要功能 (例如工作站)。我們先前曾多次嘗試解決這個問題和相關問題 (模組、工作階段架構)，但沒有任何一個解決方案能夠在所有 Fuchsia 途徑上全面實作。
系統目前的狀態缺乏明確的責任劃分，且有許多方式可執行相同的動作。這導致不同產品之間出現分散現象。我們現在已核准架構，因此可以決定平台日後支援的 API (例如可能採用 Wayland 以供 Fuchsia 使用)，並解除殼層和應用程式的開發限制。
這份 RFC 可能是一系列涵蓋視窗管理不同層面的 RFC 的第一份。其目的是釐清產品和平台之間的差異，方便您日後決定要使用哪些 API (例如 Wayland)。
相關人員
協助人員：abarth@google.com
審查者：
- 圖像：dworsham@google.com
- 工作站：sanjayc@google.com
- 架構：abarth@google.com
- 元件架構：thatguy@google.com
- Chrome：wez@google.com
- UX：asz@google.com
諮詢對象：quiche@google.com、jasoncampbell@google.com、geb@google.com、masonben@google.com、jsankey@google.com、tjdetwiler@google.com
社會化：在透過 Gerrit 發布前，我們已與相關人士分享並充分討論此 RFC 草稿。
定義
本文件的目的：
- 顯示伺服器 (又稱為合成器)：這個元件負責讓應用程式元件建立及顯示檢視畫面，讓這些檢視畫面的放置位置和大小受到控制，並確保圖形輸入事件可根據其檢視畫面傳送至應用程式元件。在 Fuchsia 上，這會是scenic。
- Window Manager：控制應用程式提供的視窗位置和外觀的元件 (或多個元件)。在某些系統中，此系統還負責轉譯 UI (例如標題列)。由於 Fuchsia 平台可用於實作具有截然不同的圖形和輸入功能的各種產品，因此在 Fuchsia 上分配視窗管理員的職責，可能會與其他作業系統大相逕庭，因為其他作業系統的平台與單一使用者體驗的關聯性較高。
- 系統殼層：負責繪製產品 UI 的元件。這個元件擁有顯示視覺內容的檢視區塊階層產品子樹狀結構中的頂層景觀檢視畫面。這個檢視畫面有時也稱為殼層檢視畫面。系統殼層負責在檢視區塊中安裝應用程式元件提供的檢視畫面，並針對如何顯示這些檢視畫面做出政策決定。
- 產品工作階段：負責實作 Fuchsia 產品體驗的元件。這個元件會以工作階段管理員的子項執行。這個元件負責根據使用者動作，啟動具備適當功能的應用程式元件。截至本 RFC 撰寫時，Fuchsia 一次只支援單一工作階段。
- 元素：含有圖形的元件工作階段架構概念。本 RFC 已淘汰元素角色。
- 應用程式元件：實作圖形使用者體驗，並在系統殼層中執行的元件。
- 檢視區塊樹狀結構：scenic 場景圖中的檢視區塊階層。
設計
總覽
Fuchsia 的視窗管理功能主要分為兩個層面：機制和政策。
- 「政策」是指產品專屬的詳細資料，說明哪些元件可在畫面上顯示圖形、圖形顯示的位置、接收輸入內容和焦點的方式，以及在檢視區塊樹狀結構中的關聯方式。政策是決定視窗可發生的事件。
- 「機制」是指取得螢幕上的像素，並將輸入內容路由至其基礎元件的機制，主要透過 Fuchsia UI 堆疊處理。提供圖形的所有元件都必須與這些 API 通訊。政策決定的影響可能需要多次呼叫機制 API，才能對 UI 造成相關變更。
Fuchsia SDK 定義了兩個 API 途徑，用於管理視窗政策：
- 系統殼層 API，可實作特定產品的視窗管理政策，並提供有關此產品可用的視窗管理員功能的資訊。目前，這項功能是透過要求系統殼層實作圖形呈現者角色來達成。
- 應用程式元件可使用此 API 或一組 API，要求變更該元件所擁有的檢視畫面是否存在和外觀。這會採用核心 API 的形式，所有應用程式用戶端都應使用這個 API，並可能擴充其他行為 (可在執行階段偵測)。這個 API 介面應在所有 Fuchsia 應用程式中共用，方便在 Fuchsia 上建構的不同產品之間保持相容性。
目前用戶端應用程式的實作細節差異極大。有些應用程式會實作元素角色，其他應用程式則會直接與元件架構和 Scenic 互動，或在應用程式中實作元素管理器 API。這份 RFC 要求簡化這項作業，將所有應用程式元件都移至單一 API。
這個 RFC 目前沒有表達系統殼層和應用程式元件是否直接互通，或平台元件是否應調解這些互動。
架構圖
上圖顯示在 Fuchsia 上執行的圖形產品可能的架構。產品工作階段負責啟動系統殼層和任何應用程式。應用程式和系統殼層必須針對任何政策決定進行通訊，可能會透過平台提供的視窗管理器或「橋接」元件 (請參閱下方的可能的平台橋接元件)。系統殼層和應用程式也必須與 Fuchsia 平台 UI 堆疊 (包含處理圖形和輸入處理作業的元件) 通訊，才能在視窗管理的「機制」方面執行。這類通訊也可能會透過橋接元件進行。
產品工作階段的責任
產品工作階段是產品啟動時，第一個要啟動的產品專屬元件。對於含有圖像的產品，則須負責下列事項：
- 產品工作階段負責啟動應用程式元件，並提供適當的功能，包括將 UI 顯示在螢幕上所需的功能。
- 產品工作階段必須為使用者體驗提供根檢視畫面，可直接實作或委派至子項元件。提供此檢視區塊的元件也稱為系統殼層 (有時也稱為系統 UI)。系統殼層具有一個能力 (fuchsia.session.scene.Manager)，可讓其在檢視區塊樹狀結構中安裝根檢視區塊。(請注意，產品可能包含多個殼層，例如登入和使用者殼層，並視需要在兩者之間切換)。
- 產品工作階段負責管理視窗的產品政策層面。具體來說，工作階段必須實作 Fuchsia SDK 提供的視窗管理政策 API。這項責任包括提供此產品可用的視窗作業類型相關資訊。
元件階層範例
此圖表顯示使用者體驗的可能元件階層。請注意，這會移除元素管理員。如圖所示，應用程式元件是產品工作階段的子項。有些產品可能會選擇以不同方式進行設定，例如在產品工作階段的領域中建立負責啟動應用程式的元件，或是將應用程式元件例項化委派給具有不同功能的某些平台元件。
設定檢視區塊階層
啟動後，應用程式可以與 Scenic 聯繫，建立應用程式檢視畫面，然後透過視窗管理 API 與系統殼層聯繫，將該檢視畫面顯示為系統殼層的使用者體驗。系統殼層會與 Scenic 聯絡，將應用程式檢視畫面安裝至檢視畫面樹狀結構中，通常是做為根檢視畫面的子項。
應用程式可以按照上述建立初始視窗的流程，開啟第二個頂層視窗。其他視窗管理動作 (例如調整應用程式檢視畫面大小、啟動彈出式視窗等) 需要應用程式元件透過視窗管理 API 呼叫，向系統殼層要求這些變更。一般而言，每個元件都會負責直接與 Scenic 溝通，說明其擁有的 View 內容。不過，如果檢視區塊擁有者/應用程式想要變更檢視區塊的顯示方式 (例如調整大小、最小化或開啟其他頂層檢視區塊)，系統殼層必須以某種方式表示允許此動作。系統殼層可以透過回應用戶端 API 呼叫，或是在檢視樹狀結構中儲存資訊，來指出該檢視畫面允許執行的動作，並允許 Scenic 執行相關政策。
注意：
- 產生的元件階層和檢視樹狀結構看起來不一樣！雖然應用程式檢視畫面必須是系統殼層擁有的檢視畫面的子項檢視畫面，但應用程式元件不必是系統殼層元件的範圍。
- 這段說明省略了許多有關建立檢視畫面的詳細資訊，包括如何透過檢視區塊將使用者輸入內容等內容導向檢視畫面。
檢視區塊階層範例
上圖顯示執行多個圖形應用程式的系統 UI 的範例檢視區塊樹狀結構。系統殼層檢視區塊是使用者體驗的根檢視區塊。請注意，檢視區塊樹狀結構的父項-子項關係可能與上述元件階層不同。
協商視窗管理功能
並非所有系統殼層實作方式都會公開相同的功能，因為系統殼層部分實作了產品專屬政策。因此，這些實作方式會因產品而異。舉例來說，智慧手錶的 UI 可能非常簡單，一次只顯示一個畫面，而電腦則支援多個應用程式，並允許多個視窗重疊。有些產品支援使用者透過觸控螢幕輸入內容，有些產品則只支援滑鼠和鍵盤。
針對「核心集合」以外的產品專屬功能，用戶端必須能夠找出目前產品支援哪些功能。這可讓用戶端針對不同產品調整行為，並實作可在不同產品中運作的 Fuchsia 圖形應用程式。
同樣地，系統 UI 必須告知平台目前可用的功能。
可能的平台橋接元件
平台可能會引入「橋接」元件，用於協調用戶端應用程式和系統 UI 之間的通訊。這個元件類似於其他平台上的視窗管理員，可自動執行某些「機制」動作來管理視窗，並減少開發人員需要撰寫程式碼，將低階指令傳送至 Fuchsia UI 堆疊。這樣做的好處是，讓用戶端可透過單一 API 介面與機制和政策進行通訊，這也是其他系統 (例如 Wayland) 的常見模式。將橋接元件置於平台中，也能讓產品共用視窗管理程式碼，避免重複類似功能。
至於是否要使用平台橋接元件/平台視窗管理工具，則留待日後的 RFC 決定。
實作
這份 RFC 說明瞭視窗管理的高層級架構。我們預期未來的 RFC 會對相關 API 進行重大變更，因此，這些 RFC 應會說明許多實作細節。
當 API 就位後，這個 RFC 會移除系統目前缺陷的許多舊版解決方法。請特別注意以下幾點：
- 此 RFC 已淘汰元素管理工具 (目前的元素管理工具功能將成為產品工作階段的工作)。
- 這份 RFC 會確認意圖，以便將應用程式的行為標準化 (不再需要 Chrome 專屬的因應措施)。我們會在日後的 RFC 中說明現有 API 的替代方案。
成效
雖然圖像和使用者輸入處理作業對效能非常敏感，但開啟新應用程式或視窗等視窗管理政策決定通常會以「人類速度」進行，因此不需要像轉譯或輸入處理作業那樣達到相同程度的效能。因此，在執行「控制」動作 (例如開啟新視窗) 時，通常可以使用額外的 RPC。不過，設計 API 時應小心謹慎，確保任何效能敏感的流程 (通常是涉及資料流程的流程，例如將影格放置在畫面上、路由使用者輸入內容) 避免不必要的 IPC，並且不會不必要地阻斷用戶端回應。在視窗管理員和殼層不是相同元件的情況下，這一點尤其重要。我們會在日後的 RFC 中詳細說明特定 API 的效能影響。
動畫和同步
為了為使用者提供順暢的體驗，請務必確保 UI 動作 (例如調整大小動畫) 可在多個元件之間同步。雖然這主要是特定 API 的功能，且可保證原子性，但架構會影響建構可進行此同步作業的使用者體驗的難易度。
這份 RFC 並未正式採用特定 API，但其中的決策是根據 Wayland API 進行評估，而 Wayland API 的目標是「讓每個影格都完美無缺」。在完成本 RFC 中所述 API 時，同步處理問題將是重要的考量因素。
安全性和隱私權注意事項
元件安全性
這份 RFC 說明元件階層和檢視區塊階層不必相同，並允許應用程式以產品工作階段的子項而非系統殼層 (在某些系統上可能較不穩定或不安全) 啟動。這樣一來，產品就能更輕鬆地確保產品內的元件階層符合該產品的特定安全性和隱私權需求。
查看安全性
View 系統 RFC 詳細說明瞭 View 系統的安全保證。請注意，此 RFC 保證在目前聚焦於某個檢視畫面或其子項時，該檢視畫面只能操控檢視畫面聚焦，且與檢視畫面樹狀結構中斷連線的檢視畫面無法接收使用者輸入內容。也就是說，產品工作階段安裝系統 UI 檢視畫面，以及系統殼層做出的視窗管理政策決策 (例如為已啟動的應用程式安裝子檢視畫面)，也決定了哪些元件可在任何時間接收使用者輸入內容。雖然平台無法保證所有產品都會實作安全行為，但 View 系統會提供建構元素，讓產品打造安全的體驗。
測試
平台應為所有視窗管理 API 提供一致性測試，以便產品和應用程式確保與 Fuchsia 平台的相容性。這些測試可能會因特定應用程式或產品工作階段支援哪些視窗管理 API 擴充功能而異。
系統殼層和應用程式開發人員可以使用Test UI Stack，為程式碼與 Fuchsia 平台 UI Stack 的互動情形編寫整合測試。
說明文件
這項 RFC 和後續處理 API 特定事項的 RFC 都需要大幅更新 fuchsia.dev 上的 Session Framework 說明文件，以反映產品和平台之間的劃分方式更新後的預期結果，以及 Element Manager 的淘汰。
缺點、替代方案和未知事項
替代做法：Scenic 會進行視窗管理
- 在沒有新 API 的情況下，請勿讓系統殼層套用產品層級政策/概念。
- 不清楚如何擴充這個 API 來處理產品差異。否則會將許多特定產品的邏輯 (例如「minimize」的意思為何) 推送至平台。
既有技術與參考資料
-
這些 API 將在後續 RFC 中定義。 ↩