【开源鸿蒙开发板应用升级适配大赛】API20 数据篇：从ohos.data到ArkData的“搬家”实录-洪萨配资

前言

家人们谁懂啊！在开源鸿蒙适配大赛里跟数据模块死磕的日子，简直像给旧房子翻新——API9时代的ohos.data是凑活住的老破小，API20的kit.ArkData直接是带智能管家的精装房。

咱就着润和Dayu200（RK3568）这块“性能猛将”，边踩坑边唠嗑，把这场数据模块的“乔迁之喜”给大伙盘明白。

先交代背景：本次大赛核心任务之一，就是把API9的老应用拽进OpenHarmony 6.0（API20）的怀抱。咱手里的Dayu200开发板，RK3568芯片算力拉满，跑API9的老代码纯属“高射炮打蚊子”。而数据模块作为应用的“粮仓”，从ohos.data到ArkData的迁移，堪称这场升级里最关键也最容易爆雷的环节——毕竟“粮仓”搬不明白，应用再花里胡哨也是空架子。

关键变化（API 20 vs 旧版）

维度	API 9-12（旧版）	API 20（NEXT）
导入方式	`import relationalStore from '@ohos.data.relationalStore'`	`import { RdbStore } from '@kit.DataKit'`
核心类名	`relationalStore`（模块对象）	`RdbStore`（类）
权限配置	需申请存储权限	无需手动申请（系统自动授权）
初始化方式	基于`context`获取实例	基于`DatabaseConfig`构建

一、API9的ohos.data：当代“糙汉式”数据管家

在API9时代，ohos.data给人的感觉就是“能用但膈应”。咱举个大赛里常见的场景：做个健康生活应用存每日步数、睡眠时长这些数据，用ohos.data的Preferences接口，那体验简直绝了——存个健康数据就存不住，后台杀进程后再打开，部分历史数据直接“凭空消失”，跟闹脾气似的。更要命的是健康数据关联性差，想统计一周步数趋势，得手动遍历拼接数据，繁琐又容易出错。

结果发现是这几个文件里的模块引用还需要调整！

更坑的是它的“兼容性洁癖”：在Dayu200上跑着好好的，换个其他开发板就大概率崩给你看，数据读取要么乱码要么超时。就像个认死理的老管家，只懂一套规矩，稍微换个环境就罢工。而且功能贫瘠到令人发指，想做个跨设备数据同步？想给数据库加个加密？别想了，要么自己撸代码造轮子，要么乖乖接受“裸奔”式数据管理，主打一个“凑活过”。

最致命的是它的接口混乱，各种数据存储方式各自为战，Preferences、KV存储、关系型数据库凑在一起像一盘散沙，健康应用里既要存简单的步数阈值（KV存储），又要存复杂的睡眠周期明细（关系型数据库），写代码时得反复切换思路，调试起来更是头皮发麻。参赛选手谁没为了ohos.data的一个报错，在Dayu200的串口日志里扒半天bug？尤其每次提交代码给AtomGit的老师检查，都得先把这些数据模块的报错藏好，别提多窘迫了，我愿称之为“API9数据人的共同噩梦”。

如果您还是不清楚这里面的情况，请参考API20最新的文档👇

通过关系型数据库实现数据持久化 (ArkTS)

https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/data-persistence-by-rdb-store

二、ArkData登场：数据管理界的“全能优等生”

如果说ohos.data是糙汉，那kit.ArkData就是自带全套技能包的全能管家。OpenHarmony 6.0把数据模块大重构，统一归入kit.ArkData麾下，直接解决了老版本的一堆沉疴旧疾，用起来那叫一个丝滑。

所以！！

在HarmonyOS中， API引入从@kit与@ohos有哪些不同？

https://segmentfault.com/q/1010000045196118

首先是“规矩统一”：ArkData搞了标准化数据类型（UTD）和数据结构，不管是 Preferences、KV-Store 还是 RelationalStore，都遵循一套接口规范。以前在ohos.data里切换存储方式要换一套逻辑，现在就像换个抽屉放东西，操作逻辑不变，上手成本直接砍半。对参赛选手来说，这意味着少写很多重复代码，多留时间优化功能冲奖项，简直是大赛福音。

其次是“能力拉满”：咱在Dayu200上实测，ArkData的KV-Store支持分布式场景，健康数据跨手机、穿戴设备同步再也不用自己造轮子，几行代码就能实现多端数据互通；关系型数据库自带加密功能，创建时加个参数就能给步数、睡眠等敏感健康数据上保险，再也不用担心隐私信息“裸奔”，这也是健康应用的核心刚需。更绝的是它的订阅能力，数据一变立马触发回调，比ohos.data的“延迟响应”快了不止一个档次——之前存睡眠数据要等半秒才更新趋势图表，现在数据同步完成瞬间就能刷新，Dayu200的算力总算没被浪费，AtomGit的老师看了都夸数据响应够丝滑。

还有个隐藏福利：ArkData完美适配Stage模型，跟API20的其他新特性无缝衔接。咱升级时发现，用ArkData存储的数据，配合ArkUI的状态管理，界面响应速度直接起飞，再也没有“数据改了界面不动”的尴尬。这对追求流畅体验的参赛作品来说，简直是加分项拉满。

三、实战迁移：在Dayu200上搞定“搬家”全流程

光说不练假把式，咱就以本次大赛的健康生活应用为例，结合AtomGit老师指导时强调的要点，说说在Dayu200上从ohos.data迁移到ArkData的关键步骤，全程避坑指南安排上，也算是把老师的经验分享给大伙。

第一步：先给项目“换身份证”。在package.json里把compileSdkVersion和targetSdkVersion都改成20，同时把模块类型指定为stageMode。这一步千万别漏，不然ArkData的接口根本调不通，相当于给精装房装了老水管，白忙活一场。

第二步：接口“换血”。把原来import的“ohos.data.preferences”“ohos.data.relationalStore”这些，统一换成“@kit.ArkData”开头的接口。比如Preferences的创建，老代码要写一堆繁琐的路径配置，ArkData直接用getPreferences接口，一行代码就能搞定，还自带异常处理，比老版本省心太多。这里提醒一句：别直接复制粘贴改路径，ArkData的部分接口参数有优化，比如数据库加密参数是新增的，得按新文档调整。

* See the License for the specific language governing permissions and * limitations under the License. */ import { relationalStore } from '@kit.ArkData'; import ColumnInfo from '../../../viewmodel/ColumnInfo'; export interface RdbHelper {

* @param values - indicates the row of data {@link ValuesBucket} to be inserted into the table. * @returns the number of affected rows. */ insert(tableName: string, values: relationalStore.ValuesBucket | Array<relationalStore.ValuesBucket>): Promise<number>; /** * Updates data in the database based on a specified instance object of RdbPredicates.

导入关系型数据库模块： ```typescript import data_rdb from '@kit.ArkData'; ```

第三步：Dayu200上实测调试。迁移完别着急提交，在开发板上多测几遍健康应用的关键场景：反复读写步数、睡眠数据看是否卡顿，重启应用验证历史健康数据是否持久化，跨设备同步（有条件的话）看是否稳定。咱实测时遇到过一次健康数据读取失败，折腾半天没头绪，还好AtomGit的小助手及时提醒，是没在module.json5里给应用开数据存储权限，加上声明后立马搞定——这坑也是老师和小助手高频强调的，建议大伙提前踩，省得后期排查费时间。

第四步：功能优化加分。迁移完成只是基础，想在大赛里脱颖而出，得把ArkData的新特性用透，这也是AtomGit老师重点点拨的方向。比如给健康数据库加加密，强化用户隐私保护；用数据订阅功能实现步数实时更新、睡眠趋势动态刷新，让操作更丝滑。咱就是按照老师的建议，给应用加了健康数据实时同步和加密功能，在Dayu200上跑起来，体验直接碾压API9版本，评委看了都得眼前一亮。