什么是窗口系統
窗口系統的作用,是提供一種機制,在同一塊物理屏幕上使多個應用界面能夠顯示和交互。窗口作為應用的界面顯示容器,各應用程序的開發者只需要實現被分配部分的顯示區域內的交互界面即可,窗口系統會將這些交互界面組織成最終用戶見到的形態。 對應用開發者而言,窗口系統提供了界面顯示和交互能力的抽象;對用戶而言,窗口系統提供了控制應用界面的方式;對整個操作系統而言,窗口系統提供了不同應用顯示界面的組織管理邏輯。
為什么我們需要多窗口能力
對個人辦公電腦這樣的生產力設備而言,用戶需要同時顯示多個應用以提升辦公效率,并且用戶已經十分習慣了多個窗口層疊排布的組織形式,這也是主流桌面系統都在采用的窗口形式。
對移動終端而言,實際上大部分時候用戶仍然在使用多窗口,比如在 OpenAtom OpenHarmony(以下簡稱“OpenHarmony”)中,狀態欄、導航欄、壁紙也是獨立窗口,當用戶在桌面上時實際上已經存在 4 個窗口了。使用普通應用時的多窗口場景則包含分屏模式以及懸浮窗功能。對某些特定場景而言,多窗口功能也是十分重要的,例如車機在導航場景時,如果還需要進行其他任務,就需要進入分屏模式。
OpenHarmony多窗口框架介紹
對 OpenHarmony 來說,一個明顯的挑戰是 OpenHarmony 所面向的設備形態是不確定的,從幾百兆內存的嵌入式設備,到個人辦公設備,都有可能在 OpenHarmony 需要支持的設備范圍之內,而這些設備對多窗口的訴求差距較大,因此 OpenHarmony 窗口框架的目標是提供構建這些設備圖形界面所需要的能力,但又盡可能保持足夠的靈活性,允許系統進行策略配置或者二次開發來達成各自不同的訴求。
OpenHarmony窗口框架職責介紹
在 OpenHarmony 中,窗口系統主要負責以下職責:
?提供應用和系統顯示界面的窗口抽象:
為了將圖形界面顯示在屏幕上,應用和系統需要向窗口系統申請窗口對象,這通常代表了屏幕上一塊矩形區域,具有位置、寬高和疊加層次(Z 軸)屬性。同時,窗口對象也負責加載界面中 UI 框架的根節點,應用程序的 UI 界面就通過這個根節點在窗口中加載顯示。
?組織不同窗口的顯示關系,包括疊加層級和位置屬性:
窗口系統維護不同窗口間的疊加層次。應用和系統的窗口具有多種類型,不同類型的窗口具有不同的疊加層次(Z 軸高度)。窗口系統負責給不同類型的窗口定義默認的層次范圍,并根據用戶操作更新窗口層次,即用戶的操作也可以改變用戶窗口的疊加層次。例如,通過點擊或者觸摸操作,用戶可以將選中的窗口在用戶界面的前臺展示。
窗口系統維護不同窗口的位置屬性。窗口系統負責給不同類型窗口定義默認的位置和大小,并根據應用層對于窗口位置和大小的偏好設定進行實際調整。不同的窗口類型有不同的默認位置和大小。例如,導航欄、音量條、壁紙等系統窗口均有各自固定的顯示位置和窗口大小,而應用窗口的顯示位置和顯示大小則可以根據窗口顯示模式和用戶操作在一定范圍內調整。
?設置窗口裝飾:
在自由窗口等模式中,窗口系統會通知 ArkUI 在應用窗口外部增加窗口裝飾。窗口裝飾通常包含對窗口進行最大化、最小化及關閉按鈕等界面元素,方便用戶進行操作。
?設置窗口動畫:
在窗口顯示、隱藏、和窗口間切換時,通常會有一組動畫效果使得整個交互過程更加連貫流暢。窗口系統負責設置窗口的動畫參數,完成動畫效果。
?指導輸入事件分發:
輸入事件通常可以分為指向性輸入(如觸摸事件、鼠標事件)和非指向性輸入(如按鍵)。指向性輸入事件通常與顯示屏的某個坐標關聯,事件分發時需要根據當前窗口系統的狀態,將事件分發給在這個位置顯示的窗口;非指向性輸入事件則通常與當前的焦點窗口關聯,事件分發時需要根據當前的焦點窗口,將事件分發給當前的窗口。
?組織窗口內容的顯示:
各應用輸出的顯示內容,最終會被組合成一張顯示畫面輸出給物理屏幕,而窗口系統負責向 RenderServer 提供每個顯示內容的位置、大小、層級,使得每個界面被正確組合。
OpenHarmony窗口類型定義
OpenHarmony 的窗口分為系統窗口和應用窗口兩個類別,而應用窗口又分為應用主窗口和應用子窗口兩種類型。
系統窗口
系統窗口指完成系統特定功能的窗口類型。通常來說,系統窗口不允許三方應用創建,也不是由界面 Ability 默認創建,而是由系統應用手動添加的。
系統窗口可以被系統應用直接添加、移除、改變大小,系統應用的直接操作給予系統應用足夠的靈活度應對不同產品和 UI 設計的變更。
應用主窗口
應用主窗口是由界面 Ability 默認為應用創建、加載的,用于顯示應用界面的窗口類型。應用主窗口會在任務管理界面中被顯示。
應用輔助窗口
應用輔助窗口是基于應用手動創建的,用于顯示應用的彈窗、懸浮窗口等內容的窗口。應用輔助窗口不會在任務管理界面中被顯示。在應用獲取權限后,允許應用輔助窗口在應用主窗口不再顯示后繼續在前臺懸浮顯示
OpenHarmony應用窗口模式
應用窗口模式指的是應用主窗口的顯示方式,這也是大部分用戶所理解的“多窗口能力”。OpenHarmony 3.1 Release 中,支持以下三種應用窗口模式:全屏、分屏、自由窗口
全屏模式
全屏窗口是手持設備和嵌入設備中最常用的窗口模式,OpenHarmony 中的全屏模式具有以下特征:
1. 全屏窗口默認情況下鋪滿狀態欄導航欄之外的整個屏幕區域(見沉浸式章節)
2.同一時間內,每個屏幕上僅存在一個活動狀態的全屏窗口,新的全屏窗口被啟動,舊的全屏窗口默認被切換到后臺(而不是被遮擋)
分屏模式
分屏模式主要在平板和個人電腦中使用,OpenHarmony 中的分屏模式具有以下特征:
1. 分屏窗口默認占據屏幕的某個部分,OpenHarmony 3.1 Release 中,支持二分屏能力;
2. 兩個應用分屏窗口具有分界線,用戶可以通過拖拽分界線同時調整兩個部分的窗口尺寸。
自由窗口模式
自由窗口是個人辦公設備的標志性多窗口形態,OpenHarmony 中的自由窗口模式具有以下特征:
1. 自由窗口的大小和位置可自由改變;
2. 同一個屏幕上可以同時顯示多個自由窗口,它們按照打開順序或者獲取焦點的順序在 Z 軸排布;
3. 自由窗口被點擊或觸摸將導致自由窗口的 Z 軸高度提升,并獲取焦點。
OpenHarmony沉浸式能力
沉浸式能力,指的是對狀態欄、導航欄等系統窗口進行控制,從而使用戶獲得最佳設備使用體驗的能力。狀態欄和導航欄是獨立的窗口,它們由特定的系統應用(通常是 System UI)進行添加,狀態欄和導航欄所承載的內容和功能不在窗口系統中展開,這里僅表述該窗口與應用的窗口相關的行為。
在默認情況下,全屏應用和分屏應用使用的屏幕區域為除去狀態欄導航欄外的可用區域。為了讓應用能盡量使用屏幕的顯示區域,應用可以通過沉浸式接口將狀態欄導航欄隱藏,即占據全屏大小的應用的窗口大小與屏幕大小一致,分屏的應用的窗口大小則按比例分割屏幕大小。這在進行全屏播放視頻等場景時是非常常用的。
除了隱藏狀態欄、導航欄外,還可以將應用的布局設置到狀態欄導航欄的下方,這樣應用就可以作為半透明狀態欄導航欄的背景存在,使用戶獲得更好的體驗。
應用也可以獨立設置(https://gitee.com/openharmony/docs/blob/master/zh-cn/application-dev/reference/apis/js-apis-window.md#setsystembarproperties)狀態欄導航欄的文字顏色和背景顏色,這樣就可以使得應用顯示時系統整體的界面風格統一。
以上是對OpenHarmony窗口管理框架的簡單介紹。OpenHarmony 窗口管理框架和多窗口能力還在不斷持續的開發演進中。對 OpenHarmony 窗口框架感興趣的小伙伴,可以從以下鏈接獲取窗口管理代碼進行深入了解:https://gitee.com/openharmony/windowmanager。也希望更多開發者一起加入進來,與OpenHarmony共同成長。
有興趣進行 OpenHarmony 應用開發的小伙伴,也可以通過以下鏈接了解 OpenHarmony 的窗口管理相關接口:
https://gitee.com/openharmony/docs/blob/master/zh-cn/application-dev/reference/apis/js-apis-window.md。
審核編輯 :李倩
-
嵌入式
+關注
關注
5138文章
19524瀏覽量
314652 -
應用程序
+關注
關注
38文章
3322瀏覽量
58691 -
OpenHarmony
+關注
關注
26文章
3820瀏覽量
18101
原文標題:OpenHarmony 3.1 Release版本關鍵特性解析——構建OpenHarmony窗口框架
文章出處:【微信號:gh_e4f28cfa3159,微信公眾號:OpenAtom OpenHarmony】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
KaihongOS操作系統FA模型與Stage模型介紹
AI開發框架集成介紹
OpenHarmony程序分析框架論文入選ICSE 2025

第三屆OpenHarmony技術大會星光璀璨、致謝OpenHarmony社區貢獻者
控制臺窗口主機是什么
基于ArkTS語言的OpenHarmony APP應用開發:多媒體管理2

基于ArkTS語言的OpenHarmony APP應用開發:窗口管理
基于ArkTS語言的OpenHarmony APP應用開發:HelloOpenharmony

基于ArkTS語言的OpenHarmony APP應用開發:簡易計數器
第二屆大會回顧第24期 | 面向OpenHarmony的軟件工程研究:機遇與挑戰

評論