作者：sunbingxin 應用框架架構師

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應用生態拓展，廣大開發者加入進來，一起探索和創新，共建萬物互聯的應用生態。

未來將來，有跡可循！

END

想了解更多HarmonyOS技術？

后臺留言給我們

立刻安排！

歡迎點擊｜閱讀原文｜

進入HarmonyOS應用開發在線體驗