RFC-0096 - 使用者輸入架構

RFC-0096：使用者輸入架構
狀態已接受
領域
  • HCI
說明

針對具有圖形使用者介面和多個執行階段的系統，為 Fuchsia 提供使用者輸入事件 (鍵盤、滑鼠、觸控等) 的整體架構。
問題
毛皮變化
作者
審查人員
提交日期 (年-月-日)2021-04-15
審查日期 (年-月-日)2021-05-26

編輯此 RFC

編輯 RFC 中繼資料

摘要

此 RFC 說明傳送使用者輸入內容的目標高階架構 這類事件 (鍵盤、滑鼠、觸控等) 會在具有圖形的系統上 使用者介面和多個執行階段使用者透過以下方式輸入系統 各種方法/裝置，包括鍵盤、滑鼠、觸控和按鈕。這個 RFC 說明 Fuchsia 的輸入事件如何從驅動程式庫層級原始資料轉至輸入 事件 (例如 Flutter 應用程式)。 所提及的元件和元件仍在開發階段，

提振精神

為了促進 Fuchsia 的多元包容理念，Fchsia 的輸入內容 針對以不同執行階段為基礎建構的元件，提供平台層級的支援 採用不同的 UI 架構 (如 Flutter、Chromium) 來自訂輸入行為。在其他平台上：這些行為 通常會融入特定 UI 架構的實作中。紫紅色 帶來多項獨特的平台輸入處理 特定 UI 架構的細節

Fuchsia 程式碼目前有多個輸入轉送路徑 (根層級為 簡報者、輸入管道) 受限。 公開指南，說明偏好的路徑和遷移計畫。這份 RFC 概述 Fuchsia 的使用者輸入內容轉送目標架構，並提供指引 瞭解如何擴充輸入處理，以用於日後的用途。

需求條件

  • 安全性：Fchsia 輸入堆疊可讓您輕鬆打造安全的產品。
    • 輸入事件可能含有密碼和付款資料等機密資料， 以及使用者的使用時間所有使用者輸入事件 應視為個人識別資訊，且 並由信任的系統元件提供使用者軟體
    • 無法正確轉送使用者輸入內容，例如 惡意 UI，造成使用者誤按按鈕 點擊 (「點擊劫持」)。
    • Fuchsia 平台應盡可能鼓勵開發人員 提供易於理解的 API 介面來保護產品 並透過系統稽核使用者輸入事件的流程。
  • 正確性：依使用者傳送輸入事件 期望。
    • Fuchsia 輸入系統負責解讀 並提供給目前正確的目標元件 是在系統上執行的應用程式不過，「正確」的定義可能不同 根據事件和產品類型而定
    • 即使 UI 呈現動畫效果，輸入事件傳送作業仍應保持一致 或變更大小
    • 事件有時可同時分派至多個元件 (例如鍵盤快速鍵)。
  • 效能：使用者輸入內容的速度夠快。
    • 雖然確切的延遲時間要求會因輸入裝置和產品類型而異， 輸入內容交付程序特別容易受到延遲影響，因此應盡力讓 讓使用者不會察覺延遲。
    • 輸入架構應避免造成不必要的延遲。於 會特別注意程序環境切換鈕，以避免 不必要的封鎖呼叫。
  • 可自訂：系統應支援不同的使用者輸入行為， Fuchsia 平台上建構的不同產品。 * 具體來說，該產品 工作階段 應包含 這個 自訂輸入行為的能力不過，這是初始實作 此 RFC 中提議僅有一部分的最終需求 量身打造專屬模式(請參閱「輸入管道」 自訂功能)。
    • 部分產品需要鍵盤和滑鼠支援功能，其他產品則需要支援 主要透過觸控和按鈕互動。
    • Fuchsia 平台應提供產品專屬掛鉤 自訂輸入行為 (例如 按鈕事件)。
    • Fuchsia 應允許產品將輸入事件對應至不同類型的類型 例如，將觸控事件重新解讀為滑鼠事件 與不支援觸控手勢的軟體相容。
  • 擴充性： Fuchsia 可加入新的輸入模式，
    • 雖然產品有很大不同的輸入需求，但可能需要進行調整 應該可以支援新的輸入法 而不必重寫現有的輸入堆疊

激發靈感的例子

這些使用案例尚未涵蓋所有用途，但有助您深入瞭解 此架構應支援的行為類型。

  • 當 UI 來自多個架構時，正確解讀觸控螢幕手勢 。
  • 在多個 文字方塊 (具有不同架構) 顯示於螢幕上。
  • 允許特定按鈕組合 (例如同時調高和調低音量按鈕) 除了這些按鈕的正常功能以外，也會觸發恢復原廠設定程序。
  • 在裝置休眠或關上時，在筆記型電腦的觸控螢幕上隱藏輸入來源。
  • 解讀筆電觸控板手勢 (雙指撥動縮放、雙指捲動)。

背景與術語

  • 人機介面裝置 (HID) - 可將輸入和輸出端輸出到 使用者，例如鍵盤、滑鼠、觸控螢幕或消費性控制 (按鈕)。通常這是指使用 USB-HID 的裝置 規格。
  • 輸入事件：單一使用者輸入事件，例如按鍵、滑鼠移動 動作或觸控事件這些事件經過處理時，可能會加註 根據目前背景資訊而提供額外資訊
  • 指標事件 – 對應至特定位置的使用者輸入事件 例如觸控或滑鼠事件等指標事件是輸入的子集 事件。
  • 事件串流 - 一般發生的一組相關輸入事件 相輔相成
  • 輸入處理常式 — 是執行單一輸入階段的軟體 和資料處理之間輸入處理常式接受輸入事件做為輸入，並發出輸入內容 事件。它可能會修改事件，或與 有些人會將 Cloud Storage 視為檔案系統 但實際上不是
  • 輸入管道演算法 – 這個演算法須連結多個 處理 Fuchsia 輸入的一系列輸入處理常式。這項行為與政策 啟用 Fuchsia 的輸入層
  • 輸入管道實作 - 輸入管道實作 演算法。實際上，這是負責 fuchsia.git 的元件 將驅動程式庫層級的使用者輸入事件轉送至系統的其他部分。
  • Scenic - Furchsia 圖形引擎。景觀部門也負責 用於轉送指標事件
  • 「全球場景圖」：透過圖形轉譯的一系列圖像內容， 風景。
  • View - 場景圖中的子空間。通常觀看次數 對應螢幕上的區域，但這個區域不一定 長方形。
  • ViewRef - 與某個事件配對相關聯的 特定檢視表用於識別多個 Fuchsia 的檢視區塊 元件。

架構總覽

此設計可提供使用者輸入事件的整體流程總覽 但並未涵蓋所有 。其中許多細節都在 。

由下而下：dev/class/input-report ->輸入管道 ->{ Scenic 或 11y 管理員或 IME 管理員「或」媒體按鈕監聽器} ->{Chromium OR flutter OR Carnelian} ->{View 1 OR view 2 OR view3 OR view 4}側邊：產品工作階段 元件 ->{輸入管道或根情境元件} 根場景元件 -> 風景秀麗的美景：焦點管理員、場景圖 (有視覺樹木 代表： 繫結 ->指標事件處理常式 ->無障礙捷徑處理常式 ->媒體按鈕處理常式 ->其他處理常式 ->輸入法編輯器處理常式 -> 備用

系統會依據幾項關聯規則來分派事件，這些規則包括 不限於：

  • 該事件類型的產品政策 (例如，將所有磁碟區事件調派至 設定)
  • 事件在畫面上的位置 (例如，輕觸或滑鼠)
  • 目前聚焦的檢視畫面 (例如輸入文字)

「輸入管道」是負責任命的 Fuchsia 元件 管理這些規則及其互動方式，以及轉送使用者輸入內容 傳送事件給相關系統服務 處理這些事件它會實作輸入管道演算法 鏈結的輸入處理常式，每個都會在裝置輸入中執行獨立步驟 資料處理)。此元件可做為 Fuchsia 輸入的政策層。 輸入管道會透過輸入管道，直接從驅動程式庫層擷取事件 驅動器，以及由測試和測試 軟體產生的事件，例如虛擬鍵盤的事件。

事件在從全域低階的輸入管道中移動時 事件 (沒有語意意義，但機密資料) 可透過 可以由使用者軟體 (手勢、 字元等)。驅動程式層級輸入事件大致分為兩類：

  • 與螢幕上特定位置對應的指標事件。
  • 按鈕和切換事件。

未來您或許可以擴大這個目標。USB-HID 用量表龐大且 含有多次模型，包括飛行模擬模式、練習題 以及虛擬實境裝置

驅動程式層級的輸入事件可轉換為：

  • 觸控手勢。
  • 滑鼠事件 (包括捲動)。
  • 文字輸入事件。
  • 語意無障礙功能操作。
  • 按鈕事件 (例如音量變更、攝影機開啟/關閉)。

每個事件的調度通常如下：

Driver -> Input Pipeline -> UI System Component -> UI Framework-> UI View
  • 輸入管道元件包含多個稱為「輸入」的內部階段 處理常式：輸入管道會做為輸入政策層，因此可能會有所不同 依產品類型篩選(請參閱輸入管道 自訂選項)。
  • UI 系統元件包括 Views、無障礙功能管理工具和輸入法編輯器 但日後可能會逐漸增加 平台。這些元件是 Fuchsia 平台的一部分， fuchsia.git.這些元件適用於各種產品。
  • UI 系統元件負責決定應使用哪個檢視畫面或檢視畫面 接收事件並傳遞至 UI 架構 執行調度工具UI 系統元件會使用 Views 中的資訊 (通常是「焦點鏈」)，藉此判斷應接收到哪個檢視畫面 事件。
  • UI 系統元件也可能會使用事件。
  • UI 架構目前包含 Flutter、Chromium 和 Carnelian。我們希望 日後也支援其他 UI 架構/執行階段。這些內容可能會 並不屬於 Fuchsia 平台。
  • UI 檢視畫面是圖形元件，擁有對應的畫面區域 稱為「檢視表」(請參閱檢視畫面和事件轉送)。 below.)
  • 媒體按鈕事件不一定會遵循這個模式。最終目的地 可能是設定服務，而非 UI 檢視畫面。

在某些情況下，事件可能經過額外階段才會完成最終傳送。 舉例來說，觸控事件可能會透過 View 傳送到虛擬 產生合成按鍵，然後 也可能會透過輸入管道調度

輸入管道會將指標事件傳送至 View，負責 將事件分派到正確的執行階段執行個體。如此一來，View 就會 以一致的方式瞭解畫面內容的所在位置 避免動畫播放期間發生競爭狀況(請參閱轉送圖表 事件)。

設計

輸入事件來源

輸入事件通常會透過輸入驅動程式進入系統，或 透過 Fuchsia 元件作為輸入裝置的控制器 (例如藍牙 HID 裝置的 bt-host 元件)。在許多情況下 做為人機介面裝置 (HID) 事件啟動 例外狀況。駕駛人和控制器發出每個事件時 fuchsia.ui.input/InputReport.一般來說，輸入報表會 並由輸入管道進行轉換但在復原模式中 會透過使用 Cloud Shell 的指令列 Carnelian 不必經過任何中介處理

用於測試的輸入事件會以不同方式產生。(請參閱測試 below.)

輸入管道

「輸入管道」元件是 Fuchsia 系統元件。這項服務 實作輸入管道演算法輸入管道元件 讀取輸入堆疊中的政策層負責決定 特定裝置支援的事件類型，以及輸入事件應如何宣告 以及管理輸入裝置

輸入管道演算法由以下項目組成：

  • 一種繫結階段，轉換一流的 InputReporting 串流 (內含無 系統狀態) 串連成 InputEvents (可能包含 系統狀態) 後方。
  • 一系列 InputHandlers 可能會修改和/或耗用 以便將這些 InputEvents 分派到其他元件。
  • (選用) 處理未處理 InputEvents 的備用階段。

繫結階段通常會運用 裝置狀態。例如：

  • 包含相對滑鼠移動的 InputReport 會變成 螢幕相對座標
  • 按鍵按下 InputReports 成為「鍵下」串流和「鍵向上」 InputEvents。(驅動程式通常只會回報按鍵位置在指定的 時間，而不是區分上下事件)。「索引鍵」可以是 透過後續的 InputReport 推斷出。

產品如何使用輸入管道理論可由 Fuchsia 產品 工作階段元件 ，直接在 Google Cloud 控制台實際操作。不過， 輸入管道不會在工作階段領域中執行輸入管道是 比工作階段更多特權的元件，以及使用 這裡會顯示目前不想向工作階段元件公開的功能

輸入管道實作項目會做為產品擁有者 Fuchsia 平台。截至此 RFC 的出版物上，這些實作方式 透過 Rust 和輸入處理常式編寫的類別 InputHandler Rust 特徵，不過日後可能會改變， 確保最佳化並提高擴充性

平台目前提供兩種輸入管道實作， 針對主要仰賴觸控螢幕互動的裝置進行最佳化 以滑鼠和鍵盤為中心選取屬性本有限度 我們日後可能會擴充自訂功能(請參閱「輸入管道」 自訂)。

輸入處理常式

輸入處理常式 代表一系列的輸入階段 和資料處理之間輸入處理常式是讓產品擁有者使用的主要機制 自訂與產品狀態相關的輸入處理方式。我們有時也提到 做為輸入事件的產品政策輸入處理常式可能會

  • 新增情境資訊 (例如 鍵盤配置，或同時按住哪些按鍵以及滑鼠 點擊)。
  • 根據周遭事件串流調整事件 (例如輸入平滑、 觸控板手勢)。
  • 在處理常式內或將事件傳送至服務，即可處理事件 由 UI 系統元件公開，然後由 UI 系統元件 將該事件套用至適當的 UI 檢視區塊組合。目標資料檢視或資料檢視 取決於「風景」中的目前的檢視焦點(請參閱下方的「聚焦」一節)。
  • 傳送 OutputReports 控制輸入裝置狀態 (例如設定大寫 LED 燈)。

短期內，我們定義了一個 Rust 特徵 InputHandler，必須 由每個輸入處理常式實作如果是長期下來，可以換成 FIDL 介面。每個處理常式都必須能使用輸入事件。 應輸出輸入事件的向量 (可能為空白)。

#[async_trait]
pub trait InputHandler: Send {
    /// Returns a vector of InputEvents after handling `input_event`.
    ///
    /// # Parameters
    /// `input_event`: The InputEvent to be handled.
    async fn handle_input_event(
        &mut self,
        input_event: input_device::InputEvent,
    ) -> Vec<input_device::InputEvent>;
}

日後建構於 Fuchsia 產品時可能需要的輸入處理常式範例 (部分 都很吸引人)：

  • 無障礙輸入處理常式：在相關情況下將事件傳送給 11y Manager 無障礙功能 (例如切換導覽功能或使用螢幕閱讀器) 鍵盤快速鍵)。
  • 快速鍵處理常式：決定鍵盤事件是否與進行中 鍵盤快速鍵 (可呼叫其他元件)。
  • 語言代碼處理常式：套用目前使用中語言代碼的相關資訊 檢視畫面。
  • Pointer Event Dispatch Handler：將觸控/滑鼠/觸控筆事件傳送至 Views 分派給檢視畫面
  • 媒體按鈕處理常式：將媒體按鈕轉送至設定服務 (或 其他位置)。
  • 鍵盤版面配置處理常式：在目前使用中為鍵盤事件加上註解 鍵盤配置。
  • TouchPad 手勢處理常式：觸控板手勢和轉寄對等的滑鼠 事件。
  • 輸入流暢處理常式：透過平均事件減少時基誤差。
  • Focus Handler：使用 ViewRef 為目前的鍵盤事件加上註解 聚焦於焦點所在。
  • 睡眠模式處理常式：在裝置休眠時隱藏輸入。
  • 多點觸控鬆動 Iron Magic Button 處理常式：解讀觸控手勢事件 做為媒體按鈕使用

在許多情況下，輸入處理常式會將事件分派給 Fuchsia 系統服務 例如 Views、無障礙功能管理工具、輸入法編輯器管理員等在本 案件就會標示為「已處理」並傳播到 其他部分(請參閱事件串流 一致性)。

輸入管道自訂功能

指定要納入的處理常式，將輸入管道例項化 顯示順序。這項操作會新增處理常式、重新排序 處理常式或將已修改的管道例項化，輕而易舉。範例： Rust：

async fn input_handlers(
 ...
 ...
) -> Vec<Box<dyn InputHandler>> {
    let mut handlers: Vec<Box<dyn InputHandler>> = vec![];
    // Shortcut needs to go before IME.
    add_shortcut_handler(&mut handlers).await;
    add_ime(&mut handlers).await;
    add_touch_handler(..., &mut handlers).await;
    add_mouse_handler(..., &mut handlers).await;
    handlers
}

2021 年，平台提供兩種輸入管道實作 都以元件形式導入 fuchsia.git 以利用 特殊權限 API 並未在 Fuchsia SDK 中發布。這些實作方式 許多輸入處理常式 (它們執行相同的程式碼) 且主要在 以及支援的輸入模式一種實作方式適用於 主要透過觸控螢幕互動，以及以另一種為產品為主 就能快速完成操作只能使用產品專屬代碼進行設定 將處理常式執行個體化。

短期內，只有 公開能力 (可能以 FIDL API 的形式供設定使用) 中介層) 以讓工作階段決定 指定要啟用的輸入模式這個 API 可讓 且會在工作階段啟動時生效 (例如 以及產品使用者體驗等設定並沒有意圖「在 飛行」在一般產品期間重新設定管道 作業。

隨著 Fuchsia 逐漸擴大支援其他產品類別， 和不同的產品設定可能會擴大 為了讓工作階段能力 或直接設定要使用的輸入項目 管道階段，應該以什麼順序呈現。有些輸入處理常式可能是 且必須住在 fuchsia.git 之外。

每項產品應能使用符合產品需求的輸入管道 特定需求，由支援該產品/服務的相關輸入處理常式組成 輸入行為具體做法並不包括 RFC。理想情況下，任何這類設定解決方案都會利用 平台提供的結構化設定機制 而不是發明特定資訊，因此應該免令人困惑 公開符合產品要求的最低設定介面 系統會按照資料類型和業務需求 將資料儲存到不同類型的儲存空間

檢視畫面和事件轉送

Fuchsia UI 可以在螢幕上以 讓應用程式從可以最快做出回應的位置 回應使用者要求UI 會整理成「全域場景圖」，擁有 風景：包含構成 UI 的圖形內容， 並提供轉譯所需的資訊執行階段可以提供使用者可見的內容 新增至場景，稱為檢視區塊 是否已安裝在場景圖中一般來說，檢視表會對應至 但這些區域不一定是矩形 特定時間的瀏覽次數。因為每個檢視都是風景本機資源 且不適合在其他元件中參照，我們會將核心 名為 ViewRef 的物件，其中包含每個檢視畫面。

檢視畫面以階層方式整理，而子項檢視畫面只能影響螢幕畫面 房地產父項檢視畫面邊界內的房地產，即嚴格遏制 "如果圖表是圖表中另一個檢視畫面的父項，就會是父項檢視畫面 保有對子女的特定控制權，特別是與內容相關的 以便安排刊登位置和事件轉送

查看樹狀結構

下圖說明場景圖根層級的結構。

根層級 ->無障礙檢視畫面 ->sysUI ->{尚未對部分資料檢視進行測試 其他檢視畫面}

  • 與無障礙管理員相關聯的檢視畫面允許使用 以便攔截無障礙服務所需的輸入事件，以及 或將焦點移至頂端其餘部分 無從得知
  • 「sysUI」(系統 UI) 檢視畫面是所有其他檢視畫面的父項。這個檢視畫面 通常用於實作「系統手勢」(例如在螢幕邊緣滑動) 以及系統鍵盤快速鍵。這個模型也用於 許多非輸入層面的使用者介面

轉送圖像事件

針對對應至特定畫面位置的使用者事件 (例如觸控、 滑鼠、觸控筆) 輸入事件時，輸入事件會先經過 View 路徑轉送，再分派到 以及與每個檢視畫面相關聯的執行階段執行個體這種方法的優點包括

  • 場景圖隔離：僅有完整的場景圖 以便瞭解畫面上的位置我們不允許其他 元件來查詢特定點畫面上的內容 (也稱為 「命中測試」)。
  • 全球一致性：由於「風景」是特定地點的可靠資料來源 在特定時間顯示檢視，並避開景觀派遣事件 檢視在時間之間大小、位置或消失的問題 表示輸入事件發生的位置和傳送時間。這在 以便快速更新時，使用者 與裝置互動請注意，ViewModel 也擁有焦點鏈， 用於保持非指標事件的分派一致。
  • 平行調度 (手勢消歧)：檢視畫面重疊時， 與特定事件串流相關的多個資料檢視。例如產品 可以導入「系統手勢」例如滑動關閉 而應用程式本身可能會解讀該手勢 有差異。觀看次數會決定應接收何種檢視畫面 產生指定事件，並透過名為「手勢」的程序在兩者之間進行中介服務 消除歧義。在這個模式下，觸控事件串流會 ，則以「手勢競技場」解決到 以決定最終會使用事件串流的資料檢視。

焦距

為了判斷目前執行中的軟體，應該收到 我們需要瞭解檢視焦點這是概略的 目前處於「有效」並準備好接收事件不過在實務上 可能會對每個事件感興趣。

檢視焦點是透過「焦點鏈」決定 ( 在檢視畫面中，聚焦檢視畫面及其祖系的 ViewRefs 樹狀結構)。焦點鏈的擁有者為景觀鏈 (因為風景管理會管理檢視畫面)，但 其他元件可能會要求變更目前焦點，例如 回應無障礙功能動作或鍵盤快速鍵的回應。輸入管道 負責監控焦點鏈中的變更，並提供 傳送給輸入處理常式的資訊，可能會進一步將事件轉送至正確的 用戶端元件/檢視畫面焦點鏈的終端機元素會對應至 顯示目前聚焦的檢視畫面

有些處理常式需要只聚焦於單一的檢視畫面，而其他處理常式則會希望 關注整個焦點鏈例如：

  • 未觸發鍵盤快速鍵的鍵盤事件通常會轉送至 顯示目前聚焦的檢視畫面
  • 無障礙管理員會使用聚焦檢視畫面判斷目前使用的內容 「有效」以及螢幕閱讀器朗讀。
  • 鍵盤快速鍵管理員只適用於整個焦點鏈， 裝置可能已註冊鍵盤快速鍵和相關優先順序。

聚焦事件會以特殊類型的 InputEvent 類型在輸入管道中移動 和其他輸入事件一起嚴格排序

事件串流一致性

事件串流是一組相關的 InputEvents，通常會進行 相輔相成例如：

  • 鍵盤：「a」主要向下 ->「a」金鑰向上
  • 滑鼠：懸停 ->懸停 ->BUTTON_DOWN ->BUTTON_UP
  • 觸控：手指朝下 ->移動 ->移動 ->移動 ->朝上

系統無法確保串流中各階段的事件串流一致 以及每項資料檢視這表示如果輸入處理常式使用 轉送至系統服務，則應傳送適當的「處理」事件 事件傳送至後續輸入處理常式，以便他們通知任何用戶端。

如果在處理事件串流期間聚焦變更，情況也會維持不變。來源： 用戶端的立場思考必須與對應的「鍵」 向上或「取消」事件。 滑鼠點擊和觸控事件串流也是如此。輸入管道 負責將事件標示為「已處理」然後透過 確保串流一致性系統服務負責 並在串流取消時通知觀看次數。

成效

可接受的延遲時間

使用者輸入內容具有時效性，延遲時間 (也就是事件發生時 發生於 UI 回應時)) 應該盡可能低，不過 使用者延遲時間的容忍度因輸入類型而異。使用者可能會遇到效能降低的情形 以及他們是否能夠完成工作) 以及滿足延遲時間 某些情況下為 10 毫秒。使用者體驗開始明顯低於 100 毫秒 可能超過 300 毫秒直接操作 (例如 特別容易發生延遲情形，而且可能需要預測事件 為使用者提供可接受的體驗(請參閱延遲 文件)。

因為此 RFC 描述的輸入系統以低於 以及建構在容器上的 UI 以及因時間處理與轉譯 回應輸入事件因此，輸入系統應盡可能快速 請盡可能將「延遲預算」盡可能為應用程式 和執行階段

此外，時程一致也很重要。即使平均活動送達時間 低，事件時間變化的經常性會對使用者體驗造成負面影響，因此 請務必觀察延遲分佈和平均值

提升效能

減少輸入架構延遲時間的最佳做法就是 不需要程序內容切換每次進入和結束核心時 通常會需要執行排程器，並將可變性轉換為 事件時間。

日後我們可能會嘗試在圖像中執行多個元件 輸入堆疊 (例如景觀和輸入管道) 做為個別元件中的 單一程序來進一步減少程序躍點我們也可能會重新考慮 如果發現這種情況，可將 Rust 做為輸入管道的實作語言 就會產生額外的延遲時間

我們導入了消除手勢消除 (又稱為平行調度)， 等候的時間可能會拉長 來回應指定事件串流為了 演算法才有成效，客戶必須合作及迅速回應輸入 事件。系統必須具備某些機制來指定和強制執行用戶端 預期的延遲時間 (服務水準協議)我們會在日後的設計中進一步說明。

國際化與輸入情境

每個檢視畫面都有自己的輸入背景資訊，其中包含有效的 輸入項目 method (「使用中的鍵盤」)。輸入內容的背景資訊 資訊 fuchsia.intl.Profile 包含使用者偏好的語言代碼，且會影響 UI 簡報不過，使用者的語言代碼設定可能會影響哪個輸入來源 方法/鍵盤版面配置。請參閱《Fuchsia 國際化》 說明文件，進一步瞭解 Fuchsia 國際化。

系統應允許不同檢視畫面使用不同的輸入值 方法。舉例來說，使用者在聊天時可能會使用某種語言撰寫電子郵件 和其他語言的翻譯。產品可選擇強制使用單一系統通用的語言代碼 或主動的輸入法，但架構必須支援 相關資訊很有可能想知道如何儲存這些設定 而負責任的 AI 技術應運而生。

除了將事件轉送至右側檢視畫面外，輸入管道 ( 而 IME Manager 等相關聯的系統元件 您在解讀輸入事件時預測檢視區塊舉例來說，輸入管道 為實體鍵盤活動加上註解，提供鍵盤配置的相關資訊 發生事件。與焦點相同 變更時，對使用中的鍵盤配置的變動應視為輸入事件 並與其他事件依序處理，避免使用 變更狀態

無障礙設定

為了讓使用者不受能力限制使用 Fuchsia 裝置， Fuchsia 無障礙架構提供多種無障礙功能， 修改使用者與裝置互動的方式。具體來說，這項功能可啟用以下功能：

  • 「放大」的放大鏡部分或全部的使用者介面
  • 可讓失明或低視能使用者探索及互動的螢幕閱讀器 無需透過「語意樹」使用視覺化輸入對應至目前的使用者介面

啟用這兩項功能或同時啟用後，無障礙管理員就會需要 透過輸入管道攔截輸入事件，並將其解讀為指令 以及目前啟用的無障礙功能這些指令可使用 依裝置類型而異舉例來說 螢幕閱讀器主要是透過鍵盤快速鍵操控， 觸控螢幕裝置上的閱讀器可能會使用多次輕觸和滑動操作。視情況而定 無障礙功能管理員可能會 決定只消耗部分事件 (例如放大鏡中 會耗用部分手勢，但允許他人傳遞到 UI)。 事件 (螢幕閱讀器會將事件轉譯為語意， 動作)。

無障礙管理員會維持與每個檢視畫面的連結 透過 語意 API、fuchsia.accessibility.semantics。例如「輕觸兩下」 通常會以 語意「預設動作」套用至目前所選的語意節點

安全性考量

在輸入管道和相關系統元件的情況下， 沒有在 SDK 中發布且具有特殊權限的 API。要求使用工作階段 用於輸入處理的輸入管道，平台可以限制 外部軟體可用的功能

此外，您也必須考量 UI 阻礙攻擊，例如 點擊劫持。誤導的輸入事件會在沒有相關用途的情況下授予權限 使用者的同意聲明 (例如將點擊轉送到惡意網站上的按鈕)。 雖然難以在平台層級完全防範，但輸入內容 架構必須確保圖像事件只會傳送至正確的 UI 讓產品所有人輕鬆瞭解 輸入事件

隱私權注意事項

對輸入管道所做的變更應經過隱私權審查，因為 使用者輸入內容可能會讓攻擊者建立鍵盤側錄程式或其他惡意程式碼 軟體除了復原模式之外，輸入管道應該是 然而，只有元件允許直接從驅動程式庫輸入事件來防止 而負責任的 AI 技術做法 有助於達成這項目標

測試

測試輸入管道

應使用密封的整合測試來驗證平台輸入行為 對應支援的輸入功能 (例如觸控輸入、鍵盤快速鍵) 獨立於使用這些功能的產品程式碼測試應使用 每個支援的執行階段中最基本的圖形元件，以驗證相關的 功能。如要確保功能穩定性與特定產品無關， 重要的是，開發人員可以透過 樹狀結構外 I 技術打造產品

遺傳測試涉及的難題多不勝過 RFC。

測試所有其他項目

端對端測試主要仰賴合成輸入事件來促成使用者互動 以便進行測試雖然大部分的 UI 架構都包括 插入事件 (例如 Flutter 驅動程式) 不足以測試任何 牽涉到多個執行階段也就是說 Fuchsia 提供適當的 API，用於建立假輸入。您可在 透過 SL4F 與 Fuchsia 輸入合成程式庫，可將事件插入 透過專屬插入 API 實作輸入管道這個 API 應僅適用於 但不得用於正式環境 任意輸入內容

輸入產業

支援各種類型的輸入裝置，會增加複雜度 排除在本文所述的整體架構這些詳細資料 並在後續 RFC 中獲得解決主要輸入產業包括：

  • 實體鍵盤 (藍牙和 USB)
  • 虛擬或螢幕小鍵盤
  • 滑鼠
  • 觸控
  • 觸控板

說明文件

此 RFC 內容應加入 Fuchsia 公開說明文件 以及實作詳情

考慮的替代方案

本節將說明其中一部分 (多種) 替代方案。

將根簡報者轉變為管道

一直以來，Sight 負責調度所有使用者輸入事件。 包括沒有圖形/位置元件的鍵盤事件。這是 目前用於某些產品設定，但鍵盤事件 已移除root 中現有的輸入處理程式碼 可以擴充簡報者 用途不過，這個程式碼缺少測試涵蓋範圍，因此需要 大幅改寫作業來提供想要的一致性和特性 以及移除輸入處理和 圖形 API

特定產品一覽

因為輸入內容 (尤其是指標型輸入內容) 與 其中一個選項探索會轉送輸入處理 Scenic，F Fuchsia 圖形引擎。這個架構是 從目前狀態出發的激度。這個版本的合成器 在「立即模式」時將水分排除在風景區外意味著它必須繪製 任何時候都是由視窗管理員進行變更檢視畫面會成為視窗管理員 預設是產品專屬的元件，需要 每種產品類別都有不同的導入方式輸入內容會透過這個位址轉送 元件。

雖然這種做法可以在任何單一產品中順利運作，但需要有人輸入內容才能正常運作 自訂要放入圖片中的個別產品 。這可能表示必須採用專門的 View 實作 為每個新產品類型建立這個做法可能是 但認為對目前用例的重量過大。