HarmonyOS 实战 | 数据存本地——Preferences 轻量存储入门

一、我们想解决什么问题

咱们先聊个真实的场景。

你打开一个阅读类 App，晚上躺在床上看，屏幕太亮眼睛不舒服，于是你切到了"深色模式"。界面变成黑底白字，舒服了。你翻了十来页，标记了一个书签，然后关掉 App 睡觉。

第二天你打开同一个 App------好家伙，深色模式没了，又变成白晃晃的亮色主题；上次看到的小说第 52 章第 7 页也不记得了，又得从头翻。你是不是想骂人？

这是不是特别眼熟？

类似的场景太多了：

• 你给记事本 App 调了个字体大小，下次打开又变回默认字号
• 你设置了"开启时自动刷新"，关掉 App 再进，这个选项又取消了
• 你输入了一个收货地址格式的偏好，下次打开表单自动填充的信息全不见了
• 你就想让某个开关保持"开"的状态，但 App 每次打开都跟你玩"失忆"

这些问题的本质是什么？数据没有本地存下来。

说得技术一点，叫做"没有做数据持久化"。持久化这个词听起来唬人，说白了就是：你把一个值写进去了，下次 App 打开的时候它还在那儿------就像你在冰箱里放了一瓶可乐，第二天打开冰箱它还在，没消失。

HarmonyOS 给我们提供了好几种本地存储方案。但如果你要存的不是什么大文件、不是什么复杂的数据库，只是一些"小东西"------比如用户偏好设置、开关状态、最近一次的操作记录------那用 Preferences 是最合适的。

打个比方：如果你要搬家，大件家具叫搬家公司（那是数据库或者文件存储干的活儿），而 Preferences 就是你自己随身带的那个小背包，装钥匙、钱包、手机------轻便、快速、随拿随取。

Preferences 是什么？

它的全名叫"轻量级偏好存储"。你从名字就能看出来------它专门管"偏好"这类东西。在 HarmonyOS 里，它是以 KV 对（Key-Value，键值对）的形式来存数据的。

什么叫 KV 对？想象你有一个储物柜。每个柜子上面贴了个标签（Key），比如"深色模式开关"，柜子里面放了对应的东西（Value），比如"true"（表示开启了深色模式）。你要取东西的时候，只要看标签就行了，不用把整个柜子翻一遍。

就是这么简单。

所以今天我们聊的，就是怎么用 Preferences 来搞定这些"小数据"的本地存储问题。你不用操心什么数据库建表、什么 SQL 语句、什么文件 IO 路径------Preferences 把这些都封装好了，你只需要告诉它："帮我存一下这个值"和"帮我取一下这个值"。

---

二、数据模型设计

在开始写代码之前，咱们得先想清楚一件事：我们要存哪些数据？

这就好比你去超市买东西之前，最好列个清单------不然进去就蒙了，出来发现想买的没买，不需要的买了一堆。

今天我们要做什么示例？

咱们来做个"阅读设置面板"的 Demo。这个面板包含以下几种设置项：

1. 深色模式开关 ------ 用户是否启用了深色主题。这个值只有两种状态：开或关。用布尔值（boolean）最合适。
2. 字体大小 ------ 用户选择的字号。可能是"小""中""大""超大"这几个选项。用字符串（string）存最方便。
3. 上次阅读位置 ------ 用户上次看到哪一页。比如第 128 页。这是一个数字，用 number 类型。
4. 用户昵称 ------ 用户在 App 里设置的自定义名称。这个是个字符串。

四个设置项，四种不同的数据类型，刚好能覆盖日常使用的绝大多数场景。

用 TypeScript 定义数据模型

在 HarmonyOS 开发里，我们通常用 TypeScript 的 interface 来定义数据结构。这就好比搭了个"模板"，后面的数据都得按这个模板来。

来看代码：

// 阅读设置的数据模型
interface ReadingSettings {
  // 深色模式开关
  darkMode: boolean;
  // 字体大小：small / medium / large / xlarge
  fontSize: string;
  // 上次阅读的页码
  lastPage: number;
  // 用户昵称
  userName: string;
}

这个 interface 定义出来之后，它就像一张表格的"表头"------规定了每一列叫什么名字、是什么类型。我们的 App 在存数据、取数据的时候，都会按照这个格式来对齐。

你可能会问：如果后面还要加别的设置项怎么办？比如加个"行间距"或者"翻页动画"？很简单，在 interface 里加一行字段定义就行了。Preferences 的核心思想就是------你想存什么就存什么，只要给每个数据起个名字（Key），它就能帮你管好。 没有数据库那种"我要先改表结构"的麻烦。

这就是 KV 存储的灵活之处：每一对 key-value 都是独立的，互不干扰。你可以先存一个键，过两天再加一个新的键，完全不用动之前的数据。

但这里也得留个心眼：虽然灵活，但别滥用。Preferences 设计来存的是"配置项""偏好设置"这类少量数据，不是说让你把整个应用的业务数据全塞进去。比如用户的一千条聊天记录就别放这里了------那得用数据库。Preferences 的定位就是那个"随身小背包"，不是"搬家货车"。

---

三、核心设计决策

好，现在我们已经知道要存什么了。那接下来面临一个选择：HarmonyOS 提供了好几种本地存储方案，到底用哪个？

我把常见的三种方案拉出来对比一下，这样你一眼就能看出差别。

对比维度	Preferences（轻量存储）	KVStore（分布式键值）	关系型数据库（RDB）
数据量级	小（通常几百条以内）	中等	大（万条以上）
使用难度	⭐ 极简，两三个 API	⭐⭐ 需要初始化	⭐⭐⭐⭐ 需要建表、写 SQL
是否分布式	❌ 仅本地	✅ 可跨设备同步	❌ 仅本地
适合场景	用户偏好、开关状态、配置项	需要多端同步的数据	结构化复杂业务数据
数据类型	String / Number / Boolean / Array	String / Number / Boolean	强类型，支持各种 SQL 类型
读取性能	极快（内存缓存）	快（但有同步开销）	中等（SQL 查询开销）

现在说说我的选择。

我选 Preferences，理由很简单------我们的需求恰好就落在它最擅长的区域里：

第一，数据量很小。 深色模式开没开、字体多大、上次看到第几页......这些东西加起来可能十个手指头就数得过来。你为了存这不到十个值，去建一个关系型数据库的表？那就像用搬家货车运一个背包的东西------不是不行，但有点夸张了。

第二，不需要跨设备同步。 咱们这个阅读设置的偏好，就只在当前的手机上生效，不需要说"我在手机上设了深色模式，平板也跟着变"。KVStore 的分布式能力确实很厉害，但这里有句实在话：能力越强，需要操的心也越多。如果你的 App 就只在单设备上跑，没必要给自己加活。Preferences 一把梭就够了。

第三，开发效率。 Preferences 的 API 设计得非常"直觉化"------存数据是 put()，取数据是 get()，删数据是 delete()。就这么三个核心操作，简单到你基本不用翻文档。相比之下，关系型数据库你得先建表、再写 CRUD 的 SQL、还得处理事务......杀鸡不用牛刀，对吧？

第四，性能。 Preferences 在读取数据的时候会把常用数据缓存在内存里，第二次读的时候基本是毫秒级的，甚至感觉不到延迟。用户每次打开 App，要加载设置项的时候，Preferences 几乎是秒回的体验。这叫"润物细无声"------用户感觉不到它在工作，但每次体验都很丝滑。

但这里我也得说句公道话：Preferences 也不是万能的。

如果你的数据量大了------比如超过几百条，或者单条数据特别大（超过了 10KB），Preferences 的性能就会开始打折。这时候就该考虑数据库了。还有，Preferences 只支持基础的 KV 存储，不支持复杂查询。比如说你想"查所有字体设为'大'的用户"，那 Preferences 搞不定------它没办法像数据库那样 WHERE 一把梭。

所以选型这件事，没有什么"最好的方案"，只有"最合适的方案"。你的需求决定了你的选择。我们今天要处理的"阅读设置"刚好在 Preferences 的舒适区里，那我们就用它。

---

四、完整代码实现

好了，理论聊完了，咱们来动手。我保证这部分的代码不会多------每个代码块只展示最核心的部分，加起来不超过五个代码块，每个不超过五十行。

先把完整的工作流程走一遍：创建 Preferences → 存入数据 → 读取数据 → 删除数据。就这么四个步骤。

4.1 创建 Preferences 实例

首先，我们要创建一个 Preferences 的实例。这个过程叫做"获取 Preferences 对象"------通俗说就是"先打开那个存数据的小本本"。

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

// 获取上下文
const context: common.Context = getContext(this);
// 创建一个名为 'reading_prefs' 的 Preferences 存储实例
const prefs: preferences.Preferences = await preferences.getPreferences(context, 'reading_prefs');

这段代码是什么意思呢？

第一行，import { preferences } from '@kit.ArkData'------这是在导入 HarmonyOS 提供的数据管理 Kit，Preferences 就住在里面。

第三行，getContext(this)------拿到当前应用的上下文。你可以把上下文理解成"应用的身份证明"，后面很多系统级的操作都需要用到它。Preferences 也是一样，它需要知道"这是哪个 App 的数据"，所以得先拿上下文。

第四行是核心：preferences.getPreferences(context, 'reading_prefs')------这是在告诉系统："帮我在本地创建一个名为 reading_prefs 的存储区域"。这个 'reading_prefs' 就像是一个文件夹的名字，每个 Preferences 实例都有自己的名字。后续的读写操作都基于这个区域。

值得一提的是，getPreferences 是异步的（async），所以前面加了 await。它会在第一次调用时创建文件，后续调用就直接读缓存------所以第二次及以后的速度非常快。

4.2 写入数据

实例拿到了，接下来就是存数据。Preferences 的存数据操作叫 put------英文里就是"放进去"的意思，非常形象。

// 写入一条数据：是否使用深色模式
await prefs.put('darkMode', true);

// 写入字体大小
await prefs.put('fontSize', 'medium');

// 写入上次阅读位置（页码）
await prefs.put('lastPage', 128);

// 写入用户昵称
await prefs.put('userName', '小张三');

// 别忘了 flush！把数据真正刷到磁盘上
await prefs.flush();

看到没？就这么简单。put 的第一个参数是"标签"（Key），第二个参数是"值"（Value）。你把标签贴好了，东西放进去了，齐活。

你可能会注意到，我写了好几个 put，最后才调了一个 flush。这是 Preferences 的一个设计特点：写操作默认是先缓存在内存里的 ，就像你把东西先放在了桌面上，还没有收到抽屉里。调了 flush() 之后，内存里的数据才会真正写到磁盘上，确保 App 关了也不会丢。

为什么不每次 put 完都自动 flush？因为磁盘读写比内存慢得多。如果用户连续修改十个偏好设置，每次都刷到磁盘，那就多浪费了九次 IO 操作。Preferences 的做法是让开发者自己决定什么时候一次性刷下去------这是一个性能取舍。

当然，如果你忘记了调 flush，而 App 突然崩溃了，那未刷盘的数据就会丢失。所以记得：改完设置了，就调一次 flush。

从 API 12 开始，Preferences 也支持了不带 flush 的"自动刷盘"模式（通过 put 时传入特定参数可以自动持久化），但为了更安全的习惯，手动 flush 仍然是我推荐的写法------你能掌控数据什么时候落盘。

4.3 读取数据

存完了，怎么取出来？用 get。

// 读取深色模式开关（默认值设为 false）
const isDarkMode: boolean = await prefs.get('darkMode', false);

// 读取字体大小（默认值设为 'medium'）
const fontSize: string = await prefs.get('fontSize', 'medium');

// 读取上次阅读页码（默认值设为 1）
const lastPage: number = await prefs.get('lastPage', 1);

// 读取用户昵称（默认值设为空字符串）
const userName: string = await prefs.get('userName', '');

console.info('深色模式：' + isDarkMode);
console.info('字体大小：' + fontSize);
console.info('上次看到第' + lastPage + '页');
console.info('用户昵称：' + userName);

get 也是两个参数：第一个是 Key（你要取什么），第二个是默认值。

这个默认值很关键。你想，如果用户是第一次打开 App，之前根本没存过任何数据，那 get('darkMode') 应该返回什么？null？undefined？还是 false？Preferences 的做法是让你提供一个"如果没存过就返回这个"的备用值。这就是第二个参数的作用。

这么做有一个好处：你的代码里不用写大量的空值判断。 默认值体系保证了返回值永远是有效数据------如果用户没设过，那就走默认的。对用户来说，App 打开就有合理的默认配置，体验很流畅。

这里有个小细节：get 方法的返回值类型需要和默认值的类型匹配。也就是说，prefs.get('darkMode', false) 的时候，默认值传了 false（boolean），那返回的就是 boolean 类型。如果你传 prefs.get('darkMode', 'false')，默认值变成了字符串，那返回类型就是 string。所以写的时候要注意类型一致性。

4.4 删除单条与清空

有时候用户想把某个设置恢复到默认状态------比如重置字体大小。这时候就需要删除数据了。

// 删除单条数据
await prefs.delete('lastPage');
await prefs.flush();

// 或者整个清空------就像恢复出厂设置
await prefs.clear();
await prefs.flush();

delete 是删一条；clear 是把整个 reading_prefs 里的数据全清空。用哪个取决于你的场景------是想"删掉一个设置"，还是"把用户的所有偏好恢复默认"。

HarmonyOS 还有一个跟 Preferences 配合得很好的机制：持久化订阅。你可以监听某个 Key 的变化，比如当用户改了深色模式，你可以自动更新 UI：

prefs.on('change', (key: string) => {
  if (key === 'darkMode') {
    // 自动切换主题
    applyTheme(prefs.get('darkMode', false));
  }
});

但要注意，这个监听器是比较轻量的通知机制，不是事件总线------别在上面挂太多复杂逻辑。而且从 API 12 开始，建议用 PreferencesChangeCallback 配合 on('multiSettingsChange') 来批量处理变更，性能和可维护性更好。这里先提一句，不展开，后续深入聊监听机制的时候再说。

4.5 完整的使用函数

最后，我把上面这些操作整合成一个完整的使用示例，方便你直接复制过去跑：

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

export class SettingsManager {
  private prefs: preferences.Preferences | null = null;
  private readonly storeName = 'reading_prefs';

  // 初始化 Preferences
  async init(context: common.Context): Promise<void> {
    this.prefs = await preferences.getPreferences(context, this.storeName);
    console.info('Preferences 初始化完成');
  }

  // 保存所有阅读设置
  async saveSettings(settings: ReadingSettings): Promise<void> {
    if (!this.prefs) throw new Error('未初始化');
    await this.prefs.put('darkMode', settings.darkMode);
    await this.prefs.put('fontSize', settings.fontSize);
    await this.prefs.put('lastPage', settings.lastPage);
    await this.prefs.put('userName', settings.userName);
    await this.prefs.flush();
    console.info('设置已保存');
  }

  // 读取所有阅读设置
  async loadSettings(): Promise<ReadingSettings> {
    if (!this.prefs) throw new Error('未初始化');
    return {
      darkMode: await this.prefs.get('darkMode', false),
      fontSize: await this.prefs.get('fontSize', 'medium'),
      lastPage: await this.prefs.get('lastPage', 1),
      userName: await this.prefs.get('userName', ''),
    };
  }

  // 重置指定设置（删掉对应 Key）
  async resetSetting(key: string): Promise<void> {
    if (!this.prefs) throw new Error('未初始化');
    await this.prefs.delete(key);
    await this.prefs.flush();
  }
}

这个 SettingsManager 你可以理解成一个"管家"------它帮你统一管理所有跟设置相关的存取操作。init 负责启动并连接数据源，saveSettings 负责批量保存，loadSettings 负责批量读取，resetSetting 负责删除某一条。麻雀虽小，五脏俱全。

你看，没有任何复杂的 SQL 语句，没有建表的过程，没有事务管理------就是 put、get、delete、flush 四个操作，来回组合。这就是 Preferences 的"轻量"所在。

---

五、深度技术原理

很多文章写到上面那一步就结束了------代码给你了，你用就完了。但既然是"揉碎了讲"，咱们还得往深挖一层，让你不光会用，还知道它背后是怎么工作的。

Preferences 的内部结构

Preferences 在底层到底是怎么存数据的？它在文件系统里是一份 XML 文件。

没错，就是那种带着 <tag> 和 </tag> 的 XML 格式。每个 Key 对应一个 XML 节点，Value 编码在里面。不过这些都是系统帮你打理好的，你不需要自己去碰这个文件，也不需要关心它的格式------但你得知道有这么个东西存在，这样你才能理解它的一些行为。

比如，Preferences 不擅长存大量数据，为什么？因为这个 XML 文件每次 flush 的时候都是全量写入的------不是说"只修改了一个 key，就只改那一行"，而是把整个文件重新写一遍。如果你的数据量大了（几百个 key 或者单条数据很大），磁盘 IO 开销就会线性增长。

再比如说，为什么 Preferences 的读取很快？因为它有个内存缓存层 。初始化的时候，它会把这个 XML 文件整个读到内存里，变成一个 Map（映射表）。后续的 get 操作根本不碰磁盘，直接从内存 Map 里取，所以速度特别快。

这个设计其实挺巧妙的：写入走"先记内存 → 后统一刷盘"的延迟写策略，读取走"一次加载 → 全程内存访问"的路子。读多写少？完美匹配。

与其他存储方案的数据对比

咱们来做一个非常接地气的性能对比。

假如你的 App 里有 50 条配置项，每条数据平均大小 256 字节，总数据量大约只有 12.5KB------还不到一张普通自拍照片的十分之一。这种量级下，Preferences 的初始化加载时间基本在 5ms 以内，单次 get 操作在 0.1ms 级别。如果你用数据库来存同样这 50 条数据，光是建立数据库连接、建表、写 SQL，启动时间就要多费几十甚至上百毫秒。为了 50 条配置，不值得。

但反过来，如果你的数据量到了 10 万条，Preferences 就会变得很吃力------因为每次 flush 都是全量写，10 万条数据序列化成 XML 再写磁盘，那延迟就不是毫秒级了，可能是几百毫秒甚至秒级了。而且全部加载到内存，也占空间。到那个量级，数据库才是正解。

所以记住这个判断尺度：50 条以内无脑 Preferences，500 条以上慎重，上千条换数据库。 中间带区域不绝对，得结合单条数据大小和读写频率判断。

线程安全与并发

Preferences 在 HarmonyOS 里设计为线程安全的。也就是说，你不用担心多个异步任务同时读写同一个 Preferences 实例会导致数据错乱。系统内部做了锁机制来保证一致性。

但这不代表你完全不用操心。一个常见的坑是：不要同时创建多个指向同一个存储名字的 Preferences 实例。 比如你在 A 页面调了 getPreferences(context, 'reading_prefs')，又在 B 页面调了同样名字的 getPreferences(context, 'reading_prefs')------虽然系统会尽量复用同一个实例，但在某些极端并发场景下，还是可能出现不一致的情况。最佳实践是：同一个存储名字，在整个应用生命周期里只初始化一次，全局共享。

上面代码里写的 SettingsManager 设计成了单例的使用模式------通过类来封装，外部只调用它的方法，不直接创建第二个 Preferences 实例。这样做的好处是：所有数据访问都通过同一个管家，不会出现"左手不知道右手做了什么"的问题。

Preferences 的生命周期

Preferences 的数据会跟随应用的生命周期。简单来说：

• 应用卸载 → Preferences 数据被清除
• 应用清除缓存 → Preferences 数据可能被清除
• 应用更新（覆盖安装） → Preferences 数据通常保留
• 系统设置中清除应用数据 → Preferences 数据被清除

这一点在设计时要留意。如果你的 App 存储了"用户是否已经完成新手引导"这个标记------当 App 更新后，Preferences 数据在大多数情况下是保留的，所以用户不会重新走一遍新手引导。但如果你需要"每次更新都重置某些设置"，那你就得在更新后的首次启动时，手动去删除或重置那些 key。

HarmonyOS 从 API 10 开始提供了 preferences.removePreferencesFromCache(context, name) 方法，你可以在特定时机主动释放 Preferences 占用的内存------比如在不需要某个存储实例的时候，调这个方法来释放内存资源。对于长时间运行的后台 Service，这是个有用的优化点。

数据隐私与安全

Preferences 的数据是存储在应用私有目录下的。这意味着其他应用无法访问你的 Preferences 数据。在 HarmonyOS 的安全模型下，每个应用有自己独立的沙箱环境，Preferences 文件就在这个沙箱里。

但有一个注意事项：Preferences 不是加密存储的。 如果你存的是明文密码、密钥、Token 等敏感信息，Preferences 不合适------因为 XML 文件里就是原始文本。敏感信息请用 HarmonyOS 的安全存储方案（如 @kit.ArkData 里提供的加密存储能力，或者使用密钥管理服务）。

所以在设计数据模型的时候，建议做个简单的"脱敏检查"：问自己一句，"这个值如果被别人看到了会有什么问题？" 如果是"深色模式是否开启"、"字体大小"这类信息，随便看，没问题。如果是"用户自动登录的 Token"，那就得用加密方案了。

总结一下 Preferences 的核心原理：

1. 数据是 XML 文件，存储在应用私有沙箱目录下
2. 加载时全量读入内存，后续读取不碰磁盘------读取接近于"白嫖"
3. 写入走内存缓存 + flush 触发全量刷盘------小数据高效，大数据吃力
4. 线程安全------多任务并发不用太担心，但注意实例唯一性
5. 非加密------敏感信息另寻他法

这套设计思路其实在移动开发领域不是 HarmonyOS 首创的------Android 有 SharedPreferences，本质上和这个如出一辙。但 HarmonyOS 在这个基础上做了一些优化，比如 API 更简洁、类型安全更好、异步模型更一致。一句话总结：站在前人的肩膀上，做了一些更适合鸿蒙生态的调整。

---

六、常见问题解答

Q1: Preferences 能存多少条数据？

A: 官方没有硬性限制条数，但工程上建议控制在 200 条以内，单条数据大小不超过 1MB，整体数据量不超过 10MB。原因就是上文说的------flush 是全量写入，数据多了写入性能会明显下降。超过这个量级，建议上数据库。

Q2: 我能不能存一个对象（Object）进去？

A: 可以直接存数字、字符串、布尔值、数组这些基础类型。如果要存复杂的嵌套对象，建议用 JSON.stringify() 转成字符串再存，读的时候用 JSON.parse() 转回来。比如：

const userConfig = { theme: 'dark', lineSpacing: 1.5 };
await prefs.put('userConfig', JSON.stringify(userConfig));

const raw = await prefs.get('userConfig', '{}');
const config = JSON.parse(raw);

这是一种很常见的"曲线救国"方案。有约 5-10% 的小性能开销，但对于配置项完全够用。

Q3: flush 忘记调了会发生什么？

A: 这是个好问题。如果你调了 put 但没调 flush，而 App 在这个间隙被系统杀死了（比如后台被回收、崩溃了），那内存里缓存的修改就会丢失。所以"先 put 后 flush"应该形成肌肉记忆。不过从 API 12 开始，Preferences 也提供了自动刷盘的选项，但手动 flush 更可控。

Q4: 如果我同时在多个页面读写同一个 Preferences 会冲突吗？

A: 线程安全层面，系统做了锁保护，不会出现数据错乱。但可能出现"脏读"------比如 A 页面写入了一个值但还没 flush，B 页面读到的还是旧值。通常影响不大，因为 flush 很快。如果你的场景对实时一致性要求高（比如 A 写入后 B 必须立刻读到），那可以考虑在读取前主动调一次 flush。

Q5: Preferences 和数据库可以混用吗？

A: 当然可以，而且这是很常见的设计。比如一个笔记 App：笔记的正文和列表用数据库存（数据量大、需要搜索），而用户偏好的主题、字体、排序方式用 Preferences 存。两者各司其职，互不干扰。这也是架构设计里"使用合适的工具做合适的事"的体现。

Q6: 我的 Preferences 文件在哪？能自己手动改吗？

A: 在应用沙箱目录下的某个路径，具体是由系统管理的。不建议也不应该手动去修改这个文件------首先你还需要设备 root 权限才能访问到沙箱目录，其次手动修改可能会破坏文件格式，导致整个 Preferences 实例加载失败。所有的读写操作通过 API 来完成就好，别去动那个文件。

Q7: Preferences 能存图片或者文件吗？

A: 不能。Preferences 只能存字符串、数字（整数和小数）、布尔值这些"原子"类型。如果你想存一张图片、一个 PDF、一段录音，那就不是 Preferences 该干的活了------得用文件存储（通过 file.fs 相关 API）或者数据库。Preferences 的定位非常明确：小数据、简单值、键值对。别让它干超出能力范围的事。

---

七、运行效果

下面我们用 ASCII 字符画来模拟 App 的运行效果。想象你打开了一个阅读 App，第一件事就是加载之前保存的设置：

当用户点击"保存设置"按钮时，发生的事情：

然后第二天你再次打开 App：

你看，从用户的角度来说，一切都很自然------我昨天怎么设置的，今天打开还那样。这种体验的好，是用户说不出来但能感受到的。那些让你"每次都要重新设一遍"的 App，为什么觉得不好用？就是因为没有做数据持久化。

---

八、扩展方向

到这儿，Preferences 的核心内容基本都讲完了。但学习和实践的边界不止于此，我列几个可以继续深入的方向，给你一些灵感。

1. 与 UI 状态管理联动

Preferences 存的只是"数据"，怎么把数据和 UI 连接起来？在 HarmonyOS 开发里，你可以结合 @State 和 @Link 装饰器，让数据变化自动刷新界面。更进阶一点，可以用 AppStorage 配合 Preferences 做全局状态同步------AppStorage 是 ArkUI 提供的应用级状态存储，它和 Preferences 的区别是：AppStorage 只在运行时存在，App 一关就没了；Preferences 是持久化的。两者结合的方式是：App 启动时从 Preferences 读数据，写入 AppStorage；用户修改时，AppStorage 变 → 同步到 Preferences → flush。

2. 多用户场景的隔离

如果你的 App 支持多账号切换，那每个账号的偏好设置不应该混在一起。可以在 Preferences 的存储名字上做文章：比如 'reading_prefs_user_001' 和 'reading_prefs_user_002'，每个用户一个独立的存储实例。切换账号的时候，切换对应的 Preferences 实例就行了。

3. 配合云备份

Preferences 数据存在本地，但如果用户换手机了，这些偏好就丢了。想要更好的体验，可以考虑把 Preferences 中的数据同步到云端------在用户切换设备的时候，从云端拉取偏好设置，恢复到本地。HarmonyOS 的 @kit.ArkData 提供了 KVStore 的分布式能力，如果你真的需要多端同步，可以从 Preferences 平滑迁移到 KVStore------因为它们的数据模型（键值对）是一样的，迁移成本不高。

4. 性能监控

在开发阶段，可以在 Preferences 的读写操作前后加上时间戳，统计每次操作的耗时。如果在真机测试时发现 flush 耗时超过 100ms，那就该考虑是不是 Preferences 里数据太多了，或者检查单条数据是不是太大了。保持对性能的敏感，是做好"轻量"的关键。

5. 监听数据变更做更丰富的业务逻辑

前面提到了 on('change') 的用法，但这个能力的想象空间其实挺大的。举个例子：你的阅读 App 有个"每日阅读提醒"功能，要求在字体大小改到"超大"时弹出提示"考虑减少阅读时间以保护视力"。通过 Preferences 的变更监听，你可以在 fontSize 改变的那一刻触发这个逻辑------不需要轮询、不需要手动判断。

6. 多 Process 并发写入

如果你的 App 使用了多进程架构（比如在主进程和后台 Service 进程里分别读写 Preferences），需要注意：不同进程各自维护自己的 Preferences 实例，不会自动同步。这种情况下建议用数据库做存储，或者通过 IPC（进程间通信）让所有写入操作都通过主进程完成。

---

结语

聊到这里，关于 Preferences 轻量存储的话题就到尾声了。你可以发现，它其实没有太多花哨的东西------一个结构简单、API 极简、性能出色的本地存储方案，专门处理"小数据"的场景。它不追求大而全，而是在自己擅长的领域里做到极致。

这其实也是写代码的一个道理：不是每个问题都需要一个复杂的解决方案。有时候，最简单直接的方案就是最好的方案。Preferences 这样的方案，就像一个可靠的伙伴------平时安静地待在后台，不刷存在感，但每次你需要它的时候，它都在那里。

下次你的 App 需要存用户的偏好了，记得想到它。

---