鸿蒙 ArkTS 实战：衣物单次成本的穿着次数、护理费用与残值计算

前言

衣物单次成本是一个基于 ArkTS 和 ArkUI 声明式 UI 的鸿蒙示例项目，入口文件位于 entry/src/main/ets/pages/Index.ets。
本文围绕项目当前已经实现的页面展开，结合 衣物消费复盘 场景分析状态字段、计算函数、布局结构和交互反馈。
文章内容按可发布技术博客组织，重点讲清楚代码为什么这样写、用户操作会触发什么变化，以及这种结构如何继续承载后续功能。
如果项目当前是最小交互页，本文会聚焦入口骨架和状态刷新；如果项目已经包含计算逻辑，本文会继续拆解计算公式和页面反馈。

图示：在 DevEco Studio 中查看 衣物单次成本 项目时，可以从页面入口、状态字段和资源引用三个角度理解实现。

一、项目定位与实现边界

1.1 业务场景

衣物单次成本的项目名称指向 衣物消费复盘，这是理解首屏设计的业务背景。
技术文章不能只看目录名，更要回到 Index.ets 中确认已经出现的状态、函数和组件。
当前页面最重要的价值，是把一个业务主题转化成可运行的鸿蒙页面入口。

1.2 当前代码范围

当前代码已经包含多个数值状态、计算函数、滑块输入、按钮切换和结果展示。
这些内容构成了一个完整的单页小工具，可以直接观察输入变化如何影响最终结果。

1.3 阅读路线

阅读路线可以分成三步：先看状态，再看函数，最后看 UI 绑定。
只要这三层关系清楚，页面的业务意图就不会被样式代码淹没。

维度	当前表现	阅读重点
业务主题	衣物单次成本	围绕 衣物消费复盘 理解页面
入口组件	Index	关注装饰器和 build 函数
状态机制	@State	观察字段变化如何刷新 UI
验证方式	操作首屏	查看文本、费用或状态反馈

二、工程入口解析

2.1 入口装饰器

@Entry 标记当前组件是页面入口，@Component 标记它可以被 ArkUI 渲染。
这两个装饰器让 Index 成为项目首屏的核心阅读对象。

2.2 页面构建函数

build() 函数用声明式组件树描述界面。
它把文本、容器、滑块、按钮和布局约束放在同一个结构中，让页面和状态关系更容易追踪。

2.3 资源化字号

字号通过 $r 读取资源时，页面视觉参数就不必全部硬编码在组件里。
这种写法有利于后续统一调整，也让多页面项目的视觉尺度更一致。

三、状态字段设计

3.1 字段清单

当前页面涉及的状态字段如下：

• price：服务于 衣物单次成本 的显示、输入或计算。
• wears：服务于 衣物单次成本 的显示、输入或计算。
• careFee：服务于 衣物单次成本 的显示、输入或计算。
• resale：服务于 衣物单次成本 的显示、输入或计算。
• seasonItem：服务于 衣物单次成本 的显示、输入或计算。
  这些字段共同构成页面的数据来源，也是调试时最先需要观察的对象。

3.2 响应式刷新

响应式刷新是鸿蒙声明式 UI 的核心。
当 @State 字段被事件回调修改，绑定这些字段的组件会自动更新，不需要手动查找视图节点。

3.3 命名与语义

好的状态命名会让业务含义更清楚。
在 衣物单次成本 中，状态字段和业务主题保持对应，便于从变量名直接判断它影响的页面区域。

状态类别	代表字段	页面作用
主状态	price	驱动核心展示
输入状态	数值或布尔字段	接收用户操作
派生结果	函数返回值	输出计算或显示结果
反馈状态	文本与颜色	表达当前变化

四、核心计算与业务表达

4.1 计算规则

• costPerWear 使用购买价、护理费用、残值和穿着次数计算单次成本。
• rating 根据单次成本分为很划算、可接受和单次偏贵三档。
• seasonItem 用布尔状态记录衣物是否季节限定。
• Slider 的 step 限制输入粒度，减少异常数值。
  这些规则把页面从静态展示推进到可操作工具。

4.2 边界处理

边界处理决定结果是否可信。
穿着次数设置了最小值 1，可以避免单次成本计算出现除零问题。

4.3 结果解释

结果解释应面向真实使用场景。
衣物单次成本最终要让用户看懂状态变化，而不是只展示孤立的代码语法。

五、布局结构拆解

5.1 根容器

根容器使用宽高百分比占满页面，为首屏显示提供稳定空间。
这是移动端页面常见的基础处理，能减少不同设备上内容只占局部区域的问题。

5.2 内容分区

内容分区按照信息优先级组织：主结果或主文本优先出现，输入控件和辅助说明随后展开。
这种结构适合工具类页面，因为用户需要先看到结论，再调整参数。

5.3 尺寸约束

尺寸约束影响的是稳定感。
滑块、按钮、文本和结果区域在刷新时保持稳定，用户操作会更自然。

1. 确认根容器铺满屏幕。
2. 确认主信息位于首屏核心位置。
3. 确认交互控件有稳定触控区域。

六、交互链路分析

6.1 用户动作

用户动作来自点击、拖动或切换。
每个动作都映射到一个事件回调，回调再修改状态字段。

6.2 事件回调

当前回调逻辑保持短小，通常是取整、赋值或布尔取反。
这种写法读起来直接，也降低了调试时的定位成本。

6.3 界面更新

界面更新来自状态绑定。
当状态变化后，文本、颜色、费用、评价或居中内容会同步刷新，这就是声明式 UI 的直观优势。

七、代码片段精读

7.1 状态入口

@State price: number = 399
@State wears: number = 18
@State careFee: number = 8
@State resale: number = 60
@State seasonItem: boolean = false

这段代码承担了页面中的一个独立职责，理解它和界面区域的对应关系，比单纯记语法更重要。

costPerWear(): number {
  return Math.round((this.price + this.careFee * this.wears - this.resale) / this.wears)
}

这段代码承担了页面中的一个独立职责，理解它和界面区域的对应关系，比单纯记语法更重要。

7.2 函数规则

rating(): string {
  return this.costPerWear() <= 20 ? '很划算' : this.costPerWear() <= 50 ? '可接受' : '单次偏贵'
}

这段代码承担了页面中的一个独立职责，理解它和界面区域的对应关系，比单纯记语法更重要。

Slider({ value: this.price, min: 50, max: 3000, step: 10 })
  .onChange((v: number) => {
    this.price = Math.round(v)
  })

这段代码承担了页面中的一个独立职责，理解它和界面区域的对应关系，比单纯记语法更重要。

7.3 展示反馈

Slider({ value: this.wears, min: 1, max: 200, step: 1 })
  .onChange((v: number) => {
    this.wears = Math.round(v)
  })

这段代码承担了页面中的一个独立职责，理解它和界面区域的对应关系，比单纯记语法更重要。

Button(this.seasonItem ? '季节限定' : '全年可穿')
  .height(44)
  .width('100%')
  .onClick(() => {
    this.seasonItem = !this.seasonItem
  })

这段代码承担了页面中的一个独立职责，理解它和界面区域的对应关系，比单纯记语法更重要。

7.4 配置视角

Text(this.costPerWear().toString() + ' 元/次')
  .fontSize(46)
  .fontWeight(FontWeight.Bold)
  .fontColor('#BE123C')

这段代码承担了页面中的一个独立职责，理解它和界面区域的对应关系，比单纯记语法更重要。

{
  "scenario": "clothing cost per wear",
  "entry": "pages/Index",
  "calculation": "cost per wear"
}

这段代码承担了页面中的一个独立职责，理解它和界面区域的对应关系，比单纯记语法更重要。

八、视觉层次与用户感知

8.1 主信息

主信息应在页面中形成第一视觉焦点。
对于 衣物单次成本 来说，主文本、费用结果或状态评价都应该比辅助说明更醒目。

8.2 辅助信息

辅助信息用于解释当前结果，不应抢占主信息层级。
说明文本适合较小字号和较低对比度，让页面保留呼吸感。

8.3 颜色职责

强调色可以围绕 #BE123C 组织，用于主结果、按钮或状态提示。
颜色的职责是传达状态，而不是单纯装饰页面。

九、运行调试流程

9.1 环境确认

运行前先确认 DevEco Studio、SDK、模拟器或真机连接正常。
工程能够成功编译后，再进入页面观察初始状态。

9.2 首屏验证

首屏验证关注初始显示、点击反馈、滑块输入和结果刷新。
如果这些动作都能得到可见反馈，说明页面基础链路已经跑通。

9.3 异常定位

异常定位遵循状态优先原则。
先确认事件是否触发，再确认状态是否变化，最后查看 UI 是否绑定到正确字段。

验证步骤	操作	观察点
1	打开工程	入口文件是否存在
2	运行页面	初始状态是否正常
3	执行交互	状态变化是否可见
4	查看日志	是否存在运行异常

十、扩展结构设计

10.1 组件拆分

组件拆分可以从重复输入项开始。
滑块行、结果卡片、开关按钮和说明区都适合在页面变大后拆出。

10.2 数据保存

数据保存可以让工具从演示页面变成日常可用应用。
衣物单次成本后续可以保存默认参数、最近一次输入或历史记录。

10.3 多页面演进

多页面演进应围绕业务边界展开。
首屏处理核心操作，记录页展示历史，设置页维护默认规则，结构会更清楚。

• 状态少时可以保留在页面组件中。
• 状态多时可以拆出模型对象。
• 计算复杂时可以拆出纯函数。
• 数据需要保留时可以接入本地存储。

十一、工程质量复盘

11.1 稳定性

稳定性来自受控输入。
滑块范围、步长、布尔开关和函数兜底共同保护页面不会产生异常结果。

11.2 可维护性

可维护性来自清晰函数边界。
当计算逻辑独立成函数后，修改规则时不需要在组件树里反复查找表达式。

11.3 体验一致性

体验一致性来自统一的字号、颜色、间距和反馈方式。
同一类操作保持同一种表现，用户会更快理解页面。

工具类页面的可靠感，来自用户每次输入之后都能得到明确、稳定、可解释的反馈。

声明式 UI 的优势，在于把“状态是什么”和“界面怎样显示”放在同一条清晰链路里。

十二、同类项目迁移方法

12.1 复用结构

同类项目可以复用入口结构。
保留 @Entry、@Component、build() 和状态绑定方式，再替换业务字段即可形成新页面。

12.2 替换业务字段

替换业务字段时，要同步调整显示文案、计算函数和交互控件。
字段换了但 UI 文案没换，会让页面和代码语义脱节。

12.3 保持反馈闭环

反馈闭环必须保留。
无论业务主题怎样变化，用户操作后都应该看到明确结果。

十三、总结

13.1 技术收获

衣物单次成本展示了鸿蒙页面从状态声明到视图刷新的基础路径。
完整业务页强调计算结果，最小交互页强调入口骨架，两者都能服务于 ArkTS 学习。

13.2 实践价值

这个项目的实践价值在于把页面行为压缩到可阅读、可运行、可验证的代码中。
读者可以直接对照每段代码理解状态、事件和 UI 的关系。

13.3 工程落点

工程落点是保持当前页面的清晰结构。

---

相关链接：

• HarmonyOS 应用开发指南
• ArkTS 快速入门
• ArkUI 声明式开发
• ArkUI 组件总览