HarmonyOS7 CircularProgressComparison 教程：环形进度的三种表现方式

文章目录前言先别急着写代码界面和数据是怎么配合的完整代码关键代码单独讲第一处关键代码第二处关键代码第三处关键代码常见改造方向再往前走一步容易被忽略的小地方写在最后前言环形进度更适合做卡片信息块、统计摘要和仪表式展示这个案例刚好能看出不同样式的气质差异。 这种例子表面上很基础但只要你开始往业务里塞就会发现很多细节不提前想清楚会很难收。 如果你正准备把它接到业务里这个阅读顺序会比死记参数更省时间。这篇我会重点从数据展示策略这个角度往下讲。不是为了把每个属性都讲一遍而是帮你建立一个更接近真实开发的阅读顺序先看页面目标再看状态流最后再看样式怎么收口。先别急着写代码这个案例并不复杂但它很适合练习 ArkUI 里最常用的那条线状态变化界面跟着变。如果把“Progress 环形对比”只当成一个组件示例来看它其实很快就会读完但一旦把它放回真实页面你会立刻发现它还连着状态切换和结果反馈。这一类写法常见在 下载中心、上传页、任务看板、加载反馈 这些页面里。你只要把示例里的交互换成自己的业务文案再把静态数据换成真实数据源骨架基本就够用了。如果一段代码看起来平平无奇我会先找它到底在响应谁的动作而不是急着去记它的 API。真准备往业务里接时我最先会盯的不是颜色和间距而是 状态字段和展示结果有没有保持同一份数据来源避免页面看起来“能动”但结果不可信。界面和数据是怎么配合的页面最外层通常先用Column把主轴定下来这一步看起来普通但它决定了后面所有内容是顺着读还是碎着看。这个例子没有刻意把结构做复杂反而更方便你看清主交互区和说明区是怎么分层的。像Row这种并排容器真正的价值不是“能横着排”而是帮你把对比关系直接摆给用户看。数字、标签、刻度、按钮放在一起时理解速度会快很多。第 18 篇案例在布局上最值得学的地方是它没有为了展示组件能力去强行堆内容而是尽量让每一块区域都有明确职责。这样的代码后面更好拆组件。完整代码下面这份代码保留了案例本身的实现思路但把示例编号替换成了更自然的英文命名。你直接拿去做实验、拆段运行阅读成本会低很多。/** * CircularProgressComparison - Progress 环形对比 */import{PRESET_COLORS,generateListItems,PAGE_BG_COLOR,PANEL_BG_COLOR,ACCENT_COLOR,MUTED_TEXT_COLOR}from./typesEntryComponentstruct CircularProgressComparison{StateisShow:booleantruebuild(){Column(){if(this.isShow){Column(){Text(Progress 环形对比 - 三种环形类型).fontSize(16).fontWeight(FontWeight.Bold).margin({bottom:16})Row({space:20}){Column(){Text(Ring).fontSize(12).fontColor(MUTED_TEXT_COLOR).margin({bottom:8})Progress({value:72,total:100,type:ProgressType.Ring}).width(72).height(72).color(PRESET_COLORS[5].value)Text(72%).fontSize(14).fontWeight(FontWeight.Bold).fontColor(PRESET_COLORS[5].value).margin({top:8})}Column(){Text(Eclipse).fontSize(12).fontColor(MUTED_TEXT_COLOR).margin({bottom:8})Progress({value:55,total:100,type:ProgressType.Eclipse}).width(72).height(72).color(PRESET_COLORS[3].value)Text(55%).fontSize(14).fontWeight(FontWeight.Bold).fontColor(PRESET_COLORS[3].value).margin({top:8})}Column(){Text(ScaleRing).fontSize(12).fontColor(MUTED_TEXT_COLOR).margin({bottom:8})Progress({value:88,total:100,type:ProgressType.ScaleRing}).width(72).height(72).color(PRESET_COLORS[6].value)Text(88%).fontSize(14).fontWeight(FontWeight.Bold).fontColor(PRESET_COLORS[6].value).margin({top:8})}}.justifyContent(FlexAlign.SpaceEvenly).width(100%).margin({bottom:20})Text(Capsule 胶囊型).fontSize(14).fontWeight(FontWeight.Bold).margin({bottom:8})Progress({value:60,total:100,type:ProgressType.Capsule}).width(100%).height(20).color(ACCENT_COLOR)}.width(100%).padding(16).backgroundColor(PANEL_BG_COLOR).borderRadius(12).alignItems(HorizontalAlign.Center)}Text(Progress 环形对比).fontSize(12).fontColor(MUTED_TEXT_COLOR).margin({top:12})}.width(100%).height(100%).backgroundColor(PAGE_BG_COLOR).padding(16)}}关键代码单独讲第一处关键代码State isShow: boolean true这一行先别急着略过它通常就是页面状态的起点。后面很多显示内容都会跟着它一起变化。 对进度类页面来说再往后多看一眼它有没有和任务状态、文案反馈一起出现。第二处关键代码Progress({ value: 72, total: 100, type: ProgressType.Ring })如果你只打算先读几行代码我会优先看这一类因为它通常正处在页面主路径上。 对进度类页面来说再往后多看一眼它有没有和任务状态、文案反馈一起出现。第三处关键代码Progress({ value: 55, total: 100, type: ProgressType.Eclipse })它不是整段代码里最复杂的部分却往往是最先影响使用体验的部分。 对进度类页面来说再往后多看一眼它有没有和任务状态、文案反馈一起出现。常见改造方向这段代码没有刻意堆很多事件但状态变化的路径依然很清楚用户操作数据改动页面刷新。对进度类页面来说交互不一定来自手点很多时候来自任务本身的推进所以状态源头要比样式更重要。读到交互段时不妨多问一句这个结果有没有唯一数据源很多页面后面难维护就是从这里埋下的。一个很实用的改法是尽早把状态分层谁负责输入谁负责展示谁负责兜底。只要这一步做清楚后面页面再长build()也不至于越来越乱。再往前走一步真要把这个案例拿去改业务页面我会按下面这个顺序动手把演示用的静态数据替换成真实数据源别等接口接进来以后再改页面结构。把重复出现的卡片、标题栏、结果区提成小组件后面加状态会轻松很多。提前补上异常态比如空值、失败态、禁用态、超范围输入否则示例一进业务就会露怯。如果是进度页我会补上任务状态文案比如进行中、暂停、完成、失败因为用户读的不是条而是结果。这里最容易被忽略的一点是 状态字段和展示结果有没有保持同一份数据来源避免页面看起来“能动”但结果不可信。 这个问题。很多示例在静态数据下看不出毛病一接真实状态就开始暴露问题所以这一步最好趁早做。容易被忽略的小地方有些细节在第一眼看代码时很容易被跳过去但它们往往决定了页面是不是耐改。State不是装饰器样板它决定了哪些数据变化后会重新驱动画面。对于 Progress 类页面我会特别留意文案反馈是不是跟着用户动作一起变化因为这直接影响页面有没有“会说话”的感觉。这些东西单看都不复杂组合在一起才是一个案例真正的完成度。写在最后如果你后面准备把它接进真实项目优先处理数据来源、异常状态和文案反馈这三处改完示例味道基本就没了。别急着一上来抽组件先把页面里的主路径走通后面再拆会更稳。