一、前言从FA到Stage的演进在HarmonyOS的发展历程中应用开发模型经历了从FA模型到Stage模型的重要演进。FAFeature Ability模型是HarmonyOS早期版本API 7及更早支持的应用开发模型而Stage模型则是从API 9开始引入、HarmonyOS NEXT版本主推且会长期演进的新一代应用开发模型。一句话概括FA模型是鸿蒙早期的开发范式Stage模型是官方主推的现代工程化架构。如果你现在开始学习鸿蒙开发直接选择Stage模型即可FA模型仅作为理解历史演进的需要。二、FA模型详解2.1 什么是FA模型FA模型是“Feature Ability”功能能力的缩写是HarmonyOS早期版本开始支持的应用开发模型。该模型基于微内核架构通过IPC进程间通信和分布式软总线完成轻量化、松耦合的模块间通信和服务调用。FA模型将Ability分为两大类Page Ability页面能力负责展示应用界面类似于Android的Activity包含独立的界面和业务逻辑Service Ability服务能力没有界面主要用于在后台执行任务2.2 FA模型的配置文件在FA模型中应用配置通过config.json文件完成该文件包含三个必填标签标签说明app应用级别的配置如bundleName、vendor、version等deviceConfig设备相关的配置moduleHAP模块的配置包含abilities、deviceType等信息config.json配置示例json{ app: { vendor: example, bundleName: com.example.demo, version: { code: 1000000, name: 1.0.0 } }, module: { mainAbility: .MainAbility_entry, deviceType: [tablet], abilities: [ { name: .MainAbility_entry, type: page, launchType: multiton, orientation: unspecified } ] } }2.3 FA模型的包结构FA模型的应用程序包结构中所有资源文件、库文件和代码文件都存放在assets文件夹中内部进一步区分为entry和js文件夹text- config.json # 应用配置文件 - assets/ ├── entry/ # resources目录和resources.index │ ├── resources/ # 资源文件字符串、图片等 │ └── resources.index └── js/ # 编译后的代码文件 - pack.info # 描述HAP属性的文件2.4 FA模型的上下文获取方式在FA模型中开发者通过featureAbility获取上下文typescriptimport featureAbility from ohos.ability.featureAbility; // 获取上下文 let context featureAbility.getContext(); // 拉起Ability featureAbility.startAbility({ bundleName: com.example.app, abilityName: com.example.MainAbility }).then(() { console.log(Ability启动成功); });三、Stage模型详解3.1 什么是Stage模型Stage模型是HarmonyOS从API 9开始引入的新一代应用开发模型名称中的“Stage”舞台寓意是为开发者提供一个新的展现舞台。Stage模型的设计目标主要是方便开发者开发分布式环境下的复杂应用从架构设计层面规范业务逻辑与UI交互的开发方式。3.2 Stage模型的核心概念Stage模型包含以下核心概念1. AbilityStage应用舞台每个Entry或Feature类型的HAP在运行期都有一个AbilityStage类实例当HAP中的代码首次被加载到进程时系统会先创建AbilityStage实例负责管理该模块下Ability的整体运行状态可在此进行模块级初始化2. UIAbility界面能力组件包含UI的应用组件主要用于和用户交互生命周期包含创建Create、销毁Destroy、前台Foreground、后台Background状态每个UIAbility实例与一个WindowStage类实例绑定3. ExtensionAbility扩展能力组件面向特定场景的应用组件开发者不能直接从ExtensionAbility派生而是使用其派生类常见派生类包括FormExtensionAbility卡片场景InputMethodExtensionAbility输入法场景WorkSchedulerExtensionAbility闲时任务场景4. WindowStage窗口舞台应用进程内的窗口管理器包含一个主窗口为ArkUI提供绘制区域5. Context上下文在运行期提供各种资源和能力的调用接口UIAbility和ExtensionAbility各有不同的Context类均继承自基类Context3.3 Stage模型的配置文件Stage模型使用module.json5作为应用配置文件结构更清晰、模块化程度更高。配置文件包含以下主要部分json5{ module: { name: entry, type: entry, srcEntry: ./ets/ability/AbilityStage.ets, abilities: [ { name: MainAbility, srcEntry: ./ets/ability/MainAbility.ets, launchType: standard, visible: true } ], extensionAbilities: [ { name: FormAbility, srcEntry: ./ets/ability/FormAbility.ets, type: form } ] } }3.4 Stage模型的包结构Stage模型对包结构进行了优化在顶层增加了AppScope目录存放公共资源并增加了AbilityStage.ts作为HAP加载入口。text- AppScope/ # 应用公共资源 └── resources/ └── base/ - entry/ # 主模块 ├── src/ │ └── main/ │ ├── ets/ │ │ ├── ability/ │ │ │ ├── AbilityStage.ets # HAP加载入口 │ │ │ └── MainAbility.ets # UIAbility │ │ └── pages/ │ └── resources/ └── module.json5 # 模块配置文件3.5 Stage模型的上下文获取方式在Stage模型中上下文通过组件实例的context属性直接获取无需依赖featureAbilitytypescript// 组件内直接使用this.context Entry Component struct MyComponent { async writeToFile() { // 使用组件的context属性获取文件目录 const filesDir await this.context.getFilesDir(); // 文件操作... } }在UIAbility中获取上下文typescriptexport default class MainAbility extends UIAbility { onCreate(want, launchParam) { // 直接使用this.context let context this.context; } }四、FA模型与Stage模型核心对比4.1 对比总览对比维度FA模型旧版Stage模型推荐推出时间早期版本API 7及以前API 9起持续演进主推程度已停止演进不再主推长期演进官方主推架构设计单进程架构多进程架构支持多窗口组件类型FeatureAbility、ServiceAbilityUIAbility、ExtensionAbility引擎实例每个组件独享一个ArkTS引擎实例多个组件共享同一个ArkTS引擎实例内存占用较高每个组件独立引擎优化共享引擎减少内存占用上下文获取featureAbility.getContext()组件内this.context配置文件config.jsonmodule.json5适合场景简单应用、快速开发复杂应用、多设备协同、分布式场景学习曲线较平缓类似Android开发较陡峭需要理解新架构4.2 设计思想对比FA模型的设计思想基于微内核架构通过IPC和分布式软总线实现模块间通信强调轻量化、松耦合适合需要快速响应和高效交互的场景Stage模型的设计思想多个组件共享同一个ArkTS引擎实例实现对象和状态的方便共享数据与UI分离Ability中产生数据数据驱动UI变化UI f(state)更好地支持跨端迁移和多端协同对后台进程进行有序治理保障用户体验和系统安全4.3 生命周期对比FA模型的生命周期以Page Ability为例onStart()创建时调用onActive()获得焦点时调用onInactive()失去焦点时调用onBackground()进入后台时调用onStop()销毁时调用Stage模型的生命周期AbilityStage级别模块级生命周期onCreate()模块加载时调用适合模块级初始化UIAbility级别onCreate()Ability创建时调用适合轻量初始化onWindowStageCreate()窗口舞台创建UI相关初始化建议在此进行如loadContent()onForeground()切换到前台onBackground()切换到后台onDestroy()销毁释放资源经验建议不要在onCreate()中执行重任务否则会导致启动卡顿。UI相关的初始化应放在onWindowStageCreate()中。4.4 API调用方式对比FA模型使用featureAbilitytypescriptimport featureAbility from ohos.ability.featureAbility; // 启动Ability featureAbility.startAbility({ bundleName: com.example.app, abilityName: com.example.MainAbility, parameters: { key: value } }).then(() { // 启动成功 }); // 获取参数 featureAbility.getWant((error, want) { let params want.parameters; });Stage模型使用contexttypescript// 启动Ability - 通过context getContext(this).startAbility({ bundleName: com.example.app, abilityName: com.example.MainAbility, parameters: { key: value } }).then(() { // 启动成功 }); // 获取参数 - 在UIAbility中接收 export default class MainAbility extends UIAbility { onCreate(want, launchParam) { let params want.parameters; // 可通过globalThis或AppStorage传递给UI组件 } }五、从FA迁移到Stage模型的实践要点5.1 迁移概述由于FA模型已停止演进建议开发者将现有FA模型应用迁移到Stage模型。迁移主要涉及以下方面5.2 代码目录调整在顶层增加AppScope目录存放公共资源增加AbilityStage.ts作为HAP加载入口配置文件从config.json变更为module.json5pages目录位置调整建议新建一个Stage模型的工程将原有代码逐步复制过来然后逐个解决API差异问题。5.3 API变更适配启动Ability从featureAbility.startAbility()改为context.startAbility()关闭Ability从featureAbility.terminateSelf()改为context.terminateSelf()获取参数从featureAbility.getWant()改为在UIAbility的onCreate()或onNewWant()中接收5.4 数据传递方式变化在FA模型中参数可直接在组件内通过featureAbility.getWant()获取。在Stage模型中方式一在UIAbility中接收want通过globalThis传递给UI组件方式二使用AppStorage进行数据关联UI组件用StorageLink接收六、总结与选择建议6.1 核心结论FA模型是历史产物作为API 7及以前版本的应用模型FA模型已停止演进不再主推Stage模型是未来方向作为HarmonyOS NEXT主推且会长期演进的模型Stage模型代表了鸿蒙应用开发的未来趋势Stage模型的核心优势组件共享ArkTS引擎减少内存占用UI与业务逻辑分离架构更清晰对后台进程有序治理系统更安全更好地支持多设备、分布式场景6.2 选择建议你的情况建议刚入门鸿蒙开发直接学习Stage模型无需了解FA模型新项目立项使用Stage模型开发维护FA模型老项目建议规划迁移到Stage模型学习历史演进了解FA模型有助于理解鸿蒙发展脉络但无需深入研究