【开源鸿蒙开发板应用升级适配大赛】API20 数据篇:从ohos.data到ArkData的“搬家”实录
本文对比了OpenHarmony API9与API20的数据管理模块差异,重点分析了从ohos.data到kit.ArkData的升级体验。作者以健康应用开发为例,指出API9存在数据丢失、接口混乱等问题,而API20的ArkData则提供了统一接口、分布式同步和加密功能等优势。文章详细介绍了在RK3568开发板上的迁移步骤,包括版本升级、接口替换和功能优化,并分享了AtomGit老师的调试建议。

前言
家人们谁懂啊!在开源鸿蒙适配大赛里跟数据模块死磕的日子,简直像给旧房子翻新——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版本,评委看了都得眼前一亮。
四、总结:ArkData才是API20的“数据真香定律”
折腾完这场迁移,最大的感受就是:ArkData不是对ohos.data的小修小补,而是开源鸿蒙数据管理的一次“降维打击”。对参赛选手来说,掌握它不仅能搞定本次大赛的适配任务,更能吃透OpenHarmony 6.0的核心数据能力,为后续开发全场景应用打牢基础。
毕竟在开源鸿蒙生态里,数据是应用的灵魂,而ArkData就是守护健康应用数据灵魂的最佳载体。手里握着Dayu200这样的好板子,又有AtomGit老师和小助手的专业指导,把ArkData的能力吃透,咱参赛选手只管放手冲——奖金和证书,不就是给把技术玩明白、懂得借力学习的人的奖励嘛!

下一篇咱再唠唠API20其他模块的升级技巧,例如系统通知的调整!关注我,大赛适配不踩坑,一起在开源鸿蒙的赛道上拿奖到手软~
更多推荐



所有评论(0)