HarmonyOS 7 系统能力 10｜能力整合

三掌柜666

477人浏览 · 2026-10-14 02:05:59

三掌柜666 · 2026-10-14 02:05:59 发布

这一篇解决的问题：把系统能力收进一个服务层。我们不背 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' }
    }
  }
}