一、从“命令式 UI”到“声明式 UI”：HarmonyOS 的设计取舍

在传统应用开发中，无论是 Android 早期的 XML + Java，还是 View 驱动的 UI 构建方式，本质上都属于命令式 UI。开发者需要明确告诉系统“如何一步步更新界面”，例如查找控件、修改属性、触发刷新。

这种模式在页面复杂度较低时尚可接受，但当页面状态变多、交互逻辑复杂时，UI 与业务逻辑高度耦合的问题会迅速放大，代码可维护性急剧下降。

HarmonyOS 在 UI 框架层面引入 ArkUI 声明式 UI，并不是简单地“换一种写法”，而是试图从根本上解决以下问题：

• UI 与状态之间的映射关系不清晰
• 页面刷新依赖开发者手动控制
• 复杂页面下维护成本过高

ArkUI 的核心思想可以概括为一句话：

界面 = 当前状态的函数映射结果

开发者不再关心“界面如何更新”，而是关注“状态在什么条件下发生变化”。

二、ArkUI 的核心组成与基本结构

一个最基础的 ArkUI 页面，通常由以下几个关键要素组成：

• @Entry：应用或页面的入口组件
• @Component：声明一个 UI 组件
• 状态装饰器（@State、@Prop、@Link 等）
• 布局与基础组件（Column、Row、Text、Button 等）

示例代码如下：

@Entry
@Component
struct MainPage {
  @State message: string = 'Hello HarmonyOS'

  build() {
    Column() {
      Text(this.message)
        .fontSize(24)
        .fontWeight(FontWeight.Bold)

      Button('修改文本')
        .onClick(() => {
          this.message = '状态已更新'
        })
    }
    .width('100%')
    .height('100%')
    .justifyContent(FlexAlign.Center)
  }
}

在这个示例中，有一个非常重要但容易被忽略的事实：

UI 并不是“被更新”的，而是“被重新描述”的。

当 message 状态发生变化时，ArkUI 会自动重新计算 build() 方法的结果，并最小化更新实际渲染树。

三、状态驱动 UI 的底层逻辑理解

1. 为什么状态是 ArkUI 的核心

在 ArkUI 中，状态是唯一可信的数据来源。只要状态发生变化，框架就会负责 UI 的更新逻辑。

ArkUI 提供了多种状态装饰器，不同装饰器对应不同的使用场景。

2. 常见状态装饰器对比

（1）@State：组件内部状态

@State 用于声明组件的私有状态，只在当前组件内部生效。

@State count: number = 0

适用场景：

• 页面内部计数
• 本地 UI 状态
• 不需要向外暴露的数据

（2）@Prop：父组件向子组件传值

@Prop 用于接收父组件传入的数据，子组件不能直接修改。

@Component
struct Child {
  @Prop title: string

  build() {
    Text(this.title)
  }
}

这种方式非常适合做展示型组件，可以显著提升组件复用性。

（3）@Link：双向绑定状态

当父子组件需要共享并修改同一份状态时，可以使用 @Link。

@Link value: number

但在实际工程中，应谨慎使用 @Link，过度双向绑定会导致状态流向不清晰。

四、ArkUI 布局系统与页面组织方式

1. 常用布局容器

ArkUI 提供了一组非常直观的布局组件：

• Column：纵向布局
• Row：横向布局
• Stack：层叠布局

示例：

Column() {
  Text('标题')
  Row() {
    Text('左')
    Text('右')
  }
}

这种布局方式比传统 XML 更加贴近视觉结构，阅读和维护成本更低。

2. 页面拆分与组件化实践

在中大型 HarmonyOS 项目中，页面拆分能力直接决定代码质量。

推荐的拆分原则：

• 页面负责结构
• 组件负责局部功能
• 状态尽量向上集中

示例：

@Component
struct Header {
  @Prop title: string

  build() {
    Text(this.title)
      .fontSize(28)
  }
}

主页面只负责组合组件，而不是堆叠逻辑。

五、实战：构建一个列表页面的工程化写法

1. 定义数据结构

@State itemList: Array<string> = [
  'HarmonyOS',
  'ArkUI',
  'OpenHarmony',
  'ArkTS'
]

2. 使用 ForEach 渲染列表

List() {
  ForEach(this.itemList, (item) => {
    ListItem() {
      Text(item)
        .fontSize(20)
    }
  })
}

ForEach 是 ArkUI 中渲染动态列表的核心机制，框架会自动进行最优更新。

3. 点击交互与状态联动

.onClick(() => {
  console.log(`点击了 ${item}`)
})

注意：
不要在 build() 中做复杂逻辑或异步操作。

六、声明式 UI 下的常见误区与优化建议

1. 误区一：滥用 @State

过多的 @State 会导致页面频繁重绘，应尽量拆分组件，降低状态影响范围。

2. 误区二：在 build 中写业务逻辑

build() 应保持“纯 UI 描述”，任何复杂计算都应提前完成。

3. 性能优化建议

• 控制状态粒度
• 合理拆分组件
• 列表场景优先使用惰性加载组件
• 避免大对象直接作为状态

七、ArkUI 工程化开发经验总结

从实际项目经验来看，ArkUI 非常适合以下类型的应用：

• 页面结构清晰的业务应用
• 状态驱动明显的交互场景
• 需要快速迭代的中小型项目

但前提是：
开发者必须真正理解声明式 UI 的设计思想，而不是把它当作“新的写法”。

八、结语

ArkUI 并不是对传统 UI 模型的简单替代，而是 HarmonyOS 在多端统一与工程效率之间做出的重要选择。一旦掌握状态驱动 UI 的核心思想，开发者会发现页面构建、维护和扩展都变得更加自然。

对于正在深入学习 HarmonyOS 的开发者而言，ArkUI 不只是一个工具，而是一种值得长期投入的开发范式。