HarmonyOS7 IndeterminateLoadingState 教程：不确定进度的加载状态怎么表现

前言

很多异步任务根本拿不到准确百分比，这时“正在处理”比“处理到多少”更重要。 如果只是把控件摆上去，这段代码五分钟就能写完；难的是把它写成一个像样的交互。 我会尽量把注意力放在页面为什么这样组织，而不是只解释控件叫什么。

这篇我会重点从表单交互体验这个角度往下讲。不是为了把每个属性都讲一遍，而是帮你建立一个更接近真实开发的阅读顺序：先看页面目标，再看状态流，最后再看样式怎么收口。

这个案例解决了什么小问题

我更建议把它当成一个小型业务原型，而不是孤立的组件演示。

这类页面最值得看的，从来不是控件本身，而是它怎样嵌进完整业务流程里。围绕“Progress 不确定态”，前后通常都会挂着别的状态和文案。

这一类写法常见在 下载中心、上传页、任务看板、加载反馈 这些页面里。你只要把示例里的交互换成自己的业务文案，再把静态数据换成真实数据源，骨架基本就够用了。

先把用户操作路径走一遍，再回头看参数名，很多配置为什么存在会一下子清楚很多。

这一类页面最后最容易出问题的，通常不是你肉眼第一眼看到的布局，而是 状态字段和展示结果有没有保持同一份数据来源，避免页面看起来“能动”但结果不可信。

先看交互路径

页面最外层通常先用Column把主轴定下来，这一步看起来普通，但它决定了后面所有内容是顺着读，还是碎着看。

这个例子没有刻意把结构做复杂，反而更方便你看清主交互区和说明区是怎么分层的。

这一页更多是纵向阅读逻辑，说明作者希望用户按顺序完成操作，而不是在多个区域来回跳。

第 19 篇案例在布局上最值得学的地方，是它没有为了展示组件能力去强行堆内容，而是尽量让每一块区域都有明确职责。这样的代码后面更好拆组件。

完整代码

下面这份代码保留了案例本身的实现思路，但把示例编号替换成了更自然的英文命名。你直接拿去做实验、拆段运行，阅读成本会低很多。

/** * IndeterminateLoadingState - Progress 不确定态 */import{PRESET_COLORS,generateListItems,PAGE_BG_COLOR,PANEL_BG_COLOR,ACCENT_COLOR,MUTED_TEXT_COLOR}from'./types'@Entry@Componentstruct IndeterminateLoadingState{@StateisShow:boolean=truebuild(){Column(){if(this.isShow){Column(){Text('Progress 不确定态').fontSize(16).fontWeight(FontWeight.Bold).margin({bottom:16})Text('Loading...').fontSize(14).fontWeight(FontWeight.Bold).fontColor(ACCENT_COLOR).margin({bottom:16})Text('线性不确定').fontSize(13).fontColor(MUTED_TEXT_COLOR).margin({bottom:8})Progress({value:0,total:100,type:ProgressType.Linear}).width('100%').height(8).color(ACCENT_COLOR).margin({bottom:20})Text('环形不确定').fontSize(13).fontColor(MUTED_TEXT_COLOR).margin({bottom:8})Progress({value:0,total:100,type:ProgressType.Ring}).width(60).height(60).color(PRESET_COLORS[3].value).margin({bottom:20})Text('Eclipse 不确定').fontSize(13).fontColor(MUTED_TEXT_COLOR).margin({bottom:8})Progress({value:0,total:100,type:ProgressType.Eclipse}).width(60).height(60).color(PRESET_COLORS[5].value).margin({bottom:20})Text('ScaleRing 不确定').fontSize(13).fontColor(MUTED_TEXT_COLOR).margin({bottom:8})Progress({value:0,total:100,type:ProgressType.ScaleRing}).width(60).height(60).color(PRESET_COLORS[6].value)Text('value=0 时显示不确定加载动画').fontSize(11).fontColor(MUTED_TEXT_COLOR).margin({top:14})}.width('100%').padding(16).backgroundColor(PANEL_BG_COLOR).borderRadius(12).alignItems(HorizontalAlign.Center)}Text('Progress 不确定态 - loading 旋转动画').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: 0, total: 100, type: ProgressType.Linear })

如果你只打算先读几行代码，我会优先看这一类，因为它通常正处在页面主路径上。 对进度类页面来说，再往后多看一眼它有没有和任务状态、文案反馈一起出现。

第三处关键代码

Progress({ value: 0, total: 100, type: ProgressType.Ring })

它不是整段代码里最复杂的部分，却往往是最先影响使用体验的部分。 对进度类页面来说，再往后多看一眼它有没有和任务状态、文案反馈一起出现。

落地时的取舍建议

这段代码没有刻意堆很多事件，但状态变化的路径依然很清楚：用户操作，数据改动，页面刷新。

对进度类页面来说，交互不一定来自手点，很多时候来自任务本身的推进，所以状态源头要比样式更重要。

我更建议你读这一段时，把注意力放在“状态有没有只存一份”。一旦同一个结果要靠两三个变量拼出来，后面很容易出现显示和真实值不同步的问题。

如果你后面要继续扩展这个页面，一个很稳的做法是先把核心状态梳理成几类：输入值、展示值、辅助文案、边界状态。分类清楚了，代码会比一股脑往build()里塞判断干净很多。

再往前走一步

真要把这个案例拿去改业务页面，我会按下面这个顺序动手：

• 把演示用的静态数据替换成真实数据源，别等接口接进来以后再改页面结构。
• 把重复出现的卡片、标题栏、结果区提成小组件，后面加状态会轻松很多。
• 提前补上异常态，比如空值、失败态、禁用态、超范围输入，否则示例一进业务就会露怯。
• 如果是进度页，我会补上任务状态文案，比如进行中、暂停、完成、失败，因为用户读的不是条，而是结果。

这里最容易被忽略的一点，是 状态字段和展示结果有没有保持同一份数据来源，避免页面看起来“能动”但结果不可信。 这个问题。很多示例在静态数据下看不出毛病，一接真实状态就开始暴露问题，所以这一步最好趁早做。

容易被忽略的小地方

有些细节在第一眼看代码时很容易被跳过去，但它们往往决定了页面是不是耐改。

• @State不是装饰器样板，它决定了哪些数据变化后会重新驱动画面。
• 对于 Progress 类页面，我会特别留意文案反馈是不是跟着用户动作一起变化，因为这直接影响页面有没有“会说话”的感觉。

这些东西单看都不复杂，组合在一起，才是一个案例真正的完成度。

写在最后

很多 HarmonyOS7 基础案例的价值，都不在“展示了多少组件”，而在“给了你一个能继续长大的骨架”。这篇就是典型。

真正决定成品感的，往往不是控件本身，而是用户操作后页面有没有给出明确回应。