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應用生態擴充，廣大開發者加入進來，一起探索和創新，共建萬物互聯的應用生態。
未來將來，有跡可循！
