HarmonyOS 6.1 全场景实战｜《灵犀厨房》实战（二十九）：【偏好持久化】偏好设置与推荐引擎联动——让 App 越用越“懂你”

IT喂嘟盲

498人浏览 · 2026-06-08 08:50:58

IT喂嘟盲 · 2026-06-08 08:50:58 发布

HarmonyOS 6.1 全场景实战｜《灵犀厨房》实战（二十九）：【偏好持久化】偏好设置与推荐引擎联动——让 App 越用越“懂你”

摘要：前面 28 篇中，用户在个人中心设置了口味偏好和过敏源，但 App 重启后全部丢失——因为这些数据只存在内存里。推荐引擎虽然已经写好了过敏源过滤逻辑（isSafe()），但从未与偏好设置真正联动。本篇利用 HarmonyOS 的 preferences API 实现偏好持久化，并打通偏好→推荐的数据链路——用户设置一次偏好，App 永久记住，推荐结果自动规避过敏源、响应口味变化。全程不改推荐引擎核心代码，仅新增约 30 行持久化逻辑。

一、引言：被遗忘的“口味档案”

一个实验：在第 28 篇的基础上，打开个人中心，设置口味偏好为“快手菜、高蛋白”，忌口为“花生、海鲜”。然后关掉 App，重新打开。

偏好设置全部恢复默认——App 完全忘记了你的口味和忌口。

更糟糕的是：推荐引擎虽然已经写好了 isSafe() 方法（过滤过敏源）和 calcScore() 方法（偏好标签加分），但从未被调用过。用户设置过敏源后，推荐结果依然包含“宫保鸡丁”（含花生）；用户偏好高蛋白，推荐引擎却一无所知。

问题	根因	影响
偏好设置重启丢失	数据只在内存中	每次启动都要重新设置
过敏源过滤未生效	`isSafe()` 写了但没人调用	花生过敏用户仍被推荐含花生的菜
偏好加分未生效	`calcScore()` 的偏好逻辑闲置	推荐引擎是“无差别推荐”

🎯 本篇目标：用 preferences API 将偏好持久化到本地文件，App 重启后自动恢复；打通偏好→推荐的完整数据链路，让 isSafe() 和偏好加分真正生效。推荐引擎核心代码零改动，持久化代码仅约 30 行。

二、核心原理：preferences API 的“便签本”模型

2.1 为什么是 preferences 而非 RelationalStore？

HarmonyOS 提供了两种本地持久化方案：

方案	数据结构	适用场景	本篇选型
preferences	键值对（KV）	少量结构化数据（设置、偏好、Token）	✅
RelationalStore（SQLite）	表 + SQL	结构化数据（收藏、历史、订单）	❌（第 28 篇已使用）

口味偏好是典型的 KV 场景——一个用户只有一组偏好，不需要复杂查询，不需要多表关联。用 SQLite 就像用杀牛刀杀鸡：能做，但太重。

你可以把 preferences 想象成一个便签本：你写下一行“喜欢的口味：快手菜、高蛋白”，合上本子（flush），下次打开还在。不需要建表、不需要写 SQL、不需要管理连接——三行代码搞定写入，一行代码搞定读取。

2.2 使用模式

import { preferences } from '@kit.ArkData';

const PREF_NAME = 'LingxiKitchen_prefs';
const prefs = await preferences.getPreferences(context, PREF_NAME);

// 写入
await prefs.put('favoriteTags', JSON.stringify(['快手菜', '高蛋白']));
await prefs.put('allergies', JSON.stringify(['花生', '海鲜']));
await prefs.flush();  // 必须 flush 才会持久化到文件

// 读取
const tags = prefs.getSync('favoriteTags', '[]') as string;
const parsed = JSON.parse(tags);  // ['快手菜', '高蛋白']

关键三个操作：

put(key, value)：写入键值对，value 只能是 string/number/boolean
flush()：将内存中的修改刷入磁盘。没有这一步，App 崩溃或被杀后数据丢失
getSync(key, default)：同步读取。default 在首次启动（Preferences 为空）时作为兜底值

三、数据流全景

图一解读：这张全景图展示了偏好数据从用户设置到推荐结果的完整链路。上半部分是写入路径——用户设置偏好 → save() → persistPreferences() → prefs.put + flush() → 持久化到本地文件。下半部分是读取路径——首页加载 → refreshByPreference() → getSync() 读取 Preferences → 构造 UserPreference → 传入推荐引擎 → isSafe() 过滤过敏源 + calcScore() 偏好加分。一套数据，两条路径，推荐引擎零改动。

四、实战步骤

Step 1：ProfileViewModel 新增持久化方法

在 ProfileViewModel 中新增 loadPreferences 和 persistPreferences 两个方法：

/**
 * 启动时加载持久化偏好
 * 在 ProfileTabContent.aboutToAppear 中调用
 */
async loadPreferences(context: common.UIAbilityContext): Promise<void> {
  try {
    const prefs = await preferences.getPreferences(context, 'LingxiKitchen_prefs');
    const favTags = prefs.getSync('favoriteTags', '[]') as string;
    const allergies = prefs.getSync('allergies', '[]') as string;
    const maxCal = prefs.getSync('maxCalories', 800) as number;
    if (favTags !== '[]') {
      this.preference = {
        favoriteTags: JSON.parse(favTags),
        allergies: JSON.parse(allergies),
        maxCalories: maxCal
      };
      console.info('[ProfileVM] 偏好已从本地加载');
    }
  } catch (err) {
    console.warn('[ProfileVM] 加载偏好失败:', JSON.stringify(err));
  }
}

/**
 * 保存时持久化偏好
 * 在 save() 方法中调用
 */
async persistPreferences(context: common.UIAbilityContext): Promise<void> {
  try {
    const prefs = await preferences.getPreferences(context, 'LingxiKitchen_prefs');
    await prefs.put('favoriteTags', JSON.stringify(this.preference.favoriteTags));
    await prefs.put('allergies', JSON.stringify(this.preference.allergies));
    await prefs.put('maxCalories', this.preference.maxCalories);
    await prefs.flush();
    console.info('[ProfileVM] 偏好已持久化');
  } catch (err) {
    console.error('[ProfileVM] 持久化失败:', JSON.stringify(err));
  }
}

关键设计点：

getSync(key, default) 的第二个参数 '[]' 是兜底值——首次启动时 Preferences 为空，返回空数组 JSON 字符串，JSON.parse('[]') 返回空数组，偏好保持初始状态
数组类型需要 JSON.stringify 序列化——preferences 只支持 string/number/boolean 三种原生类型
flush() 在 put 之后必须调用——它是持久化的“确认键”，没有它，数据只在内存中

Step 2：save() 中接入持久化

在现有的 save() 方法中，云端同步之后追加本地持久化：

async save(): Promise<void> {
  this.isSaving = true;
  // ... 原有云端同步逻辑（authViewModel.updateProfile 等）...
  
  // ★ 新增：本地持久化（独立于云端同步，离线模式依然有效）
  const ctx = getContext(this) as common.UIAbilityContext;
  await this.persistPreferences(ctx);
  
  this.isSaving = false;
}

设计考量：本地持久化在云端同步之后执行——不阻塞云端请求，也不依赖云端结果。即使用户离线，偏好依然能保存到本地。

Step 3：推荐联动——isSafe() 和偏好加分已就绪

RecommendEngine 中的过敏源过滤逻辑从最早就已写好，在推荐方法的 filter 链中已调用：

const scored = allRecipes
  .filter(r => this.isSafe(r, preference.allergies))  // ← 过敏源过滤
  .filter(r => preference.maxCalories <= 0 || r.calories <= preference.maxCalories)
  .map(r => ({ recipe: r, score: this.calcScore(r, preference, ingredients) }));

本篇无需修改 RecommendEngine 的任何代码——只需要确保传入的 preference 对象携带从 Preferences 加载的真实数据，而非默认空偏好。数据流打通后，推荐引擎自动生效。

Step 4：完整交互时序

图二解读：这条时序图展示了偏好持久化与推荐联动的完整闭环。用户设置过敏源后，persistPreferences 写入本地文件。下次进入首页时，refreshByPreference 从 Preferences 读取过敏源，构造 UserPreference 对象，传入推荐引擎。引擎的 isSafe() 自动过滤含过敏源的菜谱——calcScore() 也同步生效，为偏好标签匹配的菜谱加分。整套链路中，用户只做了一次设置，App 永久记住，推荐结果自动响应。

五、代码交付清单

文件	新增/修改	行数	说明
`ProfileViewModel.ets`	新增 `loadPreferences()`	+15	启动时从 Preferences 恢复偏好
`ProfileViewModel.ets`	新增 `persistPreferences()`	+12	保存时持久化偏好到文件
`ProfileViewModel.ets`	修改 `save()`	+3	调用 `persistPreferences`
`RecommendEngine.ets`	无需修改	0	`isSafe()` 和偏好加分已就绪

六、设计决策

决策	选择	理由
存储方案	preferences（KV）而非 RelationalStore（SQLite）	偏好是少量 KV 数据，不需要复杂查询
数组序列化	`JSON.stringify` + `JSON.parse`	preferences 只支持 string/number/boolean，数组必须转字符串
读取方式	`getSync(key, default)`	同步读取避免异步回调嵌套，默认值保证首次启动不报错
过敏源匹配	`ing.toLowerCase().includes(a.toLowerCase())` 模糊匹配	“花生油"匹配"花生”，避免精确匹配遗漏
持久化时机	`save()` 中云端同步之后	不阻塞云端请求，离线模式依然有效
推荐引擎	零改动	`isSafe()` 和偏好加分从第 1 篇就已写好，本篇只打通数据链路