这一篇解决的问题:按钮点击怎么更有手感。我们不背 API,而是从一个真实页面需求出发,把“触觉反馈与交互状态配合”做成能继续扩展的工程写法。

先说问题:功能能跑,不等于接对了

做 HarmonyOS 7 页面时,最容易出现一种情况:UI 已经写完,按钮也摆好了,等真正接系统能力时才发现权限、生命周期、异常分支和页面状态全挤在一起。第一次点可能没问题,第二次点、拒绝权限、切后台再回来,问题就开始冒出来。

这也是这一套连载想解决的事。我们不把系统能力当成“调用一个 API 就结束”,而是把调用前、调用中、调用后都放进页面流程里。这样代码才像项目代码,而不是演示代码。

1. 先把页面状态理顺

无论调用哪一种系统能力,页面至少要知道三件事:当前是否正在执行、执行结果是什么、失败后用户能不能继续操作。先给页面准备一个最小状态模型。

@Entry
@Component
struct DemoPage {
  @State isRunning: boolean = false
  @State message: string = '等待操作'

  build() {
    Column({ space: 16 }) {
      Text(this.message)
        .fontSize(18)

      Button(this.isRunning ? '处理中...' : '开始操作')
        .enabled(!this.isRunning)
        .onClick(async () => {
          await this.runAction()
        })
    }
    .width('100%')
    .padding(24)
  }

  private async runAction(): Promise<void> {
    this.isRunning = true
    try {
      this.message = '执行成功'
    } catch (error) {
      this.message = '执行失败,请重试'
    } finally {
      this.isRunning = false
    }
  }
}

这段代码看起来很普通,但它先解决了一个工程问题:系统调用和 UI 状态不能各写各的。 finally 也不是装饰。成功、失败都要恢复按钮,否则某个异常分支漏掉状态恢复,页面就会一直停在“处理中”。

2. 触觉反馈与交互状态配合

真正接能力时,不建议直接把一大坨调用逻辑塞进 onClick。按钮只负责表达“用户做了什么”,能力调用放进独立方法。后面加权限判断、日志、异常提示时,页面结构不会迅速失控。

private async execute(): Promise<void> {
  if (this.isRunning) {
    return
  }

  this.isRunning = true
  this.message = '正在处理'

  try {
    const result = await this.callSystemAbility()
    this.message = result ? '操作完成' : '没有获取到结果'
  } catch (error) {
    console.error(`system ability error: ${JSON.stringify(error)}`)
    this.message = '操作失败'
  } finally {
    this.isRunning = false
  }
}

private async callSystemAbility(): Promise<boolean> {
  // 此处替换为本篇对应的 HarmonyOS 7 系统能力调用。
  return true
}

这里有个很实用的习惯:方法返回的是业务需要的结果,而不是把底层对象直接扔给页面。页面只关心“能不能继续渲染”,不应该知道底层每个字段。项目一大,这个区别很明显。

在这里插入图片描述

3. 不要只写成功路径

教程代码最爱写“点击 → 成功 → 展示结果”。真实用户偏偏不会这么配合。权限可能拒绝,资源可能不存在,系统能力可能暂时不可用,应用也可能在执行中进入后台。

所以页面至少把结果拆成三类:成功、用户可恢复的失败、暂时无法恢复的失败。不要所有异常都只弹一句“操作失败”。用户看不懂,开发排查也没信息。

enum ActionStatus {
  Idle,
  Running,
  Success,
  RetryableError,
  Error
}

@State status: ActionStatus = ActionStatus.Idle

private showResult(status: ActionStatus): string {
  switch (status) {
    case ActionStatus.Running:
      return '正在处理...'
    case ActionStatus.Success:
      return '处理完成'
    case ActionStatus.RetryableError:
      return '暂时失败,可以重试'
    case ActionStatus.Error:
      return '当前无法完成操作'
    default:
      return '等待操作'
  }
}

用枚举比堆几个 boolean 更稳。否则很容易同时出现 loading = true、success = true、error = true 这种自己都解释不通的组合。

4. 页面和系统能力之间最好隔一层

项目里如果多个页面都要使用同一种系统能力,复制代码是最省事、也是后面最麻烦的方案。更合适的方式是做一个很薄的 Service。它不负责 UI,只负责调用、整理返回值和抛出明确错误。

export interface AbilityResult {
  success: boolean
  message: string
}

export class SystemAbilityService {
  async execute(): Promise<AbilityResult> {
    try {
      // 调用 HarmonyOS 7 对应能力
      return { success: true, message: 'success' }
    } catch (error) {
      console.error(`execute failed: ${JSON.stringify(error)}`)
      return { success: false, message: 'failed' }
    }
  }
}

页面拿到的是稳定的 AbilityResult。以后底层 API 调整,优先改 Service,不需要十几个页面一起找。这个做法不复杂,却是“示例代码”和“项目代码”之间很明显的一道分界线。

5. 真机测试时重点看什么

系统能力相关功能不能只盯模拟器。模拟器适合确认页面流程和基础代码,但涉及权限、硬件、后台行为时,真机结果更有参考价值。测试时至少走一遍正常路径、拒绝路径、重复点击、切后台再返回,以及失败后的再次尝试。

还有一个很常见的坑:第一次调用成功,就认为代码结束了。实际线上问题往往发生在第二次、第三次调用。比如状态没有清理、上一次结果残留、按钮重复触发、页面销毁后异步结果又回来。写系统能力时,把“重复执行”当成默认场景,代码会稳很多。

这一篇记住三件事

第一,系统能力不是一个孤立 API,它一定会和页面状态、权限、异常分支发生关系。第二,按钮事件保持短,把具体调用放进方法或 Service。第三,别只测试成功一次,重复调用和失败恢复才更容易暴露真实问题。

这一套思路会贯穿后面的 02–10。下一篇继续往真实功能里走,不停留在概念层。

小练习

把本文的 DemoPage 改成你项目里的一个真实按钮,并补上 Idle / Running / Success / Error 四种状态。然后连续操作三次,再故意制造一次失败,观察页面能不能正确恢复。能做到这一点,再往里接具体系统 API,会轻松很多。

Logo

加入「COC·上海城市开发者社区」,成就更好的自己!

更多推荐