ArkTS 进阶之道7State 真做了啥从赋值就刷 UI 理解依赖追踪本文是「ArkTS 进阶之道」系列第 7 篇开「ArkUI 状态哲学」新阶段。前两阶段讲类型哲学篇 50-52推断逃逸点 作用域哲学篇 53-55边界逃逸点——都是编译期约束。本文换角度讲运行时State 装饰器真做了啥——它是 ArkUI 状态哲学的核心赋值就刷 UI 不是魔法是依赖追踪机制。能力系列篇 13-19 讲过 State 怎么用本文讲为哈赋值就刷 UI——根因在依赖追踪机制。一、开篇State 赋值就刷 UI 不是魔法是依赖追踪机制你写 TypeScript/React 时状态赋值刷 UI 是「魔法」React 的useStatesetter 调用才刷直接赋值不刷// React useState setter 谰才刷 UI const [count, setCount] useState(0) count ← 直接赋值UI 不刷React 不知道 setCount(count 1) ← setter 调用UI 獽刷React 知道 setter 调了 // ArkTS State 赋值就刷 UI不是 setter 调用 State count: number 0 this.count ← 直接赋值就刷 UI不用 setter你写鸿蒙 ArkTS 时State 装饰器变量赋值就刷 UI——不是 setter 调用是编译期生成的依赖追踪代码Entry Component struct Index { State count: number 0 ← State 装饰器赋值就刷 UI build() { Column() { Text(${this.count}) ← Text 依赖 this.count Button(点我) .onClick(() { this.count ← 赋值就刷 UIText 自动更新 }) } } }魔法 vs 机制的区别React 把useStatesetter 当「魔法」你调 setter 獽刷 UI直接赋值不刷ArkTS 把 State 当「依赖追踪机制」编译期生成追踪代码赋值就刷 UI。根因不是魔法是机制——State 装饰器编译期给变量加依赖追踪赋值触发追踪通知 UI 重渲。二、根因State 的依赖追踪机制三重工作鸿蒙 ArkUI 的 State 装饰器是依赖追踪——编译期给变量加追踪代码赋值触发通知 UI 重渲来自三重机制工作。机制 1依赖追踪——编译期记 UI 哪里用了变量State 装饰器编译期给变量加依赖追踪——扫描 build() 里 UI 哪里用了这个变量记成依赖关系Entry Component struct Index { State count: number 0 ← State 装饰器编译期加追踪 State title: string 标题 build() { Column() { Text(${this.count}) ← Text 依赖 this.count编译期记依赖 Text(this.title) ← Text 依赖 this.title编译期记依赖 Button(点我) .onClick(() { this.count }) ← count 赋值触发通知 Text 重渲 } } }编译期记依赖Statecount装饰器编译期扫描 build()发现Text(${this.count})依赖count记成依赖关系count → Text1。赋值this.count触发通知Text1重渲。赋值就刷 UI 不是魔法是编译期记的依赖关系触发通知。机制 2赋值触发通知——运行时赋值就发通知State 装饰器运行时赋值触发通知——赋值操作拦截成「发通知给依赖 UI」Entry Component struct Index { State count: number 0 plainCount: number 0 ← 普通字段赋值不发通知对比 build() { Column() { Text(State ${this.count}) ← 依赖 State count Text(普通 ${this.plainCount}) ← 依赖普通 plainCount但 plainCount 不发通知 Button(点我) .onClick(() { this.count ← State 赋值发通知Text1 重渲 this.plainCount ← 普通赋值不发通知Text2 不重渲对比证据 }) } } }赋值拦截通知Statecount赋值this.count被装饰器拦截成「赋值 发通知给 Text1」Text1 重渲。普通plainCount赋值不拦截不发通知Text2 不重渲——这是 State 装饰器赋值就刷 UI 的直接对比证据。机制 3UI 重渲——通知触发依赖 UI 重渲染State 装饰器通知触发UI 重渲——依赖这个变量的 UI 组件重渲染更新显示Entry Component struct Index { State count: number 0 State list: string[] [一, 二, 三] ← State 数组也追踪 State obj: INumObj { a: 1, b: 2 } as INumObj ← State 对象也追踪 build() { Column() { Text(count ${this.count}) ← Text1 依赖 count Text(list ${this.list.join(, )}) ← Text2 依赖 list Text(obj.a ${this.obj.a}) ← Text3 依赖 obj.a Button(基础类型) .onClick(() { this.count }) ← count 赋值通知 Text1 重渲 Button(数组) .onClick(() { this.list.push(新) }) ← list 负值通知 Text2 重渲 Button(对象属性) .onClick(() { this.obj.a }) ← obj.a 赋值通知 Text3 重渲 } } }通知触发重渲Statecount通知触发Text1重渲显示新 countStatelist通知触发Text2重渲显示新 listStateobj通知触发Text3重渲显示新 obj.a。赋值就刷 UI 的完整链路赋值 → 拦截通知 → 触发依赖 UI 重渲。三、真机配图State 赋值就刷 UI vs 普通字段赋值不刷 UI 对比证据初始态stateCount0、plainCount0、plainCounter.count0、stateList一二三、stateObj.a1 均初始值点调四按钮后stateCount4 刷 UI、plainCount1 不刷 UI、plainCounter.count1 不刷 UI、stateList 含新5、stateObj.a2 均真触发对比证据齐对比证据StatestateCount赋值就刷 UI4 次点击显示 4普通plainCount赋值不刷 UI点击 4 次但显示仍 0普通类plainCounter.count调 inc() 也不刷 UIcount1 但 UI 不显示。赋值就刷 UI 不是魔法是 State 装饰器的依赖追踪机制——编译期记依赖 赋值拦截通知 触发重渲三重工作。四、真解法State 用法的三个场景场景 1基础类型赋值刷 UInumber/string/boolean90% 场景首选Entry Component struct Index { State count: number 0 ← State 基础类型赋值就刷 UI State title: string 标题 State isOn: boolean false build() { Column() { Text(${this.count}) ← 依赖 State count Button(点我) .onClick(() { this.count ← 赋值就刷 UI不用 setter this.title 标题${this.count} ← 赋值就刷 UI this.isOn !this.isOn ← 赋值就刷 UI }) } } }为哈能跑State 基础类型number/string/boolean赋值触发依赖追踪通知UI 重渲。首选这个90% 的场景基础类型 State 就够。赋值就刷 UI 不用 setter跟 React useState 区别ArkTS 编译期生成追踪代码。场景 2数组赋值刷 UIpush/splice 赋值刷 UIEntry Component struct Index { State list: string[] [一, 二, 三] ← State 数组赋值就刷 UI build() { Column() { Text(${this.list.join(, )}) ← 依赖 State list Button(加元素) .onClick(() { this.list.push(新${this.list.length 1}) ← push 负值就刷 UI }) Button(删元素) .onClick(() { this.list.splice(0, 1) ← splice 负值就刷 UI }) } } }为哈能跑State 数组push/splice/pop赋值触发依赖追踪通知依赖数组的 UI 重渲。要写「列表动态增删」时用这个——赋值就刷 UI 不用额外通知State 数组追踪数组操作。场景 3对象属性赋值刷 UI属性赋值刷 UI// 显式 interface 声明见篇 51 装对象字量约束 interface INumObj { a: number b: number } Entry Component struct Index { State obj: INumObj { a: 1, b: 2 } as INumObj ← State 对象属性赋值就刷 UI build() { Column() { Text(a ${this.obj.a}, b ${this.obj.b}) ← 依赖 State obj.a/obj.b Button(改 a) .onClick(() { this.obj.a ← 属性赋值就刷 UI }) Button(改 b) .onClick(() { this.obj.b this.obj.b * 2 ← 属性赋值就刷 UI }) } } }为哈能跑State 对象属性赋值this.obj.a触发依赖追踪通知依赖属性的 UI 重渲。要写「对象属性动态改」时用这个——属性赋值就刷 UI 不用整体替换State 对象追踪属性操作。注意装对象字量要as INumObj见篇 51 装对象字量约束。五、一句话哲学State 赋值就刷 UI 不是魔法是依赖追踪机制三重工作。ArkUI 的 State 装饰器编译期给变量加依赖追踪——①编译期记 UI 哪里用了变量依赖关系②运行时赋值拦截成发通知赋值触发通知③通知触发依赖 UI 重渲UI 重渲染。三重工作链路赋值 → 拦截通知 → 触发重渲。对比普通字段赋值不发通知不刷 UIState 装饰器赋值就刷 UI 是依赖追踪机制的直接证据。两阶段 vs 状态哲学类型哲学篇 50-52编译期推断逃逸点 作用域哲学篇 53-55编译期边界逃逸点都是编译期约束状态哲学篇 56State 运行时依赖追踪是运行时机制——从「编译期拦」到「运行时追踪」换角度讲 ArkUI 状态哲学。下一篇ArkTS 进阶之道8—— Prop/Link 父子传值单向 vs 双向数据流对应能力系列篇 14讲根因——续「ArkUI 状态哲学」阶段。能力系列回链能力系列篇本文进阶点篇 13 State 基础用法State 依赖追踪机制三重工作篇 14 Prop/Link 用法下篇预告单向 vs 双向数据流根因篇 19 State 数组/对象用法数组/对象属性赋值也追踪真机 demo 完整代码// 篇 56 demoState 装饰器依赖追踪机制 // 对比State 装饰器管赋值刷 UI vs 普通字段赋值不刷 UI // 普通字段不是 State赋值不刷 UI class PlainCounter { count: number 0 inc(): void { this.count } } // 显式 interface 声明见篇 51 装对象字量约束 interface INumObj { a: number b: number } Entry Component struct Index { // ✅ State 装饰器赋值就刷 UI State stateCount: number 0 State stateList: string[] [一, 二, 三] State stateObj: INumObj { a: 1, b: 2 } as INumObj State log: string (未操作) // ❌ 普通字段赋值不刷 UI对比证据 plainCount: number 0 plainCounter: PlainCounter new PlainCounter() build() { Column({ space: 12 }) { Text(篇 56 配图State 装饰器依赖追踪机制) .fontSize(18).fontWeight(FontWeight.Bold).margin({ top: 20, bottom: 8 }) Text(State 赋值就刷 UI vs 普通字段赋值不刷对比证据) .fontSize(12).fontColor(#888).margin({ bottom: 16 }) // State 基础类型赋值刷 UI Column({ space: 6 }) { Text(State stateCount ${this.stateCount}).fontSize(16).fontWeight(FontWeight.Bold) Text(普通字段 plainCount ${this.plainCount}赋值不刷 UI).fontSize(14).fontColor(#999) Text(普通类 plainCounter.count ${this.plainCounter.count}赋值不刷 UI).fontSize(14).fontColor(#999) Text(State stateList ${this.stateList.join(, )}).fontSize(14) Text(State stateObj.a ${this.stateObj.a}, b ${this.stateObj.b}).fontSize(14) Text(日志${this.log}).fontSize(12).fontColor(#333).margin({ top: 4 }) } .width(92%).padding(12).backgroundColor(#f5f5f5).borderRadius(8) Button(State 基础类型赋值stateCount) .width(92%).height(44).fontSize(14) .onClick(() { this.stateCount // ✅ State 赋值就刷 UI this.plainCount // ❌ 普通字段赋值不刷 UI对比 this.log 第 ${this.stateCount} 次State 基础类型赋值刷 UI }) Button(State 数组赋值push 新元素) .width(92%).height(44).fontSize(14) .onClick(() { this.stateList.push(新${this.stateList.length 1}) // ✅ State 数组赋值刷 UI this.log 第 ${this.stateCount} 次State 数组 push 刷 UI长度${this.stateList.length} }) Button(State 对象属性赋值stateObj.a) .width(92%).height(44).fontSize(14) .onClick(() { this.stateObj.a // ✅ State 对象属性赋值刷 UI this.log 第 ${this.stateCount} 次State 对象属性 a 刷 UIa${this.stateObj.a} }) Button(普通类调用plainCounter.inc 不刷 UI) .width(92%).height(44).fontSize(14) .onClick(() { this.plainCounter.inc() // ❌ 普通类字段不刷 UI对比 this.log 第 ${this.stateCount} 次plainCounter.inc() 调了但 UI 不刷count${this.plainCounter.count} }) } .width(100%).height(100%).alignItems(HorizontalAlign.Center) } }写鸿蒙 ArkUI 记住State 装饰器赋值就刷 UI 不是魔法是依赖追踪机制三重工作——①编译期记 UI 哪里用了变量依赖关系②运行时赋值拦截成发通知赋值触发通知③通知触发依赖 UI 重渲UI 重渲染。对比普通字段赋值不发通知不刷 UIState 装饰器赋值就刷 UI 是依赖追踪机制的直接证据。基础类型/数组/对象属性赋值均触发追踪赋值就刷 UI 不用 setter是 ArkUI 状态哲学核心