Stage 模型深入解讀

HarmonyOS 3.1 版本（API 9）推出了全新應用開發(fā)模型 - Stage 模型，該模型重新定義了應用開發(fā)的能力邊界，從應用開發(fā)模型的角度，支持多窗口形態(tài)下統(tǒng)一的應用組件生命周期，并支持跨設備的遷移和協(xié)同機制。本文為大家詳細介紹 Stage 模型。

一、Stage 模型概念

應用開發(fā)模型是運行在不同 OS 上的抽象結構。OS 通過這種抽象結構，把應用開發(fā)的基礎設施封裝在 OS 內部。開發(fā)者通過使用應用開發(fā)模型，復用 OS 基礎設施的能力，達到高效開發(fā)應用的目的。

1、什么是 Stage 模型

Stage 模型提供面向對象的開發(fā)方式，規(guī)范化了進程創(chuàng)建的方式，提供組件化開發(fā)機制，將組件抽象為 UIAbility 和 ExtensionAbility 兩大類。UIAbility 組件的生命周期包含創(chuàng)建、銷毀、前臺、后臺狀態(tài)，將與界面強相關的獲焦、失焦狀態(tài)都放在窗口管理對象中，從而實現(xiàn) UIAbility 與窗口之間的弱耦合；在服務側，窗口管理服務依賴于組件管理服務，前者通知后者前后臺變化，這樣組件管理服務僅感知前后臺變化，不感知焦點變化。ExtensionAbility 組件提供場景化的服務擴展機制，不提供自定義服務的能力。

相比于 FA 模型，Stage 模型提供了更靈活的開發(fā)方式，更低的內存占用和更規(guī)范化的系統(tǒng)管理機制。

未來 HarmonyOS 將在兼容 FA 模型的基礎上，持續(xù)演進 Stage 模型。

2、Stage 模型能力特點

Stage 模型的設計，是為了提供給開發(fā)者一個更好的開發(fā)方式，更好的適用于多設備、分布式場景。

Stage 模型的三大能力特點：

1）原生支持組件級的遷移和協(xié)同

Stage 模型的組件天生具備分布式遷移和協(xié)同的能力，它是 HarmonyOS 支持分布式能力在應用模型上的體現(xiàn)。

應用組件支持跨設備的數(shù)據(jù)恢復：

充分使用 ArkUI 的聲明式 UI 和多頁面的能力，把數(shù)據(jù) / 狀態(tài)保存在 UIAbility 組件實例中，邏輯修改數(shù)據(jù)，數(shù)據(jù)驅動 UI 變化。多設備間遷移 UIAbility，就是遷移 UIAbility 的數(shù)據(jù) / 狀態(tài)。在目標設備上通過數(shù)據(jù) / 狀態(tài)來恢復 UI，實現(xiàn)邏輯與 UI 的解耦，提升了流轉開發(fā)效率。

應用組件支持跨設備的遠程調用：

UIAbility 組件支持跨設備拉起另外一個設備上同名應用的同名組件實例。系統(tǒng)在拉起過程中，通過底層軟總線的能力在兩個組件實例之間建立跨設備的 RPC 連接，開發(fā)者在獲取 RPC 接口后，即可進行跨設備通信，適用于應用在設備間交互的場景。

2）支持多設備形態(tài)和多窗口形態(tài)

在桌面設備上，窗口可以最大化 / 最小化 / 任意改變窗口大小，窗口間可以任意切換焦點，接收用戶輸入。在移動設備上，基本以全屏窗口為主，窗口之間構成棧結構，只有頂層窗口才能接收用戶輸入。如何在不同窗口形態(tài)的設備上，提供統(tǒng)一的組件模型呢？Stage 模型分離了 UIAbility 生命周期和窗口顯示 / 焦點事件，使得窗口的焦點切換不影響 UIAbility 組件的狀態(tài)。

UIAbility 的前后臺狀態(tài)和窗口的全屏 / 最小化的關系如下：

只有當窗口最小化的時候，UIAbility 組件進入后臺狀態(tài)，否則 UIAbility 組件處于前臺狀態(tài)；

當一個窗口全屏的時候，觸發(fā)其他窗口最小化（可以根據(jù)產(chǎn)品形態(tài)確定全屏窗口個數(shù)）。

在桌面設備和移動設備的交互體驗不同的情況下，系統(tǒng)通過實施上述規(guī)則，可以保證 UIAbility 組件的生命周期定義在多設備上保持一致。同時，不論在桌面設備還是移動設備，都遵循每個新的 UIAbility 組件實例都會創(chuàng)建一個任務，所以也保證了任務（Mission）機制在多設備上的一致性。

3）重新定義應用能力邊界

通常情況下，應用如果可自行決定創(chuàng)建多少個進程、自定義服務時，系統(tǒng)為保證用戶體驗，需要在后臺運行管控、進程關聯(lián)啟動等方面對應用的運行狀態(tài)進行強管理，從而降低系統(tǒng)總體的內存占用和功耗開銷。

Stage 模型基于場景的服務擴展、嚴格的后臺管控機制和受限的進程模型，重新定義了應用能力邊界，使進程環(huán)境從 “無序” 到 “有序”，規(guī)范了進程管理模型。

二、Stage 模型介紹

基于 Stage 模型開發(fā)應用，下面將會從應用組件、進程模型、線程模型、任務模型、后臺運行機制、應用配置文件 6 個方面進行介紹。

1、組件模型

應用開發(fā)模型中需要指明應用開發(fā)的入口。在 HarmonyOS 上，應用組件是應用開發(fā)的入口，同時也是運行時入口。用戶啟動、使用和退出應用過程中，應用組件會在不同的狀態(tài)間切換，這些狀態(tài)稱為應用組件的生命周期。應用組件提供生命周期的回調函數(shù)，開發(fā)者通過應用組件的生命周期回調感知應用的狀態(tài)變化。

Stage 模型提供了 UIAbility 和 ExtensionAbility 兩種類型的組件。

1） UIAbility 組件是一種包含 UI 界面的應用組件，主要用于和用戶交互。UIAbility 的生命周期只包含創(chuàng)建 / 銷毀 / 前臺 / 后臺等狀態(tài)，通過 WindowStage 的事件暴露顯示相關的狀態(tài)。每個 UIAbility 組件都會有一個主窗口與之綁定，如果開發(fā)者希望開發(fā)復雜的頁面和動效，我們推薦開發(fā)者使用 ArkUI 的多頁面能力。UIAbility 支持跨設備拉起同名組件，并與之協(xié)同交互的能力。

2）ExtensionAbility 組件是一種面向特定場景的應用組件，系統(tǒng)在特定場景下啟動該組件為用戶提供服務。開發(fā)者并不直接從 ExtensionAbility 派生，而是從 ExtensionAbility 的派生類派生。目前 ExtensionAbility 有用于卡片場景的 FormExtensionAbility 和用于輸入法場景的 InputMethodExtensionAbility 等多種派生類。在 Stage 模型上，普通應用開發(fā)者不能開發(fā)自定義服務，也不支持開發(fā)者直接啟動 ExtensionAbility，包括開發(fā)者自己編寫的 ExtensionAbility。

2、進程模型

Stage 模型有三類進程，是從系統(tǒng)總體資源占用考慮，希望由系統(tǒng)負責應用進程的創(chuàng)建和銷毀。所以不支持應用自定義配置多進程，也不支持通過接口啟動進程。

1）主進程

開發(fā)者編寫的 UIAbility 入口及其依賴的代碼都在該進程中運行。它是由 UIAbility 組件的啟動觸發(fā)創(chuàng)建的。

2）ExtensionAbility 進程

開發(fā)者編寫的同一種類型的 ExtensionAbility 組件實例都會在同一個進程中運行。不同類型的 ExtensionAbility 組件實例則在不同的進程中運行。該類進程是由系統(tǒng)服務在特定場景下創(chuàng)建，并根據(jù)用戶對特定場景的使用，決定其何時銷毀。同時該類進程獨立于主進程創(chuàng)建，并且不支持與主進程之間進行 IPC 通信。

3）Render 進程

為了支持 WebView 的運行，每個應用只能創(chuàng)建一個 Render 進程用于運行 WebView 的渲染引擎。這個 Render 進程也是由系統(tǒng)負責創(chuàng)建和銷毀。

3、線程模型

HarmonyOS 的原生應用開發(fā)語言為 ArkTS。在應用進程啟動時，系統(tǒng)會在主線程上創(chuàng)建一個 ArkTS 的虛擬機實例，然后加載和執(zhí)行應用的入口代碼。應用組件的生命周期回調，輸入事件的分發(fā)，ArkUI 的布局等操作都會在主線程上執(zhí)行，所以我們推薦開發(fā)者不要在主線程上執(zhí)行單次耗時過長的操作，否則容易引發(fā)卡頓。

ArkTS 通過提供 Worker API 支持并發(fā)編程。Worker 有獨立的虛擬機上下文，它與主線程是兩個不同的虛擬機上下文。它們之間通過 postMessage API 進行通信。這種基于消息傳遞的并發(fā)模型與基于鎖的并發(fā)模型不同，需要開發(fā)者特別注意。

4、任務模型

用戶在操作應用的過程中，經(jīng)常需要對已經(jīng)操作過的應用進行切換，這些操作記錄（不同 OS 的操作對象定義可能不同）經(jīng)常被稱為任務。應用任務管理模型需要定義任務的操作對象，以及任務創(chuàng)建和銷毀的方式和時機。

在 HarmonyOS 上，每次用戶啟動一個新的 UIAbility 組件實例，都會生成一個新的任務（Mission）。例如，用戶啟動一個視頻應用后，切換到 “任務中心” 界面，將會看到視頻應用這個任務，當用戶點擊這個任務時，系統(tǒng)會把該任務切換到前臺，如果這個視頻應用中的視頻編輯功能也是通過應用組件編寫的，那么在用戶啟動視頻編輯功能時，會創(chuàng)建視頻編輯的應用組件實例，在 “任務中心” 界面中，將會展示視頻應用、視頻編輯兩個任務。

任務（Mission）中記錄了組件和快照的信息，并在系統(tǒng)中持久化。即使任務對應的組件實例銷毀，任務仍然存在。如果用戶從任務中心中選擇某個任務，任務對應的組件實例會被拉到前臺并獲焦，如果它對應的組件實例已經(jīng)銷毀，系統(tǒng)會創(chuàng)建一個新的組件實例與之對應。

開發(fā)者在用戶交互設計上需要特別注意，避免產(chǎn)生過多的任務。如果開發(fā)者希望使用多個頁面交互，推薦使用 ArkUI 的頁面棧能力。

HarmonyOS 的任務模型不提供任務棧的能力，每個應用可以有多個任務在任務中心呈現(xiàn)，不同應用的任務不會以棧的形式堆疊在一起，避免了不同應用間任務混淆不清的情況。

5、后臺運行機制

當應用的所有前臺 UIAbility 組件都進入后臺的時候，系統(tǒng)認為該應用進入后臺。應用在后臺運行的機制對設備續(xù)航影響很大。HarmonyOS 后臺運行機制的設計初衷是希望應用進程在系統(tǒng)規(guī)則范圍內運行，并使用戶可感知，避免應用進程在后臺運行，而用戶不感知的情況。我們提供了如下幾種后臺任務（Task）：

1）短時任務

系統(tǒng)每天會給申請了短時任務的應用分配一定的后臺運行配額。

2）長時任務

系統(tǒng)定義了若干種后臺長時運行的任務類型，開發(fā)者需要在應用的配置文件中配置，并需要上架審核。這樣該應用在設備上后臺運行的時候，就可以保持長時間運行，同時系統(tǒng)會通過用戶可感知的 UI 提示用戶有后臺進程正在運行。例如導航，錄音，音樂等場景。

3）無任務

默認情況下，應用不申請任何后臺運行方式，則會在應用進程進入后臺 10 秒鐘后被凍結掛起，應用無法收到外部非用戶操作事件。

4）閑時任務

對于一些 CPU 密集型，且對實時性要求不高的任務，比如科學計算等場景，系統(tǒng)提供了閑時任務機制。例如設備充電等適當?shù)臅r機向應用提供后臺運行的能力，開發(fā)者可以通過 Work-SchedulerExtensionAbility 使用該機制，系統(tǒng)會根據(jù)當前的系統(tǒng)狀態(tài)和用戶使用頻次決策喚醒時機。

5）托管任務

對于一些可以托管給系統(tǒng)執(zhí)行的任務。比如下載等場景，系統(tǒng)提供代理任務的 API，由系統(tǒng)代理實現(xiàn)任務，應用進程會處于凍結狀態(tài)。

6、應用配置文件

Stage 模型提供了全新的應用配置文件，它包含應用信息、應用組件信息、權限信息、開發(fā)者自定義信息等，這些信息在編譯構建、分發(fā)和運行階段分別提供給編譯工具、應用市場和操作系統(tǒng)使用。

Stage 應用模型是 HarmonyOS 應用開發(fā)的基礎架構，它從組件模型、面向對象開發(fā)方式、進程 / 線程模型等方面對 FA 模型進行了全面的優(yōu)化，提高了應用開發(fā)效率。后續(xù)我們將在應用模型的基礎設施、大型應用開發(fā)、拓展應用形態(tài)、跨設備能力和性能體驗等方面繼續(xù)打磨，支撐 HarmonyOS 應用生態(tài)拓展，廣大開發(fā)者加入進來，一起探索和創(chuàng)新，共建萬物互聯(lián)的應用生態(tài)。

未來將來，有跡可循！

審核編輯 黃宇