概述

应用数据持久化就是应用将内存中的数据通过文件或者数据库的方式保存在设备本机上。HarmonyOS标准系统支持一下三种f方式进行持久化处理：包括用户首选项、键值型数据库、关系型数据库。

用户首选项

用户首选项(Preferences) 是通过将数据(Key-Value键值)保存在文本中，以文件的形式保存在设备上，在读取或者设置数据时，会全量将文件内容加载在内存中，所以访问速度快、效率高，但是不适合用来存储大量数据，一般用户应用的基本设置，比如颜色、字体等等。

首选项运行机制

用户通过JS调用暴露的首选项接口来对数据文件进行读写操作，每一个持久化文件唯一对应一个Preferences实例，然后系统会通过静态容器将该实例存储在内存中，并对其进行操作。其中持久化文件保存在应用沙箱中，可以通过context来获取路径。

约束条件

由于首选项是通过key-value的形式保存在文件中，并全量加载到内存中进行读取，所以在存储时，添加了一些约束条件。

• Key必须是string类型，非空并且长度不可超过80字节。Value长度不超过8192个字节
• 存储数据不超过10000条，避免内存太大开销

接口说明

使用前需要在’@ohos.data.preferences’中引入首选项模块，然后通过context来获取实例并读取指定文件进行操作。以下是用户首选项持久化功能的相关接口，大部分为异步接口。异步接口均有callback和Promise两种返回形式，下图均以callback形式为例：

具体方法实例以及更多细节，请查看官网首选项实现数据持久化

键值型数据库

键值型数据库（KV-Store）是一种非关系型数据库，其数据以“键值”对的形式进行组织、索引和存储，其中“键”作为唯一标识符。可用于存储商品名称及对应价格、员工工号及今日是否已出勤等，由于数据复杂度低，更容易兼容不同数据库版本和设备类型，因此推荐使用键值型数据库持久化此类数据。

约束条件

• 设备协同数据库，针对数据库的每条记录，Key长度不超过896Byte，Value不超过4MB
• 单版本数据库，每条记录 Key不超过1KB，Value不超过4MB
• 每个应用程序最多支持同时打开16个键值型数据库
• 数据库回调中，不允许修改UI组件等进行阻塞的操作

设备协同数据库：设备协同分布式数据库建立在单版本分布式数据库之上，对应用程序存入的KV数据中的Key前面拼接了本设备的DeviceID标识符，这样能保证每个设备产生的数据严格隔离，底层按照设备的维度管理这些数据，设备协同分布式数据库支持以设备的维度查询分布式数据，但是不支持修改远端设备同步过来的数据。

单版本分布式数据库： 单版本是指数据在本地保存是以单个KV条目为单位的方式保存，对每个Key最多只保存一个条目项，当数据在本地被用户修改时，不管它是否已经被同步出去，均直接在这个条目上进行修改。同步也以此为基础，按照它在本地被写入或更改的顺序将当前最新一次修改逐条同步至远端设备。

详细的数据库分类以及细节可查看：HarmonyOS-数据管理

接口说明

使用前需在‘@ohos.data.distributedKVStore’导入模块，并根据context配置一个KVManager实例。以下是键值型数据库持久化功能的相关接口，大部分为异步接口。异步接口均有callback和Promise两种返回形式，下图均以callback形式为例

详情可查看官网：键值型数据库实现数据持久化

关系型数据库

基于SQLite组件的关系型数据库，以行和列的形式存储数据，适用于存储包含复杂关系数据的场景，比如一个班级的学生信息，需要包括姓名、学号、各科成绩等，又或者公司的雇员信息，需要包括姓名、工号、职位等，由于数据之间有较强的对应关系，复杂程度比键值型数据更高，此时需要使用关系型数据库来持久化保存数据。

基本概念

• 谓词：数据库中用来代表数据实体的性质、特征或者数据实体之间关系的词项，主要用来定义数据库的操作条件。
• 结果集：指用户查询之后的结果集合，可以对数据进行访问。结果集提供了灵活的数据访问方式，可以更方便地拿到用户想要的数据。

运行机制

关系型数据库对应用提供通用的操作接口，底层使用SQLite作为持久化存储引擎，支持SQLite具有的数据库特性，包括但不限于事务、索引、视图、触发器、外键、参数化查询和预编译SQL语句。

约束条件

• 系统默认日志方式是WAL（Write Ahead Log）模式，系统默认落盘方式是FULL模式。
• 数据库中连接池的最大数量是4个，用以管理用户的读操作。
• 为保证数据的准确性，数据库同一时间只能支持一个写操作。
• 当应用被卸载完成后，设备上的相关数据库文件及临时文件会被自动清除。

接口说明

使用前需要通过‘@ohos.data.relationalStore’导入模块，并通过context配置数据库。以下是关系型数据库持久化功能的相关接口，大部分为异步接口。异步接口均有callback和Promise两种返回形式，下图均以callback形式为例

详情可查看官网：关系型数据库实现数据持久化

总结

用户首选项Preferences

通过key-vlaue键值对的方式以文本形式保存在用户本地磁盘文件，来达到持久化的功能。可以通过putSync、getSync等api来对其进行增删改查操作，这些都是在内存中进行运行的，只有当通过首选项实例来调用flush来进行持久化的时候，才会将Preferences中的数据保存在磁盘文件中，进行持久化。用户首选项一般用于保存用户个性化配置，不适应与大型数据，因为数据越多占用磁盘就越大，同步保存的时候就越慢。
流程如下：

首选项实例和持久化文件是1:1的，一个实例对应一个文件：

PS：在调用flush进行持久化之前的所有Perferences实例的操作都是在内存的缓存区中，此时还没有进行持久化，只有调用flush之后才会进行持久化处理，将数据同步保存到本地磁盘文件，该文件是在第一次获取首选项实例的时候创建。

键值型数据库

非关系型数据库，通过distributedKVStore创建一个KVManager实例来管理数据库，用于对简单关系数据的存储。t通过用户首选项一致，所有对KVStore的操作都是在内存中进行的，只有通过commit之后才会进行持久化写入磁盘文件。

对应关系： 应用通过distributedKVStore来创建一个KVMagager，然后生成多个KVStore。对应关系：app : KVMagager : KVSTore : 缓存文件= 1: 1: n: n

关系型数据库RDB

关系型数据库用于具有复杂关系的数据存储，也可以通过executeSql直接执行SQL语句，无返回值。是基于SQLite来进行的封装，在应用中通过调用kits/framwork来调用SQLite创建数据库并进行操作。

一个应用可以有多个rdbStore实例，在生成实例的时候会创建对应的磁盘文件，多个实例会创建多个文件。并且通过insert进行插入或者delete等操作时，不需要手动调用flush进行持久化，系统会自动在操作之后同步修改本地文件。

有兴趣的朋友可以关注一下公众号,主要分享前端相关的小知识，方便随时随地一起交流学习。