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