Stage模型深入解讀
HarmonyOS 3.1版本(API 9)推出了全新應用開發模型-Stage模型,該模型重新定義了應用開發的能力邊界,從應用開發模型的角度,支援多視窗形態下統一的應用元件生命週期,並支援跨裝置的遷移和協同機制。本文為大家詳細介紹Stage模型。
一、Stage模型概念
應用開發模型是執行在不同OS上的抽象結構。OS通過這種抽象結構,把應用開發的基礎設施封裝在OS內部。開發者通過使用應用開發模型,複用OS基礎設施的能力,達到高效開發應用的目的。
1、什麼是Stage模型
Stage模型提供面向物件的開發方式,規範化了程序建立的方式,提供元件化開發機制,將元件抽象為UIAbility和ExtensionAbility兩大類。UIAbility元件的生命週期包含建立、銷燬、前臺、後臺狀態,將與介面強相關的獲焦、失焦狀態都放在視窗管理物件中,從而實現UIAbility與視窗之間的弱耦合;在服務側,視窗管理服務依賴於元件管理服務,前者通知後者前後臺變化,這樣元件管理服務僅感知前後臺變化,不感知焦點變化。ExtensionAbility元件提供場景化的服務擴充套件機制,不提供自定義服務的能力。
相比於FA模型,Stage模型提供了更靈活的開發方式,更低的記憶體佔用和更規範化的系統管理機制。
未來HarmonyOS將在相容FA模型的基礎上,持續演進Stage模型。
FA模型與Stage模型對比圖
2、Stage模型能力特點
Stage模型能力示意圖
Stage模型的設計,是為了提供給開發者一個更好的開發方式,更好的適用於多裝置、分散式場景。
Stage模型的三大能力特點:
1)原生支援元件級的遷移和協同
Stage模型的元件天生具備分散式遷移和協同的能力,它是HarmonyOS支援分散式能力在應用模型上的體現。
應用元件支援跨裝置的資料恢復:
充分使用ArkUI的宣告式UI和多頁面的能力,把資料/狀態儲存在UIAbility元件例項中,邏輯修改資料,資料驅動UI變化。多裝置間遷移UIAbility,就是遷移UIAbility的資料/狀態。在目標裝置上通過資料/狀態來恢復UI,實現邏輯與UI的解耦,提升了流轉開發效率。
應用元件支援跨裝置的遠端呼叫:
UIAbility元件支援跨裝置拉起另外一個裝置上同名應用的同名元件例項。系統在拉起過程中,通過底層軟匯流排的能力在兩個元件例項之間建立跨裝置的RPC連線,開發者在獲取RPC介面後,即可進行跨裝置通訊,適用於應用在裝置間互動的場景。
2)支援多裝置形態和多視窗形態
在桌面裝置上,視窗可以最大化/最小化/任意改變視窗大小,視窗間可以任意切換焦點,接收使用者輸入。在移動裝置上,基本以全屏視窗為主,視窗之間構成棧結構,只有頂層窗口才能接收使用者輸入。如何在不同視窗形態的裝置上,提供統一的元件模型呢?Stage模型分離了UIAbility生命週期和視窗顯示/焦點事件,使得視窗的焦點切換不影響UIAbility元件的狀態。
UIAbility的前後臺狀態和視窗的全屏/最小化的關係如下:
只有當視窗最小化的時候,UIAbility元件進入後臺狀態,否則UIAbility元件處於前臺狀態;
當一個視窗全屏的時候,觸發其他視窗最小化(可以根據產品形態確定全屏視窗個數)。
在桌面裝置和移動裝置的互動體驗不同的情況下,系統通過實施上述規則,可以保證UIAbility元件的生命週期定義在多裝置上保持一致。同時,不論在桌面裝置還是移動裝置,都遵循每個新的UIAbility元件例項都會建立一個任務,所以也保證了任務(Mission)機制在多裝置上的一致性。
3)重新定義應用能力邊界
通常情況下,應用如果可自行決定建立多少個程序、自定義服務時,系統為保證使用者體驗,需要在後臺執行管控、程序關聯啟動等方面對應用的執行狀態進行強管理,從而降低系統總體的記憶體佔用和功耗開銷。
Stage模型基於場景的服務擴充套件、嚴格的後臺管控機制和受限的程序模型,重新定義了應用能力邊界,使程序環境從“無序”到“有序”,規範了程序管理模型。
二、Stage模型介紹
基於Stage模型開發應用,下面將會從應用元件、程序模型、執行緒模型、任務模型、後臺執行機制、應用配置檔案6個方面進行介紹。
1、元件模型
應用開發模型中需要指明應用開發的入口。在HarmonyOS上,應用元件是應用開發的入口,同時也是執行時入口。使用者啟動、使用和退出應用過程中,應用元件會在不同的狀態間切換,這些狀態稱為應用元件的生命週期。應用元件提供生命週期的回撥函式,開發者通過應用元件的生命週期回撥感知應用的狀態變化。
Stage模型元件型別
Stage模型提供了UIAbility和ExtensionAbility兩種型別的元件。
1) UIAbility元件是一種包含UI介面的應用元件,主要用於和使用者互動。UIAbility的生命週期只包含建立/銷燬/前臺/後臺等狀態,通過WindowStage的事件暴露顯示相關的狀態。每個UIAbility元件都會有一個主視窗與之繫結,如果開發者希望開發複雜的頁面和動效,我們推薦開發者使用ArkUI的多頁面能力。UIAbility支援跨裝置拉起同名元件,並與之協同互動的能力。
2)ExtensionAbility元件是一種面向特定場景的應用元件,系統在特定場景下啟動該元件為使用者提供服務。開發者並不直接從ExtensionAbility派生,而是從ExtensionAbility的派生類派生。目前ExtensionAbility有用於卡片場景的FormExtensionAbility和用於輸入法場景的InputMethodExtensionAbility等多種派生類。在Stage模型上,普通應用開發者不能開發自定義服務,也不支援開發者直接啟動ExtensionAbility,包括開發者自己編寫的ExtensionAbility。
2、程序模型
程序模型示意圖
Stage模型有三類程序,是從系統總體資源佔用考慮,希望由系統負責應用程序的建立和銷燬。所以不支援應用自定義配置多程序,也不支援通過介面啟動程序。
1)主程序
開發者編寫的UIAbility入口及其依賴的程式碼都在該程序中執行。它是由UIAbility元件的啟動觸發建立的。
2)ExtensionAbility程序
開發者編寫的同一種類型的ExtensionAbility元件例項都會在同一個程序中執行。不同型別的ExtensionAbility元件例項則在不同的程序中執行。該類程序是由系統服務在特定場景下建立,並根據使用者對特定場景的使用,決定其何時銷燬。同時該類程序獨立於主程序建立,並且不支援與主程序之間進行IPC通訊。
3)Render程序
為了支援WebView的執行,每個應用只能建立一個Render程序用於執行WebView的渲染引擎。這個Render程序也是由系統負責建立和銷燬。
3、執行緒模型
HarmonyOS的原生應用開發語言為ArkTS。在應用程序啟動時,系統會在主執行緒上建立一個ArkTS的虛擬機器例項,然後載入和執行應用的入口程式碼。應用元件的生命週期回撥,輸入事件的分發,ArkUI的佈局等操作都會在主執行緒上執行,所以我們推薦開發者不要在主執行緒上執行單次耗時過長的操作,否則容易引發卡頓。
ArkTS通過提供Worker API支援併發程式設計。Worker有獨立的虛擬機器上下文,它與主執行緒是兩個不同的虛擬機器上下文。它們之間通過postMessage API進行通訊。這種基於訊息傳遞的併發模型與基於鎖的併發模型不同,需要開發者特別注意。
4、任務模型
使用者在操作應用的過程中,經常需要對已經操作過的應用進行切換,這些操作記錄(不同OS的操作物件定義可能不同)經常被稱為任務。應用任務管理模型需要定義任務的操作物件,以及任務建立和銷燬的方式和時機。
在HarmonyOS上,每次使用者啟動一個新的UIAbility元件例項,都會生成一個新的任務(Mission)。例如,使用者啟動一個視訊應用後,切換到“任務中心”介面,將會看到視訊應用這個任務,當用戶點選這個任務時,系統會把該任務切換到前臺,如果這個視訊應用中的視訊編輯功能也是通過應用元件編寫的,那麼在使用者啟動視訊編輯功能時,會建立視訊編輯的應用元件例項,在“任務中心”介面中,將會展示視訊應用、視訊編輯兩個任務。
任務(Mission)中記錄了元件和快照的資訊,並在系統中持久化。即使任務對應的元件例項銷燬,任務仍然存在。如果使用者從任務中心中選擇某個任務,任務對應的元件例項會被拉到前臺並獲焦,如果它對應的元件例項已經銷燬,系統會建立一個新的元件例項與之對應。
開發者在使用者互動設計上需要特別注意,避免產生過多的任務。如果開發者希望使用多個頁面互動,推薦使用ArkUI的頁面棧能力。
HarmonyOS的任務模型不提供任務棧的能力,每個應用可以有多個任務在任務中心呈現,不同應用的任務不會以棧的形式堆疊在一起,避免了不同應用間任務混淆不清的情況。
5、後臺執行機制
後臺執行示意圖
當應用的所有前臺UIAbility元件都進入後臺的時候,系統認為該應用進入後臺。應用在後臺執行的機制對裝置續航影響很大。HarmonyOS後臺執行機制的設計初衷是希望應用程序在系統規則範圍內執行,並使使用者可感知,避免應用程序在後臺執行,而使用者不感知的情況。我們提供瞭如下幾種後臺任務(Task):
1)短時任務
系統每天會給申請了短時任務的應用分配一定的後臺執行配額。
2)長時任務
系統定義了若干種後臺長時執行的任務型別,開發者需要在應用的配置檔案中配置,並需要上架稽核。這樣該應用在裝置上後臺執行的時候,就可以保持長時間執行,同時系統會通過使用者可感知的UI提示使用者有後臺程序正在執行。例如導航,錄音,音樂等場景。
3)無任務
預設情況下,應用不申請任何後臺執行方式,則會在應用程序進入後臺10秒鐘後被凍結掛起,應用無法收到外部非使用者操作事件。
4)閒時任務
對於一些CPU密集型,且對實時性要求不高的任務,比如科學計算等場景,系統提供了閒時任務機制。例如裝置充電等適當的時機嚮應用提供後臺執行的能力,開發者可以通過Work-SchedulerExtensionAbility使用該機制,系統會根據當前的系統狀態和使用者使用頻次決策喚醒時機。
5)託管任務
對於一些可以託管給系統執行的任務。比如下載等場景,系統提供代理任務的API,由系統代理實現任務,應用程序會處於凍結狀態。
6、應用配置檔案
Stage模型提供了全新的應用配置檔案,它包含應用資訊、應用元件資訊、許可權資訊、開發者自定義資訊等,這些資訊在編譯構建、分發和執行階段分別提供給編譯工具、應用市場和作業系統使用。
Stage應用模型是HarmonyOS應用開發的基礎架構,它從元件模型、面向物件開發方式、程序/執行緒模型等方面對FA模型進行了全面的優化,提高了應用開發效率。後續我們將在應用模型的基礎設施、大型應用開發、拓展應用形態、跨裝置能力和效能體驗等方面繼續打磨,支撐HarmonyOS應用生態拓展,廣大開發者加入進來,一起探索和創新,共建萬物互聯的應用生態。
未來將來,有跡可循!
- Stage模型深入解讀
- Hypium框架使能ArkTS應用高效測試
-
3.1版本
課程精華速覽第四期下 -
3.1版本
課程精華速覽第四期上 -
#HarmonyOS小課堂# 速覽
課程精華第三期:ArkTS基礎知識 -
#HarmonyOS小課堂# 速覽
課程精華第二期:應用程式框架 -
#HarmonyOS小課堂# 速覽
課程精華第一期:執行Hello World - HarmonyOS 3.1版本釋出,全面進入宣告式開發
- HarmonyOS開發者創新大賽 《蘑菇實驗室》案例——服務卡片(JS)開發步驟總結
- HarmonyOS 3釋出,華為帳號為使用者帶來協同一致的多裝置智慧體驗
- HarmonyOS3.0嚐鮮之關鍵Js Api--ServiceAbility開發
- HarmonyOS應用開發:鴻蒙Js實戰,計算器功能開發!
- HarmonyOS應用開發:鴻蒙自定義元件slot插槽,體現的更強大!
- 【HarmonyOS議題資料下載】HDD杭州站·線下沙龍專注應用創新 展現鴻蒙生態魅力
- HarmonyOS api8 ArkUI正式釋出於杭州HDD線下沙龍
- 【Codelabs挑戰賽—定製訊息和配置】HarmonyOS定製告白訊息
- ImageKnife元件,讓小白也能輕鬆搞定圖片開發
- 敲重點!這些更新將會影響原子化服務上架
- 【OpenHarmony移植案例與原理】XTS子系統之應用相容性測試用例開發
- 【HarmonyOS】【ArkUI】研究了半天,鴻蒙 JS實現餅狀圖終於成功啦!分享一下