【鸿蒙心迹】数据持久化实战：Preferences 与关系型数据库的分界线

前言

一多适配做完，码上清单在三档设备上都站住了。这时数据侧的债开始讨：设置项、卡片 formId 这类小数据一直散在内存里，后台被杀就丢（生命周期那篇埋过这个雷）；待办量上来之后，"全部读进内存再过滤"也开始吃力。这篇把持久化补上，核心是想清楚一条分界线：什么数据用 Preferences，什么数据必须上关系型数据库。

一、先分层，再选型

动手前把应用数据按"形状"分三类：

1. 键值小配置：主题、开关、卡片 formId——单条很小、总量有限、按 key 取；
2. 结构化业务数据：待办本身——条数会涨、要条件查询、要排序分页；
3. 文件类数据：附件、导出的备份——本来就是文件。

三类各对一种存储：键值配 Preferences，结构化数据上关系型数据库（RelationalStore），文件走文件系统。分界线就一条：需不需要"按条件查"。需要条件、排序、聚合的，塞 Preferences 里早晚返工；反过来说，为了几十个开关建表，也是给自己找事。

二、Preferences：轻，但有脾气

Preferences 的 API 很直白：put/get/flush。实操里记住三点：

• flush 的时机：写入后不 flush，数据可能只在内存里，进程被杀就没了——"后台被杀数据丢失"这种玄学问题，八成是这里；
• 别把它当数据库用：几百个 key 循环读写，启动时间立刻给你颜色看；它适合"读一次管半天"的配置；
• 大小克制：单条 value 别放大对象，大对象序列化成 JSON 塞进去，读时要整体反序列化，账不划算。

三、RelationalStore：SQL 的账，SQL 来算

待办数据迁到 RelationalStore 后，最直接的红利是查询能力：今日待办就是一条 WHERE，按截止日排序就是 ORDER BY，再不用把全量读进内存自己 filter。接入步骤不复杂：建库、建表、封装一个 DAO 层（insert/query/update/delete），UI 层不直接摸 SQL。

封装 DAO 时立了两条规矩：

1. 异步优先：数据库操作全部放异步任务，UI 线程只等结果。同步写法在数据量小的时候"感觉不到"，数据一大就是掉帧元凶——Profiler 那篇的套路正好用来验证；
2. 升级路径从第一版就有：版本号+升级回调从建表那天就写上，哪怕回调体是空的。事后补升级逻辑，比一开始就带上贵十倍。

四、踩坑三条

1. 结果集用完要关：查询返回的resultSet 遍历完记得 close，泄漏的表现是越用越卡，Profiler 里能看到内存缓涨。
2. 事务包批量写：导入一批待办逐条 insert 慢得离谱，包进事务一次提交，速度差一个量级。
3. 数据库文件跟着应用走：卸载即清，重要的数据要么按文档目录规范放用户可见区，要么提供导出备份——别让用户替你的存储方案担风险。

小结

持久化补完，应用的数据有了稳定的家：配置进 Preferences、业务进 RelationalStore、文件归文件系统。数据量一大，下一个战场自然浮现——列表渲染的性能。下一篇写长列表优化：LazyForEach 与按需加载，把滑动丝滑这件事做成工程事实。

*本文环境：DevEco Studio 5.x / HarmonyOS NEXT（API 14+）。存储 API 细节以官方《数据管理》文档为准。系列上一篇：《【鸿蒙心迹】一多适配实战》。*