华为 Mate 70 Pro 插件开发实战：Stage 模型 vs FA 模型，谁才是真香之选？

说真的，现在做 HarmonyOS 插件开发，最容易踩坑的地方不是 API 不会用，而是模型选错了还不自知。Mate 70 Pro 出厂就搭载 HarmonyOS Next，整套系统服务已经全面切换到 Stage 模型架构，很多老插件还在用 FA 模型硬扛，适配成本蹭蹭往上涨——这种痛，不亲自趟一遍是感受不到的。

本文会从核心架构、内存实测、迁移路径、踩坑案例四个维度，把这两种模型掰开揉碎讲清楚。无论你是新插件从零起步，还是老插件要往 Next 上迁，这篇文章都建议收藏。

一、两种模型的核心架构差异

1.1 FA 模型：老功臣，但越来越力不从心

FA 模型诞生于 HarmonyOS 2.0 时代，采用 Page Ability 粒度划分，每个 Ability 独立运行，拥有独立的窗口和生命周期。这种设计在小型应用场景下简洁直观，但随着应用复杂度提升，跨 Ability 数据共享和状态同步就变成老大难问题了。

具体来说，FA 模型有三个绕不开的局限：

第一，多进程架构带来的资源浪费。 每个 Ability 都跑在独立进程里，进程间通信（IPC）只能通过 HarmonyOS 提供的 RPC 机制实现。数据序列化、反序列化那套开销，在高频交互场景下尤其明显。

第二，窗口生命周期被 Ability 锁死。 FA 模型的窗口管理依附于 Ability 实例，窗口生命周期与 Ability 生命周期强绑定，窗口状态管理的灵活性非常受限——你想让窗口独立存活？想搞个悬浮工具？基本没门。

第三，内存占用偏高。 根据华为官方开发者文档，FA 模型下的 Ability 冷启动平均需要分配约 15-25MB 内存，而 Stage 模型的共进程模式可将这一数字降低至 5-10MB。这不是个小数目，在插件多开场景下差距会被放大得很明显。

1.2 Stage 模型：Next 时代的标准答案

Stage 模型在 HarmonyOS 3.1 时引入，成熟于 HarmonyOS Next 版本。它的核心思路是把界面展示和业务逻辑彻底拆开：

• UIAbility 负责界面展示
• ExtensionAbility 负责业务逻辑（服务、卡片等）
• WindowStage 统一管理窗口状态
• AbilityStage 统一管理同一进程内的多个 Ability 实例

这种解耦带来的好处是：同一个进程里可以跑多个 Ability，内存开销大幅下降，进程间通信的需求也显著减少。

更重要的是，Mate 70 Pro 的系统服务大量基于 Stage 模型构建，插件若采用 FA 模型开发，在与系统服务交互时会产生额外的适配开销。这一点对插件开发者来说几乎是决定性的——你的插件要跟系统的卡片服务、推送服务、文件服务打交道，人家都是 Stage 模型，你这边还停留在 FA，对接的时候光是接口转换就够你头秃的。

二、实战表现：内存与启动速度的真实差距

光讲架构太抽象，咱们看点实际的。

2.1 内存占用对比

还是引用华为官方开发者文档的数据（截至 2026 年 8 月的 HarmonyOS Next 最新 SDK）：

拿一个典型的工具类插件举例：如果插件内含 3 个 Ability（主界面 + 设置 + 后台服务），FA 模型下三个进程加起来可能要 60-80MB，而 Stage 模型共进程模式下，整体可能控制在 20-30MB。对于 Mate 70 Pro 这种内存已经顶到 12GB 的旗舰来说，虽然绝对数值看着不大，但在多插件并行、后台保活、低内存清理这些场景下，这种差距直接决定了你的插件能不能”活下来”。

2.2 启动速度

根据 HarmonyOS 开发者社区里几位开发者的实测反馈（基于 2026 年初的 HarmonyOS Next 版本），从 FA 迁移到 Stage 模型的插件：

• 冷启动耗时普遍下降 30%-50%
• 跨 Ability 数据传递延迟降低约 60%（因为大部分场景不再需要走 IPC）
• 后台保活成功率明显提升

有位做笔记类插件的开发者分享说，他之前用 FA 模型时，插件在后台被系统回收的概率大概是每 10 分钟一次；迁到 Stage 模型后，配合合理的 AbilityStage 配置，基本能做到半小时内不会被无故清理。这种”破防式”的体验提升，在旧模型下是想都不敢想的。

三、从 FA 迁移到 Stage 的完整路径

这一节是很多开发者最关心的——怎么动刀？下面按步骤来。

3.1 配置文件改造

FA 模型的 config.json（或 module.json5）需要按 Stage 模型规范重新组织。核心变化是把 abilities 字段拆分为 abilities（UIAbility）和 extensionAbilities（ExtensionAbility）两个独立字段。

FA 模型旧写法（简化版）：

{
  "module": {
    "abilities": [
      {
        "name": "MainAbility",
        "type": "page",
        "launchType": "standard"
      }
    ]
  }
}

Stage 模型新写法：

{
  "module": {
    "abilities": [
      {
        "name": "EntryAbility",
        "type": "page",
        "launchType": "standard",
        "srcEntry": "./ets/entryability/EntryAbility.ets"
      }
    ],
    "extensionAbilities": [
      {
        "name": "FormAbility",
        "type": "form",
        "srcEntry": "./ets/formability/FormAbility.ets"
      }
    ]
  }
}

3.2 Ability 继承关系改造

FA 模型里 Page Ability 通常继承 Ability，Stage 模型里 UIAbility 必须继承 UIAbility，并且要实现 onWindowStageCreate 生命周期回调来加载窗口内容：

// Stage 模型 UIAbility 典型写法
import UIAbility from '@ohos.app.ability.UIAbility';
import window from '@ohos.window';

export default class EntryAbility extends UIAbility {
  onCreate(want, launchParam) {
    // 初始化逻辑
  }

  onWindowStageCreate(windowStage: window.WindowStage) {
    windowStage.loadContent('pages/Index', (err) => {
      if (err.code) {
        console.error('加载页面失败：' + JSON.stringify(err));
        return;
      }
    });
  }

  onWindowStageDestroy() {
    // 窗口销毁逻辑
  }

  onDestroy() {
    // Ability 销毁逻辑
  }
}

对照 FA 模型那个直接 onActive() 里 setMainRoute() 的写法，这种显式的 WindowStage 生命周期管理其实更符合复杂应用的需求。

3.3 跨 Ability 数据共享方案

FA 模型时代，跨 Ability 数据共享基本靠 want 参数透传，或者通过全局 AppStorage，又或者走 RPC。这种方式在 Stage 模型下不再推荐——共进程模式下，Stage 模型提供了更优雅的方案：

方案一：AbilityStage 内单例

// MyAbilityStage.ets
import AbilityStage from '@ohos.app.ability.AbilityStage';

export default class MyAbilityStage extends AbilityStage {
  private static sharedData: Map<string, any> = new Map();

  onCreate() {
    // 进程级别初始化
    MyAbilityStage.sharedData.set('initTime', Date.now());
  }

  static getData(key: string) {
    return MyAbilityStage.sharedData.get(key);
  }
}

方案二：UIAbility 间的 EventHub

// 在 UIAbility 内
const eventHub = this.context.eventHub;
eventHub.on('customEvent', (data) => {
  console.info('收到事件：' + JSON.stringify(data));
});

// 另一个 UIAbility 触发
const eventHub2 = this.context.eventHub;
eventHub2.emit('customEvent', { msg: 'hello from other ability' });
}

3.4 迁移检查清单

根据社区里踩过坑的开发者总结，FA 迁移到 Stage 时最容易翻车的地方：

• config.json/module.json5 字段结构拆分
• Ability 基类改为 UIAbility 或对应的 ExtensionAbility
• 补全 onWindowStageCreate 回调
• 检查所有 want 参数传递逻辑，看能否换成 EventHub
• 重新申请权限（Stage 模型下权限声明位置有变化）
• 卡片、后台服务等拆分为独立的 ExtensionAbility
• 测试多 Ability 共享内存的实际表现

四、常见问题 FAQ

五、给插件开发者的实操建议

最后给几点掏心窝的建议：

1. 新插件直接 Stage 模型起步。 不要纠结，不要回头看 FA，Stage 模型是 HarmonyOS Next 之后唯一的方向。
2. 老插件迁移要按模块分批进行。 别想着一口气全迁完，建议先把最核心的主 Ability 迁过去，跑通后再处理卡片、后台服务等 ExtensionAbility。
3. 善用 HarmonyOS 开发者社区和官方文档。 2026 年 Stage 模型的官方文档已经相当完善，踩坑前先搜一遍，能省你大把时间。
4. 实测内存和启动数据。 不要光看官方文档的数字，自己用 Profiler 工具测一遍才有底。不同插件类型的资源消耗模式差很多。
5. 关注 HarmonyOS 5/6 的版本更新。 新版本往往会带来一些 Stage 模型相关的 API 优化，适时跟进能让你插件的性能始终在线。