从命令式到声明式：鸿蒙开发的思维革新之路

大家好，我是Echo_Wish，一个长期在鸿蒙生态中摸爬滚打的人。今天我们来聊一个很多人在用，但不一定“真正理解”的东西——声明式编程在鸿蒙（ArkUI）中的应用。

说句实话，这玩意儿看起来很“新潮”，但它背后代表的不是语法变化，而是开发思维的转变。从“我告诉系统一步步怎么做”，到“我描述我想要的 UI 最终是什么样”。这背后，藏着鸿蒙对未来交互、设备融合、开发者体验的深度考量。

一、引子：为什么我们的 UI 越写越累？

还记得你写命令式 UI 的那些日子吗？

• 状态改一下，UI就要手动刷新
• 页面联动多一点就开始“屎山重构”
• 视图、数据、事件一堆混在一起
• 一改一个地方，其他地方全跟着崩

就像你想做个咖啡，结果你要：

称咖啡豆 → 控温 → 打奶泡 → 调配比例 → 擦机子 → 清理台面 → 最后才能喝一口

命令式开发模式就是这样：每一个细节你都要亲自操作。

而声明式呢？

你只需要说：

我要一杯热拿铁，浓度中等，奶多一点

剩下的由系统自动安排。

鸿蒙的 ArkUI 声明式 UI 就是为了让开发者从繁琐的控件更新中解放出来。

二、原理讲解：什么叫声明式编程？

一句话总结：

命令式：告诉系统“怎么做”

声明式：只描述“想要什么”

鸿蒙中声明式编程的核心理念是：

• UI = 状态（State） 的函数
• UI 不需要手动更新，状态改变，UI 自动刷新

也就是说：

UI = f(state)

状态一变，页面自己变，不用你操心。

这和 Flutter、React、SwiftUI 是一样的现代 UI 框架方向。

三、上代码，感受下声明式的“爽感”

例子：计数器（经典但好理解）

命令式写法（旧逻辑，让人崩溃）

let count = 0
function onButtonClick() {
  count++
  document.getElementById("text").innerText = count
}

你要自己拿控件、自己更新 UI。

鸿蒙声明式写法（ArkTS）

@Entry
@Component
struct CounterDemo {
  @State count: number = 0

  build() {
    Column() {
      Text(this.count.toString())
        .fontSize(30)
      Button("点击 + 1")
        .onClick(() => {
          this.count++
        })
    }
  }
}

看到关键区别了吗？

声明式写法不仅代码少，而且可维护性直接起飞。

四、场景应用：当 UI 复杂时差距特别大

比如有这样一个场景：

选择商品 → 数量变化 → 价格联动 → 购物车同步 → UI 实时刷新

命令式写法就容易变成：

• onClick 里更新数量
• 调用价格刷新函数
• 再触发购物车同步
• 再手动刷新 UI 控件
• 还可能忘记刷新一个地方导致显示不一致

而声明式写法只需要：

• 维护数据状态
• UI 自动跟随状态变化更新

示例：

@State price: number = 18
@State count: number = 1

get total() {
  return this.price * this.count
}

UI 不用管，只写：

Text(`合计：￥${this.total}`)

这，就是架构层面的降维打击。

五、Echo_Wish式思考：声明式不是“语法更新”，是开发者心态的升级

为什么鸿蒙选择声明式？

因为未来的应用环境不再是“一个屏幕”，而是：

• 手机 + 平板
• 手表 + 音箱
• 车机 + 电视
• 家庭 IoT 场景的 分布式界面流转

要做到 同一套业务逻辑在多设备上动态重构 UI，必须用声明式模式。

命令式根本扛不住这种复杂度。

一句话：

声明式是为“多设备多形态时代”设计的，而不是给单一设备优化的。

所以声明式不是趋势，它是必然。

六、写在最后：会不会写声明式，不再是能力差别，而是时代差别

我们曾经习惯拼体力、写大量 UI 刷新代码；
现在，我们要学会：

• 让状态驱动 UI
• 让框架帮我们做脏活
• 把注意力放在业务和体验上

就像从搬砖转变为设计建筑。

开发不是累出来的，是想明白出来的。

如果你现在还觉得声明式“只是新语法”，那么我劝你：

不要只学“怎么写”，要学“为啥这样写”。