HarmonyOS鸿蒙Next中Stage模型和FA模型有什么区别？为什么新项目都推荐用Stage？

HarmonyOS鸿蒙Next中Stage模型和FA模型有什么区别？为什么新项目都推荐用Stage？ 我在看鸿蒙文档时发现有两种应用模型：FA（Feature Ability）和 Stage。老项目多用 FA，但新教程全在推 Stage。作为新开发者，我该选哪个？Stage 到底解决了 FA 的哪些痛点？

9 回复

FA 模型（Ability + Service）结构松散，生命周期管理复杂，且难以支持多实例、多窗口场景。Stage 模型引入了统一入口（MainAbilityStage）、清晰的组件生命周期（UIAbility + WindowStage）、更好的并发隔离（每个 Ability 独立线程），并原生支持多实例、多窗口、跨设备迁移。华为已明确 Stage 是未来方向，FA 将逐步淘汰，新项目务必使用 Stage 模型。

更多关于HarmonyOS鸿蒙Next中Stage模型和FA模型有什么区别？为什么新项目都推荐用Stage？的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


不用考虑，直接选Stage就行了

现在还能选择FA？，

特性 FA 模型 (Feature Ability) Stage 模型 (推荐)
适用版本 API 8 及以前 (不再主推) API 9 及以后 (主推)
设计理念 早期探索模型，每个 Ability 相对独立 为复杂应用设计，强调组件管理和窗口管理的解耦
引擎实例 独享 JS VM 引擎实例。每个 Ability 运行在独立的上下文，内存占用较高。 共享 ArkTS 引擎实例。同一进程内的 Ability 共享引擎，内存占用更低，对象共享更方便。
开发范式 偏向类 Web 开发方式，结构相对松散。 面向对象 开发方式，类结构更清晰，易于维护和扩展。
进程模型 默认多进程（每个 Ability 可能在不同进程）。 单进程模型（应用内组件运行在同一进程），适合复杂业务交互。
配置文件 使用 config.json 使用 module.json5
多设备协同 支持基础的分布式能力。 原生支持组件级迁移与协同，对多窗口、多设备形态适配更友好。

总结

  • 性能更优：由于共享 ArkTS 引擎，减少了系统资源的开销。
  • 架构更清晰：引入了 AbilityStage（应用级生命周期）和 WindowStage（窗口管理器），将 UI 与业务逻辑更好地分离。
  • 未来演进：鸿蒙系统的后续新特性（如跨端迁移、流转）将主要在 Stage 模型上演进

随着系统的演进发展，先后提供了两种应用模型：

  • FA（Feature Ability）模型：从API 7开始支持的模型，已经不再主推。
  • Stage模型：从API 9开始新增的模型，是目前主推且会长期演进的模型。在该模型中，由于提供了AbilityStage、WindowStage等类作为应用组件和Window窗口的“舞台”，因此称这种应用模型为Stage模型。

通过对比认识FA模型与Stage模型

Stage模型与FA模型最大的区别在于：Stage模型中，多个应用组件共享同一个ArkTS引擎实例；而FA模型中，每个应用组件独享一个ArkTS引擎实例。因此在Stage模型中，应用组件之间可以方便的共享对象和状态，同时减少复杂应用运行对内存的占用。Stage模型作为主推的应用模型，开发者通过它能够更加便利地开发出分布式场景下的复杂应用。

表1 FA模型与Stage模型差异概览

项目 FA模型 Stage模型
应用组件 1. 组件分类
图片 - PageAbility组件：包含UI，提供展示UI的能力。详细介绍请参见PageAbility组件概述。
- ServiceAbility组件：提供后台服务的能力，无UI。详细介绍请参见ServiceAbility组件概述。
- DataAbility组件：提供数据分享的能力，无UI。详细介绍请参见DataAbility组件概述。
2. 开发方式
通过导出匿名对象、固定入口文件的方式指定应用组件。开发者无法进行派生，不利于扩展能力。		 1. 组件分类
图片 - UIAbility组件：包含UI，提供展示UI的能力，主要用于和用户交互。详细介绍请参见UIAbility组件概述。
- ExtensionAbility组件：提供特定场景（如卡片、输入法）的扩展能力，满足更多的使用场景。详细介绍请参见ExtensionAbility组件概述。
2. 开发方式
采用面向对象的方式，将应用组件以类接口的形式开放给开发者，可以进行派生，利于扩展能力。
进程模型 有两类进程：
1. 主进程
2. 渲染进程
详细介绍请参见进程模型。		 有三类进程：
1. 主进程
2. ExtensionAbility进程
3. 渲染进程
详细介绍请参见进程模型。
线程模型 1. ArkTS引擎实例的创建
一个进程可以运行多个应用组件实例，每个应用组件实例分别运行在单独的ArkTS引擎实例中。
2. 线程模型
每个ArkTS引擎实例都在一个单独线程（非主线程）上创建，主线程没有ArkTS引擎实例。
3. 进程内对象共享：不支持。
详细介绍请参见线程模型。		 1. ArkTS引擎实例的创建
一个进程可以运行多个应用组件实例，所有应用组件实例共享一个ArkTS引擎实例。
2. 线程模型
ArkTS引擎实例在主线程上创建。
3. 进程内对象共享：支持。
详细介绍请参见线程模型。
应用配置文件 使用config.json描述应用信息、HAP信息和应用组件信息。
详细介绍请参见应用配置文件概述（FA模型）。		 使用app.json5描述应用信息，module.json5描述HAP信息、应用组件信息。
详细介绍请参见应用配置文件概述（Stage模型）。

FA基本是废弃状态了，ArkTS还是直接选择Stage模型吧；后面还有仓颉呢。

Stage 与 FA 核心区别在于组件共享引擎、架构解耦、分布式原生支持；新项目选 Stage 是因它更适配复杂应用、内存更省、官方长期支持、生态更完整。有官方文档。

Stage模型是鸿蒙Next的推荐应用模型，提供更清晰的UI与业务逻辑分离，支持多实例与跨设备协同。FA模型为旧版，主要用于兼容早期应用。Stage模型在性能、安全及扩展性上更优，适合复杂应用开发，因此新项目推荐采用。

对于新项目，强烈推荐使用Stage模型。这是鸿蒙架构演进的核心方向。

主要区别与Stage的优势：

  1. 架构设计理念不同

    • FA模型：基于“Ability”为中心，UI（Page Ability）、数据（Data Ability）、服务（Service Ability）耦合较紧，能力边界模糊，不利于复杂应用开发与维护。
    • Stage模型：采用“应用组件”与“UI组件”分离的设计。UIAbility组件负责生命周期和系统交互，Window管理窗口，ArkUI页面负责UI。职责清晰，符合现代前端开发思维。

  2. 开发范式与API清晰度

    • FA模型：API相对庞杂，页面路由、数据共享等方式不够直观统一。
    • Stage模型：提供了清晰、现代的ArkTS声明式UI开发范式。页面路由通过router模块标准化管理，状态管理（如AppStorage）和组件通信机制更完善、高效。

  3. 进程模型与资源管理

    • FA模型：每个Ability默认独立进程，进程创建销毁频繁，系统开销大。
    • Stage模型：同一UIAbility组件及其窗口共进程，多个UIAbility可配置同进程。显著减少进程数量，降低系统负载，资源管理更精细。

  4. 扩展性与生态对齐

    • Stage模型是鸿蒙生态持续演进的基石，未来新特性、新能力（如更好的多设备协同、安全增强、性能优化）将优先甚至仅在Stage模型中提供。其设计也更便于与主流跨平台开发理念接轨。

总结： Stage模型解决了FA模型在架构清晰度、维护性、性能开销和未来扩展性方面的核心痛点。对于新开发者，从Stage模型开始学习，能直接掌握鸿蒙应用开发的现代最佳实践，并确保项目能长期兼容鸿蒙生态的未来发展。FA模型主要用于维护存量应用。

回到顶部