一、背景
随着鸿蒙系统的演进，先后提供了两种应用模型。从 API 7 开始支持 FA 模型，目前已不再主推；从 API 9 开始新增 Stage 模型，是目前主推且长期演进的模型，通过以下对比了解两个模型之间的区别。
二、最核心的区别
|--------------|-----------------------------------|---------------------------------------------------------|
| 对比维度 | FA 模型 | Stage 模型 |
| ArkTS 引擎实例管理 | 每个应用组件（Ability）独享一个引擎实例 | 多个应用组件（UIAbility）共享一个引擎实例 |
| 生命周期与上下文管理 | 无统一应用上下文，每个 Ability 独立生命周期（孤岛式管理） | 全局 ApplicationContext 统筹管理，UIAbility 生命周期隶属于应用进程（容器式管理） |
| 窗口管理能力 | 无统一窗口管理入口，窗口与 AbilitySlice 强耦合 | 内置 WindowStage 统一管理窗口，支持多窗口、悬浮窗、分屏等复杂场景 |
三、应用组件
|----------|---------------------|----------------------------------------------------------------------------------------------------------|
| 模型 | 组件类型 | 说明 |
| Stage 模型 | UIAbility 组件 | 承载 UI 页面，是应用的核心交互载体 |
| Stage 模型 | ExtensionAbility 组件 | 提供特定场景扩展能力（如 ServiceExtension、FormExtension、InputMethodExtension 等），替代 FA 模型的 ServiceAbility/DataAbility |
| FA 模型 | PageAbility 组件 | 承载 UI 页面，与 AbilitySlice 配合实现页面跳转 |
| FA 模型 | ServiceAbility 组件 | 提供后台服务能力 |
| FA 模型 | DataAbility 组件 | 提供跨应用数据共享能力 |
四、进程模型
|--------------------------------------------------------|----------------------|----------------------------------------------------------------------------------------|
| Stage 模型 | FA 模型 | 关键差异 |
| 主进程 (UIAbility) + ExtensionAbility 进程 + 渲染进程 (WebView) | 主进程 + 渲染进程 (WebView) | Stage 模型的 ExtensionAbility 可独立进程运行，避免后台服务阻塞主进程；FA 模型的 ServiceAbility 运行在主进程或独立进程，需手动配置 |
五、线程模型
|-------------------------------|------------------------------|------------------------------------------------------------------------------|
| Stage 模型 | FA 模型 | 关键差异 |
| 主线程 + TaskPool 线程 + Worker 线程 | 主线程 + Ability 线程 + Worker 线程 | Stage 模型的 TaskPool 是更高效的任务调度机制，支持任务并发和负载均衡，替代 FA 模型的 Ability 线程（单线程模型，调度效率低） |
六、启动模式
|------------------|-----------|------------------------------------------------------|
| Stage 模型 | FA 模型 | 关键差异 |
| 单实例 + 多实例 + 指定实例 | 单实例 + 多实例 | Stage 模型新增 指定实例 模式，可指定已存在的 UIAbility 实例启动，精准控制组件复用逻辑 |
七、生命周期
|----------------------------|----------------------------------------------------------------------------------------------------|
| Stage 模型（UIAbility 生命周期） | onCreate → onWindowStageCreate → onForeground → onBackground → onWindowStageDestroy → onDestroy |
| FA 模型（PageAbility 生命周期） | onCreate → onStart → onActive → onInactive → onShow → onHide → onDestroy |
| FA 模型（ServiceAbility 生命周期） | onStart→onCommand→onConnect→onDisconnect→onStop |
| 核心差异 | Stage 模型新增 窗口生命周期钩子（onWindowStageCreate/onWindowStageDestroy），实现 UI 与窗口的解耦；FA 模型生命周期与页面跳转强绑定，逻辑更混乱 |
八、上下文与资源管理
|----------|---------------------------------------------------------|
| Stage 模型 | 全局 ApplicationContext 统一管理应用配置、资源、权限，任意 UIAbility 可直接获取 |
| FA 模型 | 无全局上下文，资源需在 Ability 间手动传递（如通过 Intent） |
| 开发影响 | Stage 模型资源共享更便捷，无需写大量数据传递代码 |
九、其他
|-------|----------------------------------------------------|-------------------------------------------------------------------|---------------------------------------|
| 对比维度 | FA 模型 | Stage 模型 | 开发影响 |
| 跨设备能力 | 基于 Ability 迁移，需手动处理状态同步，易出现数据不一致 | 基于 UIAbility 分布式迁移，结合 Stage 上下文管理，迁移后状态不丢失、体验连贯 | Stage 模型是鸿蒙跨端流转、元服务的核心支撑，FA 模型跨设备能力受限 |
| 开发范式 | Ability 与页面耦合度高，模块划分模糊，依赖手动传递数据，样板代码多，无明确分层设计 | 遵循前后端分离理念，支持模块化拆分（entry/feature/library），依赖注入灵活，工程结构清晰，符合现代应用开发规范 | Stage 模型可维护性、扩展性更强，降低团队协作成本 |
| 兼容性 | 仅适配 API 8 及以下版本，HarmonyOS NEXT 中部分 API 已废弃，兼容性逐步收缩 | 适配 API 9 及以上版本，HarmonyOS NEXT 主推模型，向下兼容部分 FA 能力（需适配改造） | 新项目优先选 Stage 模型，存量 FA 项目需逐步迁移 |
| 生态支持 | 生态逐步弱化，新特性（元服务、跨端流转、AI 原生能力）不再适配 | 生态持续完善，所有鸿蒙新特性、官方工具链、第三方组件均优先支持，是鸿蒙原生应用的唯一推荐模型 | 依托 Stage 模型可接入鸿蒙最新生态能力，保障应用长期演进 |