手绘笔记风信息图,主题是 HarmonyOS7 的 preferences 存草稿。画面中心是一张手

前言

草稿数据通常不大,但对用户很重要。写到一半退出页面、应用被回收、网络提交失败,用户都希望内容还能找回来。HarmonyOS7 里 preferences 很适合保存这种轻量键值数据。

但它不是数据库,也不是万能缓存。我的习惯是提前想清楚三件事:恢复什么、什么时候保存、什么时候清理。草稿存储要及时,但不能无边界。

为什么这个问题经常被写乱

preferences 存草稿刚刚好 这类内容很容易被写成“代码能跑就算讲完了”,但对初学者来说,这恰恰是最不够的地方。真正让人卡住的,往往不是某个组件名记不住,而是不知道这段代码为什么要这样拆、状态为什么要这样放、以后需求变化时应该从哪里改。

所以这篇文章不只想给你一个能跑的例子,更想把背后的判断过程讲清楚。你只要把这个判断过程吃透,后面自己改页面、补需求、查问题时,心里会稳很多。

什么适合放进 preferences

笔记草稿是典型场景:标题和正文都是字符串,数据量小,恢复价值高。

手绘蓝图风框架图,主题是 HarmonyOS7 草稿存储的判断框架。用三层结构展示:页面目标 ->

数据是否适合说明
草稿标题适合小而明确
草稿正文适合短文本长文或富文本要另选方案
图片列表不适合结构和体积都偏重
上次选择适合比如排序方式、开关配置

我会把 preferences 当成轻量记事本,而不是缓存层。只要数据开始变大、变复杂,就应该重新考虑存储方案。

先把页面目标想清楚

在真正写代码之前,先别急着盯着 API。更有用的做法是先想清楚:这个页面到底想解决什么问题,用户最在意的反馈是什么,哪些状态必须一直保持一致。

当你先把这条主线想明白,再回头看组件和状态设计,很多选择都会顺理成章。对小白来说,这一步尤其重要,因为它能帮你从“照着抄”慢慢过渡到“看得懂、改得动”。

完整 ArkTS 示例

import { preferences } from '@kit.ArkData'

@Entry
@Component
struct DraftPreferencePage {
  @State title: string = ''
  @State content: string = ''
  @State status: string = '草稿未加载'
  private store: preferences.Preferences | undefined = undefined

  async aboutToAppear(): Promise<void> {
    this.store = await preferences.getPreferences(getContext(this), 'noteDraft')
    this.title = await this.store.get('title', '') as string
    this.content = await this.store.get('content', '') as string
    this.status = '已恢复本地草稿'
  }

  private async saveDraft(): Promise<void> {
    if (!this.store) {
      return
    }
    await this.store.put('title', this.title)
    await this.store.put('content', this.content)
    await this.store.flush()
    this.status = '草稿已保存'
  }

  private async clearDraft(): Promise<void> {
    if (!this.store) {
      return
    }
    await this.store.delete('title')
    await this.store.delete('content')
    await this.store.flush()
    this.title = ''
    this.content = ''
    this.status = '草稿已清空'
  }

  build() {
    Column({ space: 12 }) {
      Text('笔记草稿')
        .fontSize(22)
        .fontWeight(FontWeight.Bold)
        .width('100%')

      TextInput({ placeholder: '标题', text: this.title })
        .onChange((value: string) => {
          this.title = value
        })

      TextArea({ placeholder: '写点内容...', text: this.content })
        .height(180)
        .onChange((value: string) => {
          this.content = value
        })

      Text(this.status)
        .fontSize(12)
        .fontColor('#777777')
        .width('100%')

      Row({ space: 10 }) {
        Button('保存草稿')
          .layoutWeight(1)
          .onClick(() => {
            this.saveDraft()
          })
        Button('清空')
          .layoutWeight(1)
          .backgroundColor('#F0F2F5')
          .fontColor('#333333')
          .onClick(() => {
            this.clearDraft()
          })
      }
      .width('100%')
    }
    .padding(16)
  }
}

手绘流程图,主题是 HarmonyOS7 preferences 草稿的完整生命周期。流程从‘页面

把关键代码一段段拆开

aboutToAppear() 里恢复草稿。页面出现时先读本地内容,用户能直接接着写,不需要自己重新输入。

saveDraft()put() 之后调用 flush()。这一步很关键,很多人只写 put(),以为数据已经稳了;但没有及时落盘,异常退出时就可能丢。

clearDraft() 同时清理本地存储和页面状态。只删本地不清 UI,用户会以为还没删;只清 UI 不删本地,下次打开又会恢复旧内容。

store 用可选类型,是因为它需要异步初始化。按钮触发时如果还没准备好,直接返回比强行使用更稳。

保存时机怎么选

示例里用按钮手动保存,适合教程理解。真实项目中可以在离开页面、输入停顿一段时间、提交失败时保存。不要每输入一个字符就落盘,频率太高没有必要。

提交成功后要清理草稿。否则用户下次打开编辑页,看到的可能是上一次已经发布成功的内容。

新手最容易踩的坑

这一类示例最容易让人产生错觉:界面出来了,就以为已经掌握了。其实真正容易出问题的地方,通常都在效果之外,比如状态有没有收拢、失败后怎么兜底、以后要扩展时会不会牵一发动全身。

所以你练这篇内容时,别只看“现在能不能跑”,还要继续看“以后好不好改”。能把这个习惯养起来,你写出来的页面会比单纯照着示例拼出来的页面稳很多。

放进真实项目还要补什么

示例代码的重点是把核心思路讲明白,所以很多工程化细节会故意省掉。真正落到项目里时,你通常还要继续补接口联动、异常处理、边界保护、资源抽离,以及和其他页面状态之间的配合。

比较稳的做法是分三步走:先把结构和职责立住,再把真实业务接进去,最后再优化视觉和交互体验。这样改出来的页面不只是“能演示”,而是真的更接近可以长期维护的业务代码。

写在最后

preferences 存草稿刚刚好:轻、快、代码也不复杂。关键是别贪心,别把大对象和复杂列表都塞进去。保存和清理边界写清楚,草稿功能就很稳。

Logo

讨论HarmonyOS开发技术,专注于API与组件、DevEco Studio、测试、元服务和应用上架分发等。

更多推荐