# HarmonyOS 5 鸿蒙中Stage模型与FA模型详解

这篇文章是 HarmonyOS 5 中 Stage 模型与 FA 模型的详细对比解析，结合设计理念、技术差异和实际应用场景进行系统性归纳,帮助大家理解一下

⚙️ 一、模型定位与演进趋势

1. FA 模型（Feature Ability）

   • 定位：HarmonyOS 早期版本（API 8 及之前）的默认模型，面向简单应用场景。

   • 组件类型：

     • PageAbility：负责 UI 交互。

     • ServiceAbility：后台服务。

     • DataAbility：数据共享组件。

   • 局限：

     • 每个组件独立运行进程及 ArkTS 引擎实例，内存占用高。

     • 多设备协同能力弱，无法高效支持分布式场景。

2. Stage 模型

   • 定位：HarmonyOS 3.1（API 9）引入，主推的未来演进模型，专为复杂应用与多设备协同设计。

   • 核心优势：

     • 多组件共享单 ArkTS 引擎实例，降低内存占用（较 FA 模型减少 30%+）。

     • 原生支持组件级跨设备迁移与协同（如 UI 状态同步、远程 RPC 调用）。

二、架构与核心组件对比

特性	FA 模型	Stage 模型
组件类型	Page/Service/DataAbility	UIAbility + ExtensionAbility 子类
进程模型	每个组件独立进程	三类进程：主进程、Extension 进程、Render 进程
配置文件	config.json	module.json5 + form_config.json（卡片）
资源管理	需导入 @ohos.resourceManager	通过 context 直接获取 resourceManager
窗口耦合度	高（生命周期与窗口强绑定）	低（通过 WindowStage 分离 UI 与窗口状态）

• Stage 模型新增核心概念：

  • UIAbility：承载 UI 交互，生命周期仅包含创建/销毁/前后台状态，与窗口解耦。

  • ExtensionAbility：场景化扩展能力（如 FormExtensionAbility 用于卡片）。

  • AbilityStage：HAP 运行时的组件容器，管理 UIAbility 实例。

⚡ 三、性能与开发效率差异

1. 资源占用优化

• Stage 模型通过共享引擎实例减少冗余内存开销，尤其适合多组件复杂应用。

1. 分布式能力内建

• UIAbility 支持跨设备拉起与状态同步（数据驱动 UI 恢复），FA 模型需手动实现跨设备通信。

1. 开发范式升级

• FA 模型：基于匿名对象导出，扩展性差。
• Stage 模型：面向对象设计（类接口派生），代码可读性及维护性显著提升。

四、工程结构与配置差异

1. 工程目录

   • FA 模型：资源文件集中存放于 assets 目录下8。

   • Stage 模型:

     entry/src/main/ets/
     ├── Application/MyAbilityStage.ts         # AbilityStage 实现
     ├── UIAbility/MainAbility.ts              # UIAbility 入口
     ├── pages/Index.ets                       # UI 页面
     └── resources/base/profile/form_config.json # 卡片配置:cite[1]:cite[8]

2. HAP包结构 

• Stage 模型：明确区分 ets（代码）、libs（原生库）、resources（资源）。
• FA 模型：所有代码、资源均嵌套在 assets/js 和 assets/entry 中。

五、适用场景与官方推荐

• FA 模型：仅兼容旧项目，新开发不推荐（官方已停止演进）35。

• Stage 模型：

  • 必选场景：分布式应用（跨设备协同）、多窗口适配（平板/智慧屏）、卡片服务67。

  • 长期优势：严格后台管控、单进程模型保障系统功耗平衡17。

总结：模型选择建议

维度	FA 模型	Stage 模型
复杂度	简单应用	中/大型应用
设备支持	单设备	多设备协同
内存敏感场景	不推荐	优先选择
未来兼容性	逐步淘汰	官方主推

 迁移建议：新项目务必采用 Stage 模型；旧项目可逐步重构成 HAP 包，利用 AbilityStage 管理生命周期。