👋 你好，欢迎来到我的博客！我是【菜鸟学鸿蒙】
   我是一名在路上的移动端开发者，正从传统“小码农”转向鸿蒙原生开发的进阶之旅。为了把学习过的知识沉淀下来，也为了和更多同路人互相启发，我决定把探索 HarmonyOS 的过程都记录在这里。
  
  🛠️ 主要方向：ArkTS 语言基础、HarmonyOS 原生应用（Stage 模型、UIAbility/ServiceAbility）、分布式能力与软总线、元服务/卡片、应用签名与上架、性能与内存优化、项目实战，以及 Android → 鸿蒙的迁移踩坑与复盘。
  🧭 内容节奏：从基础到实战——小示例拆解框架认知、专项优化手记、实战项目拆包、面试题思考与复盘，让每篇都有可落地的代码与方法论。
  💡 我相信：写作是把知识内化的过程，分享是让生态更繁荣的方式。
  
   如果你也想拥抱鸿蒙、热爱成长，欢迎关注我，一起交流进步！🚀

前言：Ability 不是“页面”，它是系统调度的最小“能力单位”😤

在鸿蒙里，Ability 的定位特别“硬核”：它是系统调度应用的最小单元，一个应用可以包含一个或多个 Ability。(华为开发者)
这句话看着像教科书，但你真写项目就懂了——鸿蒙不是让你用“Activity 思维”硬套，它是把“能力”先抽象出来，然后再决定：

• 这个能力要不要 UI？
• 要不要常驻后台？
• 要不要对外扩展成输入法/分享/卡片/快捷开关？

这就是鸿蒙应用模型的“底层脾气”。

1）Ability 类型：FA / PA / SA ——别再混着叫了，求你了🙏

1.1 FA / PA：这是“FA 模型”的应用组件分类（偏早期 / API 8 及更早）

在 FA 模型里，Ability 被分成 FA（Feature Ability） 和 PA（Particle Ability）：

• FA：支持 Page Ability（有界面）
• PA：支持 Service Ability / Data Ability / FormAbility（偏服务、数据、卡片）(华为开发者)

OpenHarmony 的开发概述也明确：FA 模型应用组件常见就是 PageAbility、ServiceAbility、DataAbility 以及卡片相关。(Gitee)

说人话：FA/PA 是“老模型的分法”，你现在要是新项目还坚持只用它，我会皱眉（但我不骂人，我忍😅）。

1.2 Stage 模型：主流！Ability 变成 UIAbility + ExtensionAbility（API 9 起）

从 API 9 开始，Ability 框架引入 Stage 模型，把应用组件主要分成：

• UIAbility：带 UI 的能力（你的页面入口通常都在这）
• ExtensionAbility：各种“扩展能力”，例如 ServiceExtensionAbility、FormExtensionAbility、DataShareExtensionAbility 等(华为开发者)

并且 Stage 模型一个特别重要的差异是：多个组件共享同一个虚拟机（VM），相比 FA 模型“组件各自一套 VM”，内存和对象共享会更友好。(华为开发者)

1.3 SA：System Ability（系统能力服务），不是你业务 App 里随手 new 的东西😤

**SA（System Ability）**指的是系统能力服务/系统服务，背后由 **Samgr（System Ability Manager）**管理：负责系统服务的启动、注册、查询等。(Gitee)

说人话：

• FA/PA/UIAbility/ExtensionAbility：应用开发者经常写的组件
• SA：更偏系统服务层/系统侧能力（系统服务的“注册与管理体系”）(Gitee)

所以你大纲里写“FA/PA/SA”，我理解你是想把“应用模型 + 系统服务体系”一起捋顺——这很对！但请千万别把 SA 当作“App 里的后台 Service”那样用，它不是一个层级的概念。

2）Ability 生命周期：UIAbility 的核心回调到底怎么走？

生命周期这块最容易写成“玄学”。我给你一个能落地的结论：

UIAbility 的核心生命周期回调包括：

• onCreate
• onForeground
• onBackground
• onDestroy (华为开发者)

而且 UIAbility 生命周期和 WindowStage 生命周期强关联：比如 onWindowStageCreate()、onWindowStageDestroy() 这一套。(华为开发者)

2.1 代码示例：UIAbility 生命周期（建议你照这个骨架写，省心）

import { AbilityConstant, UIAbility, Want, WindowStage } from '@kit.AbilityKit';

export default class EntryAbility extends UIAbility {
  onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void {
    console.info('[EntryAbility] onCreate, want=' + JSON.stringify(want));
    // ✅ 做一次性初始化：配置、日志、轻量级资源
    // ❌ 别在这儿干大活：不要同步读大文件/不要卡主线程
  }

  onWindowStageCreate(windowStage: WindowStage): void {
    console.info('[EntryAbility] onWindowStageCreate');
    // ✅ 在这里把 UI 挂上去
    // 具体 setUIContent 写法随工程模板/API 版本略有差异，以你项目为准
    windowStage.setUIContent(this.context, 'pages/Index', null);
  }

  onForeground(): void {
    console.info('[EntryAbility] onForeground');
    // ✅ 恢复前台：刷新可见数据、恢复订阅
  }

  onBackground(): void {
    console.info('[EntryAbility] onBackground');
    // ✅ 退后台：暂停动画/停止高频任务/保存轻量状态
  }

  onDestroy(): void {
    console.info('[EntryAbility] onDestroy');
    // ✅ 释放资源：取消订阅、关闭连接
  }

  onNewWant(want: Want): void {
    console.info('[EntryAbility] onNewWant, want=' + JSON.stringify(want));
    // ✅ 多次拉起复用时处理新参数
  }
}

2.2 两个“我踩过的坑”，你别再踩一次🙃

• 坑 1：在生命周期里做耗时操作
  官方文档明确提醒：生命周期回调在主线程执行，尽量只做必要的轻量操作，耗时任务要异步/子线程处理。(华为开发者)
• 坑 2：把页面逻辑全塞 UIAbility
  UIAbility 是“能力入口”，不是“代码垃圾桶”。页面路由、状态、网络请求最好分层放，不然维护起来你会怀疑人生。

3）Ability 与页面、服务的关系：别再把“页面=Ability”了

这句话你一定要记住（我说得很认真😤）：

Ability 负责“被系统调度”，页面负责“给用户看”。

3.1 UIAbility 与页面（ArkUI 页面）

• UIAbility：是应用的“前台交互能力”，系统把它调度到前台/后台
• 页面：是 UIAbility 在 WindowStage 上挂载的具体 UI 内容（你看到的界面）

文档也强调 UIAbility 生命周期和 WindowStage 生命周期关联——这本质上就是在告诉你：UIAbility 管“生命周期状态”，WindowStage 管“窗口与界面载体”。(华为开发者)

3.2 Ability 与服务：ExtensionAbility 才是 Stage 模型里的“服务范式”

Stage 模型里你想做后台服务/扩展能力，通常落在 ExtensionAbility 家族里（例如 ServiceExtensionAbility）。(华为开发者)

直观点：

• UIAbility ≈ 你要跟用户交互的“入口能力”
• ServiceExtensionAbility ≈ 你要在后台/系统扩展点干活的“服务能力”

4）与 Android 四大组件对比：像，但不等于（别硬套）

Android 的“四大组件”是：Activity、Service、BroadcastReceiver、ContentProvider。Activity 生命周期核心回调官方也写得很清楚：onCreate/onStart/onResume/onPause/onStop/onDestroy。(Android Developers)
鸿蒙这里更像“能力 + 扩展点”的组合，而不是 1:1 镜像。

我给你一个不容易被喷、但很实用的对照表：

Android	鸿蒙（Stage 模型）更接近谁	说明
Activity	UIAbility	都是带 UI 的交互入口，但鸿蒙更强调“系统调度的能力单元” (华为开发者)
Service	ServiceExtensionAbility（或相关 Extension）	鸿蒙把“服务”放进扩展能力体系里，场景更细分 (华为开发者)
BroadcastReceiver	（能力更分散在系统事件/公共事件机制中）	不是简单一类组件就能概括，更多是“事件机制 + 权限 + 场景”
ContentProvider	DataAbility（FA）/ 数据共享相关 Extension（Stage）	FA 模型里 DataAbility 很直观；Stage 模型用数据共享相关扩展更符合新体系 (Gitee)

你会发现：

• Android 更像“固定四大件 + 你按规则装配”
• 鸿蒙更像“能力为核心 + UIAbility/ExtensionAbility 组合出场景”(华为开发者)

所以你如果拿 Android 四大组件去硬套鸿蒙，短期能理解，长期会拧巴——因为鸿蒙的抽象粒度更偏‘能力与扩展点’。

结尾：你想写的是“页面”，还是“能力”？先想清楚再敲键盘😅

Ability 架构这套东西，最烦人的地方在于：名词多；但最爽的地方也在于：一旦你把“UIAbility 是入口、ExtensionAbility 是扩展、SA 是系统服务体系”分清楚，你写应用会突然变得很顺。
不夸张——那种感觉就像你终于把一团耳机线理顺了（虽然第二天它可能又打结🙃）。

📝 写在最后

如果你觉得这篇文章对你有帮助，或者有任何想法、建议，欢迎在评论区留言交流！你的每一个点赞 👍、收藏 ⭐、关注 ❤️，都是我持续更新的最大动力！

我是一个在代码世界里不断摸索的小码农，愿我们都能在成长的路上越走越远，越学越强！

感谢你的阅读，我们下篇文章再见～👋

✍️ 作者：某个被流“治愈”过的 移动端 老兵
📅 日期：2025-11-05
🧵 本文原创，转载请注明出处。