当前位置:首页>鸿蒙APP>《从零到一:鸿蒙原生应用开发实战》第6篇:声明式UI入门——告别命令式旧思维,手写第一个ArkUI组件

《从零到一:鸿蒙原生应用开发实战》第6篇:声明式UI入门——告别命令式旧思维,手写第一个ArkUI组件

  • 2026-11-04 08:59:51
《从零到一:鸿蒙原生应用开发实战》第6篇:声明式UI入门——告别命令式旧思维,手写第一个ArkUI组件

你好,我是华鸿技术栈的作者。

前两篇把 ArkTS 的基础语法过完了。数据类型、函数、数组、解构、扩展运算符——写 UI 要用的“词汇”你已经有了。今天该把它们串起来,真正写一个能跑在模拟器上的组件了。

学任何一门新语言或框架,刚上手都会有点别扭。不是因为它难,是因为它跟你脑子里已经习惯的那套模式不一样。Android 开发者第一次写 Swift 会别扭,前端写 Flutter 也会别扭。这个阶段谁也绕不开,但跨过去之后,你就能用它自己的方式思考问题,写起来反而顺手。

ArkUI 也是一样。它跟你之前写过的 Android(Java/Kotlin)或 iOS(Swift/ObjC)的 UI 写法不太一样。这个不一样的根源,就是声明式 UI。

声明式UI是什么? 就是只负责描述“界面长什么样”,不用管“怎么更新界面”。状态变了,框架自动刷新 UI——你省掉了手动找控件、调 setText、处理各种刷新逻辑的脏活。

6.1 两种写 UI 的方式:命令式和声明式

同一个功能,用两种写法分别实现,差异一目了然。

功能:页面上显示一个数字,一个按钮,点击一次数字加 1。

命令式:一步一步指挥系统干活

如果你写过 Android 或 iOS,你习惯的写法大概是这样(用安卓 Java 举个例):

java

TextView textView = findViewById(R.id.counterText);Button button = findViewById(R.id.addButton);int count = 0;button.setOnClickListener(v -> {    count++;    textView.setText(String.valueOf(count));});

逻辑很清楚:先找到界面上的文字控件和按钮控件,定义一个变量 count,按钮点击时 count 加一,然后手动调用 setText 把新数字塞进控件里。

每一步都是你在命令系统:找到谁、干什么、改什么。代码里既有界面的初始状态,又有每次更新后你怎么去改界面的操作。

声明式:只描述“应该是什么样”

同样的功能,ArkTS 这么写:

@Entry@Componentstruct Counter {  @State count: number = 0;  build() {    Column() {      Text(`${this.count}`)        .fontSize(40)      Button('+1')        .onClick(() => {          this.count++;        })    }    .width('100%')    .height('100%')    .justifyContent(FlexAlign.Center)  }}

这里面没有 findById,没有 setText。你只做了一件事:在 build() 里描述界面。

结论:声明式 UI 省掉了手动更新界面的全部操作。

  • 不用找控件(省略 findById 或 @IBOutlet)

  • 不用手动赋值(省略 setText / setColor)

  • 不用管刷新时机(框架自动 diff 和局部更新)

count 变了之后界面怎么更新——你不管,框架自动搞定。你写“是什么”,框架负责“怎么变”。

6.2 build() 方法:每个组件的 UI 工厂

刚才那段代码里,build() 是核心。每个用 @Component 修饰的 struct 都必须有一个 build() 方法,它返回的就是这个组件的 UI 描述。

你可以把 build() 当成一个生产线:每次状态更新,生产线就重新启动一次,产出一份新的 UI 描述,框架拿着这份描述去更新屏幕。

几个硬性规则:

  1. build() 里只能写 UI 描述,不能写 console.log 之外的复杂逻辑。数据处理、条件判断最好挪到外面。

  2. build() 的返回值必须是组件或容器(Column、Row、Flex 等),不能返回原始值(数字、字符串)。

  3. build() 里的代码会被频繁调用,别在里面做耗时操作。

随着状态管理深入,你会越来越理解 build() 的调用时机。现在先记住:界面 = build() 的返回值。

6.3 链式调用:像流水线一样设置属性

再看这行代码:

Text(`${this.count}`)  .fontSize(40)  .fontColor('#333333')  .fontWeight(FontWeight.Bold)

ArkUI 里所有组件都支持这种“点.属性”的写法,叫链式调用。每个属性方法都返回组件自身,所以你可以一个点接一个点地设属性,不用写很多中间变量。

写过 Java 的 Builder 模式或 Kotlin 的 apply 的话,这个写法不会陌生。它带来的好处是:描述 UI 外观的代码紧凑、直观。

常用的通用属性还有这些:

属性
作用
.width()
 / .height()
宽高
.margin()
外边距
.padding()
内边距
.borderRadius()
圆角
.backgroundColor()
背景色
.onClick()
点击事件

以后你会频繁和它们打交道。

6.4 手写计数器组件——把知识点串起来

下面是完整可运行的计数器代码。新建一个页面(比如 pages/CounterPage.ets),全部贴进去,运行就能看到效果。

@Entry@Componentstruct CounterPage {  @State count: number = 0;  build() {    Column({ space: 20 }) {      Text(`当前计数:${this.count}`)        .fontSize(28)        .fontWeight(FontWeight.Medium)        .fontColor('#333333')      Row({ space: 12 }) {        Button('-1')          .width(60)          .height(40)          .fontSize(18)          .backgroundColor('#FF6B6B')          .fontColor(Color.White)          .borderRadius(8)          .onClick(() => {            this.count--;          })        Button('+1')          .width(60)          .height(40)          .fontSize(18)          .backgroundColor('#4ECDC4')          .fontColor(Color.White)          .borderRadius(8)          .onClick(() => {            this.count++;          })        Button('归零')          .width(60)          .height(40)          .fontSize(18)          .backgroundColor('#95A5A6')          .fontColor(Color.White)          .borderRadius(8)          .onClick(() => {            this.count = 0;          })      }    }    .width('100%')    .height('100%')    .justifyContent(FlexAlign.Center)  }}

跑起来后,点击按钮数字变化,每一步你都没写任何“更新界面”的代码,只改了 this.count 的值。

这就是声明式 UI 的核心体验——改数据,UI 自动跟上。

6.5 声明式 UI 的心里模型:UI = f(state)

可以把 ArkUI 的渲染过程理解成一个函数:

UI = f(state)

state 是你用 @State、@Link、@Prop 等装饰器标记的变量。f 是你写的 build() 方法。每次 state 变了,框架自动重新执行 f,拿到新 UI 描述,跟上一帧对比,只更新变化部分。

你以后写 ArkUI 的日常就是两件事:

  1. 定义状态变量,想清楚哪些数据会变。

  2. 在 build() 里把状态“映射”成界面组件。

剩下的 diff、局部更新、布局计算,框架全包了。

6.6 命令式 vs 声明式 一张表看清

对比点
命令式 UI (Android/iOS)
声明式 UI (ArkUI)
核心逻辑
找到控件 → 改控件属性
定义状态 → 描述状态对应的 UI
更新界面
手动调用 setText/setColor
改状态,框架自动刷新
代码量
初始搭建 + 更新代码都多
只写一次 build()
状态来源
分散在控件和变量里
集中在 @State 等装饰器变量里
易错点
忘记更新、更新了错误控件
状态依赖写错(后面展开)

刚开始写声明式不太习惯,正常。等你用 @State 写完第一个交互列表,再回头想想如果用 findViewById 加 adapter.notifyItemChanged 要写多少行代码,会庆幸自己迈过了这个坎儿。

6.7 本篇总结

今天解决的核心问题就一个:从“手动更新界面”切换到“描述状态对应的界面”。

三个关键知识点:

  • 声明式 UI:UI = f(state),状态变,界面自动变。

  • build() 方法:组件的 UI 描述入口,状态变更即重新执行。

  • 链式调用:设置组件属性的简洁写法。

@State + build() + 链式调用这套组合拳,后面无论多复杂的页面,都是在这个基础上叠加。

常见问题(FAQ)

Q: 声明式 UI 和命令式 UI 到底有什么不同?A: 命令式是“找到控件,手动改属性”;声明式是“定义状态,描述 UI”,状态变了框架自动刷新界面,不用手动操作控件。

Q: build() 方法的作用是什么?A: build() 是每个 ArkUI 组件的 UI 描述入口。每次状态变更,框架重新执行 build(),产出新的 UI 描述并高效更新屏幕。

Q: ArkUI 链式调用是什么意思?A: 链式调用是在组件后连续使用 .属性() 设置样式的方式,如 .fontSize(20).fontColor('#333')。每个属性方法返回组件自身,可以一路点下去。

Q: 刚开始写声明式 UI 不习惯怎么办?A: 正常,每个转过来的开发者都有这个阶段。先把计数器组件手写三遍,感受“改状态→UI自动变”的流程,慢慢就适应了。

本系列指南(点击跳转):

下一篇:计数器只有一个变量 count,实际页面数据更多,组件之间要传值。下一篇深入 @State,学它的搭档 @Prop 和 @Link——父子组件怎么互相传数据、如何保持同步,把收藏按钮这样的组件拆出来复用。

本文由「华鸿技术栈」原创发布,专注鸿蒙原生应用与元服务开发。分享实战代码、源码解析、性能优化及生态前沿。不讲虚的,只上干货。转载请联系授权。

最新文章

随机文章