Ability 到 Stage：HarmonyOS 应用架构到底在‘舞’什么？

最新推荐文章于 2025-12-16 23:10:05 发布

原创最新推荐文章于 2025-12-16 23:10:05 发布 · 998 阅读

12 ·

CC 4.0 BY-SA版权

文章标签：

#harmonyos #架构 #华为

零基础学鸿蒙开发专栏收录该内容

451 篇文章

订阅专栏

你是不是也在想——“鸿蒙这么火，我能不能学会？”
答案是：当然可以！
这个专栏专为零基础小白设计，不需要编程基础，也不需要懂原理、背术语。我们会用最通俗易懂的语言、最贴近生活的案例，手把手带你从安装开发工具开始，一步步学会开发自己的鸿蒙应用。
不管你是学生、上班族、打算转行，还是单纯对技术感兴趣，只要你愿意花一点时间，就能在这里搞懂鸿蒙开发，并做出属于自己的App！
📌 关注本专栏《零基础学鸿蒙开发》，一起变强！
每一节内容我都会持续更新，配图+代码+解释全都有，欢迎点个关注，不走丢，我是小白酷爱学习，我们一起上路 🚀

全文目录：

写代码嘛，不就是写人间悲喜。可在 HarmonyOS 的世界里，这场戏，居然真有舞台。

前言：开发，是一场优雅的“舞台剧”

朋友，你有没有过这种体验：明明代码逻辑写得没毛病，但应用一运行就卡顿、闪退、黑屏，一通调试下来，一头问号——“到底是哪个环节出了锅？”
在移动开发的江湖中，生命周期管理、界面构建、模块解耦永远是三座大山。而在华为打造的 HarmonyOS 世界里，这一切，有了新的演绎方式：Ability + Stage Model 架构。

乍一听，是不是一脸懵？Stage 是啥？Ability 和 Activity 有什么区别？Declarative UI 又跟 Jetpack Compose 有没有一腿？别慌，别慌，今天我这篇文章就是来解锁这些关键概念的，一边码代码，一边给你讲人话，写出味儿来！

一、HarmonyOS 是怎么“想”的？——从分布式角度重新审视应用架构

先从最顶层开聊。为什么 HarmonyOS 要搞 Ability 这种概念？原因其实很简单：它要的是一个真正的“万物互联操作系统”。

想象一下，如果你的手机、手表、电视、冰箱都是一套代码跑的，你还敢用传统的 Activity/Fragment 框架玩命堆逻辑？不敢！

所以，HarmonyOS 引入了三大核心设计理念：

✅ 面向服务的架构（Service Oriented Architecture）
✅ 基于组件的设计（Ability 拆解）
✅ 支持跨设备迁移（分布式能力）

简言之，HarmonyOS 的“应用”不再是一个固化在手机上的包，而是一组动态可部署的能力集合，可漂移、可复用、可组合。

二、Ability 与 Stage Model 架构：不再“背锅”的模块分工

2.1 什么是 Ability？——不是 Activity 的“马甲”

Ability 在 HarmonyOS 中，是一个广义上的“能量单位”。每个 Ability 负责实现一个相对独立的功能。

它分为两类：

FA（Feature Ability）：传统单设备能力，面向 UI 和交互；
PA（Particle Ability）：服务型能力，常驻后台，面向数据和业务逻辑。

看起来是不是有点像 Android 的 Activity + Service？是，但又不是。

特性	Android Activity/Service	HarmonyOS Ability
生命周期	单线程管理	分 Stage 精细控制
跨设备迁移	不支持	✅支持
解耦性	中等	高
生命周期调度	组件间隐式耦合	明确、分层

举个栗子🌰：

你有一个健康管理应用，包含运动记录、睡眠分析、数据同步三个模块：

- UI模块 --> Feature Ability
- 数据分析模块 --> Particle Ability
- 后台同步模块 --> Particle Ability

每个 Ability 独立管理，彼此低耦合，还能跨设备调用！这才是真·现代架构。

2.2 Stage Model 是干嘛的？——舞台导演不是白叫的

如果说 Ability 是演员，那 Stage Model 就是导演。它负责调度各个 Ability 的生命周期，统一管理资源、窗口、任务栈等。

Stage Model 的引入，让原本由系统粗暴处理的生命周期，变得清晰、可控、可扩展。

生命周期核心类如下：

public class MainAbility extends StageAbility {
    @Override
    public void onCreate(Want want) {
        super.onCreate(want);
        // 初始化，加载UI，准备数据等
    }

    @Override
    public void onForeground(Intent intent) {
        super.onForeground(intent);
        // 页面进入前台
    }

    @Override
    public void onBackground() {
        super.onBackground();
        // 页面进入后台
    }

    @Override
    public void onDestroy() {
        super.onDestroy();
        // 清理资源
    }
}

是不是比 Android 的 onResume/onPause 更加一目了然？HarmonyOS 的 Stage Model 是面向多线程和多设备的，因此必须分层管理。

三、生命周期的奥义：从乱七八糟到井井有条

在 Android 时代，开发者最怕的就是“生命周期地狱”：页面一变，状态全丢；Activity 一死，数据全挂。HarmonyOS 的设计从根源上解决了这个问题：

3.1 生命周期分层设计

层级	管理对象	方法名
Application	应用全局	`onCreate` / `onTerminate`
StageAbility	页面生命周期	`onCreate` / `onForeground`
UIComponent	页面内部UI逻辑	生命周期绑定于Stage

开发者可以针对不同层级做资源初始化、权限申请、状态恢复，逻辑更加清晰、职责明确。

四、Declarative UI 与 XML 布局：你是传统派还是未来派？

4.1 Declarative UI：HarmonyOS 的 UI 新语法糖

Declarative UI，是 HarmonyOS 开发者未来的主力战场。它让你“声明一个界面状态”，而不是“堆砌控件”。

形象比喻：

XML 布局像在搭积木；
Declarative UI 像在写剧本。

@Entry
@Component
struct HelloComponent {
  build() {
    Column() {
      Text("你好，HarmonyOS！")
        .fontSize(30)
        .fontWeight(FontWeight.Bold)
    }
  }
}

是不是有点像 Flutter / SwiftUI？没错！但 HarmonyOS 的 ArkUI 是自研的 UI 渲染引擎，性能优化更偏底层。

4.2 XML布局：老将仍有用武之地

虽然 Declarative UI 是未来，但 XML 仍然是许多项目的主力。毕竟它成熟、稳定、上手快，尤其适合不太依赖动态状态变更的界面。

<Text
    android:id="@+id/hello_text"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="你好，老朋友" />

五、实战项目结构剖析：用一套架构撑起全平台分发

在真实项目中，HarmonyOS 鼓励开发者使用模块化架构：

myApp/
├── entry/                   # 主模块
│   ├── src/main/ets         # 主Ability UI逻辑
├── feature_orders/          # 订单模块
│   └── src/main/ets
├── service_sync/            # 同步服务模块
│   └── src/main/java
├── base_libs/               # 基础库模块
│   └── network, storage, UI组件