HarmonyOS7 preferences 存草稿刚刚好:轻量数据要有保存和清理边界

前言
草稿数据通常不大,但对用户很重要。写到一半退出页面、应用被回收、网络提交失败,用户都希望内容还能找回来。HarmonyOS7 里 preferences 很适合保存这种轻量键值数据。
但它不是数据库,也不是万能缓存。我的习惯是提前想清楚三件事:恢复什么、什么时候保存、什么时候清理。草稿存储要及时,但不能无边界。
为什么这个问题经常被写乱
preferences 存草稿刚刚好 这类内容很容易被写成“代码能跑就算讲完了”,但对初学者来说,这恰恰是最不够的地方。真正让人卡住的,往往不是某个组件名记不住,而是不知道这段代码为什么要这样拆、状态为什么要这样放、以后需求变化时应该从哪里改。
所以这篇文章不只想给你一个能跑的例子,更想把背后的判断过程讲清楚。你只要把这个判断过程吃透,后面自己改页面、补需求、查问题时,心里会稳很多。
什么适合放进 preferences
笔记草稿是典型场景:标题和正文都是字符串,数据量小,恢复价值高。

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

把关键代码一段段拆开
aboutToAppear() 里恢复草稿。页面出现时先读本地内容,用户能直接接着写,不需要自己重新输入。
saveDraft() 里 put() 之后调用 flush()。这一步很关键,很多人只写 put(),以为数据已经稳了;但没有及时落盘,异常退出时就可能丢。
clearDraft() 同时清理本地存储和页面状态。只删本地不清 UI,用户会以为还没删;只清 UI 不删本地,下次打开又会恢复旧内容。
store 用可选类型,是因为它需要异步初始化。按钮触发时如果还没准备好,直接返回比强行使用更稳。
保存时机怎么选
示例里用按钮手动保存,适合教程理解。真实项目中可以在离开页面、输入停顿一段时间、提交失败时保存。不要每输入一个字符就落盘,频率太高没有必要。
提交成功后要清理草稿。否则用户下次打开编辑页,看到的可能是上一次已经发布成功的内容。
新手最容易踩的坑
这一类示例最容易让人产生错觉:界面出来了,就以为已经掌握了。其实真正容易出问题的地方,通常都在效果之外,比如状态有没有收拢、失败后怎么兜底、以后要扩展时会不会牵一发动全身。
所以你练这篇内容时,别只看“现在能不能跑”,还要继续看“以后好不好改”。能把这个习惯养起来,你写出来的页面会比单纯照着示例拼出来的页面稳很多。
放进真实项目还要补什么
示例代码的重点是把核心思路讲明白,所以很多工程化细节会故意省掉。真正落到项目里时,你通常还要继续补接口联动、异常处理、边界保护、资源抽离,以及和其他页面状态之间的配合。
比较稳的做法是分三步走:先把结构和职责立住,再把真实业务接进去,最后再优化视觉和交互体验。这样改出来的页面不只是“能演示”,而是真的更接近可以长期维护的业务代码。
写在最后
preferences 存草稿刚刚好:轻、快、代码也不复杂。关键是别贪心,别把大对象和复杂列表都塞进去。保存和清理边界写清楚,草稿功能就很稳。
更多推荐



所有评论(0)