引子一个小应用引发的思考需求不复杂——掷骰子、抛硬币、生成指定范围的随机数再加上历史记录。我顺手用 HarmonyOS 的 ArkTS 写了一个结果发现这个看似简单的应用恰好把 ArkUI 几个核心机制都串起来了状态管理、自定义构建器、组件通信、数据持久化。完整效果技术栈与环境开发框架HarmonyOS ArkTS (ArkUI)开发工具DevEco Studio 5.0目标平台HarmonyOS NEXT语言TypeScript 的超集 ArkTS应用整体架构打开代码第一眼看到的是四个 Tab骰子、硬币、随机数、历史。这四个功能模块通过底部导航栏切换每个模块独立构建。这种结构在移动端很常见但 ArkTS 的实现方式和 React Native 或 Flutter 有明显区别。// 底部 Tab 定义privatetabs:TabItem[][{key:dice,icon:,label:骰子},{key:coin,icon:,label:硬币},{key:rand,icon:,label:随机数},{key:history,icon:,label:历史}];这里用了一个简单的对象数组来管理 Tab 状态配合ForEach渲染。看起来没什么特别的但 ArkTS 的ForEach和 React 的map有一个关键区别ArkTS 的ForEach第二个参数是 item generator第三个参数是 key generator可选。如果数据项会变化比如列表增删一定要提供稳定的 key否则渲染会出问题。为什么选择四个独立 Tab 而不是一个长页面朋友最初的建议是做成一个长页面上下滑动。但考虑到实际使用场景——桌游过程中用户可能频繁切换骰子和硬币功能滑动操作效率太低。底部 Tab 导航让用户可以一键切换这是移动端交互的最佳实践。更重要的是从技术角度看四个 Tab 对应四个Builder方法每个方法内部的逻辑完全独立。如果合并成一个长页面状态管理会变得混乱——比如掷完骰子后页面滚动位置会重置用户体验很差。状态管理State 装饰器的使用哲学整个应用的核心状态都集中在Index组件上Statetab:stringdice;Statetheme:ThemeTypeThemeType.DARK;StatediceType:stringd6;StatediceCount:number1;Stateresults:number[][];Statetotal:number0;Staterolling:booleanfalse;StateshowResult:booleanfalse;Statehistory:RollResult[][];StatecoinResult:string;StaterandMin:number1;StaterandMax:number100;StaterandResult:number0;ArkTS 的State装饰器和 React 的useState有本质区别。React 的useState是函数式的每次调用都会返回新的状态值而 ArkTS 的State是声明式的直接绑定到组件的属性上。这意味着状态变更自动触发重新渲染修改State变量后框架会自动重新执行build()方法中受影响的部分状态是响应式的不是整个组件重新渲染而是只更新绑定了该状态的 UI 部分但这里有个容易踩的坑状态提升State Hoisting。我把所有状态都放在Index组件里是因为这些状态需要在多个子 Tab 之间共享。如果把history放在HistoryTab里DiceTab掷完骰子后就无法更新历史记录了。不过当应用变复杂时这种把所有状态堆在顶层的做法会变得难以维护。ArkTS 提供了State、Prop、Link、Provide/Consume等多种状态管理方案选择哪种取决于数据的流向State组件内部状态父组件不可直接修改Prop父组件向子组件单向传递数据Link父子组件双向绑定Provide/Consume跨层级组件通信对于这个小应用State就够了。但如果要做成生产级应用建议拆分组件用Link或Provide/Consume来管理状态流。状态更新的性能陷阱ArkTS 的状态更新是批量处理的。如果在同一个事件循环中多次修改State框架会合并这些更新只触发一次重新渲染。这在大多数情况下是好事但有时会导致中间状态丢失。比如在doRoll方法中我需要先设置rolling true再设置showResult false。如果这两行代码紧挨着框架可能只渲染一次用户就看不到投掷中的状态了。解决方案是用setTimeout把它们分开或者用State的回调机制如果框架支持的话。骰子滚动动画setTimeout 的妙用骰子投掷的动画效果是这个应用最有趣的部分privateasyncdoRoll():Promisevoid{this.rollingtrue;this.showResultfalse;constsidesthis.cd().sides;constcountthis.diceCount;letc0;consttotal12;consttick():void{consttmp:number[][];for(leti0;icount;i){tmp.push(Math.floor(Math.random()*sides)1);}this.resultstmp;lets0;for(leti0;itmp.length;i)stmp[i];this.totals;c;if(ctotal){setTimeout(tick,40c*10);}else{constfrrollDice(sides,count);this.resultsfr;letfs0;for(leti0;ifr.length;i)fsfr[i];this.totalfs;this.showResulttrue;this.rollingfalse;if(this.db){this.db.add(createRollResult(this.diceType,fr));this.historythis.db.getHistory();}}};tick();}这段代码用递归setTimeout模拟了骰子滚动效果。每次tick都生成一组随机数更新 UI然后设置下一次tick的延迟。延迟时间是40 c * 10毫秒意味着随着滚动次数增加速度会逐渐变慢——这和真实骰子的物理特性很像。为什么用 setTimeout 而不是动画框架ArkTS 的动画系统animation属性、animateTo等适合做平滑的过渡动画但骰子滚动这种快速切换内容的效果用setTimeout更直接。每次tick都重新生成随机数并赋值给State框架会自动触发重新渲染用户就看到了骰子面不断变化的效果。性能考量12 次tick每次间隔 40-150ms总耗时大约 1-2 秒。对于这种轻量级动画setTimeout的性能完全够用。如果要做更复杂的动画比如 3D 旋转建议用 ArkTS 的ohos.animatorAPI。最后一步的处理注意else分支里的逻辑动画结束后调用rollDice(sides, count)生成最终结果然后保存到数据库。这里有个细节——rollDice函数是在../model/Dice中定义的它返回的是一个确定的结果而不是随机数。这样做的好处是可以在测试时 mock 这个函数确保结果可预测。递归 setTimeout vs setInterval这里用递归setTimeout而不是setInterval是有原因的。setInterval的执行时间不固定——如果上一次tick的执行时间超过了间隔时间下一次tick会立即执行导致动画卡顿。而setTimeout是在上一次执行完成后才开始计时保证了动画的流畅性。更重要的是递归setTimeout可以动态调整间隔时间40 c * 10而setInterval的间隔是固定的。这种先快后慢的动画效果用setInterval很难实现。随机数生成的公平性代码中用Math.floor(Math.random() * sides) 1来生成随机数。这个公式是标准的均匀分布随机数生成方法对于骰子应用来说是公平的。但需要注意的是Math.random()的随机性取决于浏览器的实现在某些极端情况下可能不够随机。对于游戏应用来说这完全够用但如果涉及密码学或安全场景应该用crypto.getRandomValues()。主题系统深色模式的实现应用支持深色主题通过getThemeColors函数获取当前主题的颜色配置privategc():ThemeColors{returngetThemeColors(this.theme);}然后在 UI 中通过this.gc().primary、this.gc().text等方式引用颜色。这种模式的好处是主题切换方便只需修改this.theme的值整个应用的颜色就会自动更新颜色一致性所有颜色都从同一个配置对象获取避免了硬编码颜色值散落在代码各处可维护性新增主题只需在Theme.ts中添加配置不需要修改 UI 代码但这里有个问题当前实现是通过this.theme状态来控制主题而ThemeType只有DARK一种值。如果要支持浅色模式需要在Theme.ts中添加LIGHT主题的配置添加切换主题的 UI 控件比如设置页面考虑跟随系统主题使用ohos.app.ability.ConfigurationAPI颜色透明度的处理代码中用this.gc().primary 20来添加透明度。这依赖于颜色值是 6 位十六进制字符串。如果主题配置返回的是其他格式比如rgb()或rgba()这种拼接就会失效。建议统一使用十六进制格式或者提供一个专门的函数来处理颜色透明度。// 更安全的颜色透明度处理functionwithAlpha(hexColor:string,alpha:number):string{constalphaHexMath.round(alpha*255).toString(16).padStart(2,0);returnhexColoralphaHex;}// 使用示例.backgroundColor(withAlpha(this.gc().primary,0.12))这样不仅更安全而且代码意图也更清晰——看到withAlpha就知道是在处理透明度而不是字符串拼接。数据持久化DiceDatabase 的设计应用使用DiceDatabase类来保存历史记录privatedb:DiceDatabase|nullnull;privatectx:common.UIAbilityContext|nullnull;privateasyncinit():Promisevoid{this.ctxgetContext(this)ascommon.UIAbilityContext;this.dbnewDiceDatabase(this.ctx);awaitthis.db.init();this.historythis.db.getHistory();}DiceDatabase封装了底层的存储逻辑可能是 Preferences API 或关系型数据库。这里有几个设计要点异步初始化数据库初始化是异步操作需要在aboutToAppear生命周期中调用空值保护db和ctx都可能为 null所以在使用前要检查数据同步每次掷完骰子后调用this.db.add()保存结果然后重新获取历史列表Preferences API vs 关系型数据库对于这种简单的键值对存储HarmonyOS 的 Preferences API 就够了。Preferences 适合存储少量配置数据API 简单性能好。但如果要支持复杂查询比如按日期筛选、统计分析建议用关系型数据库 RDB。特性Preferences关系型数据库 (RDB)数据结构键值对表、行、列查询能力按 key 获取SQL 查询性能读写快复杂查询慢适用场景配置、少量数据大量结构化数据数据上限约 1MB无硬性限制在这个应用中历史记录可能会增长到几百条。如果用 Preferences每次获取历史记录都需要读取整个数据集性能会下降。而 RDB 支持分页查询可以只获取最近的 N 条记录。数据库初始化的时序问题aboutToAppear是组件即将出现时调用的生命周期方法但数据库初始化是异步的。如果用户在初始化完成前就点击了投掷按钮db还是 null会导致崩溃。需要添加 loading 状态或禁用按钮直到初始化完成。StatedbReady:booleanfalse;privateasyncinit():Promisevoid{this.ctxgetContext(this)ascommon.UIAbilityContext;this.dbnewDiceDatabase(this.ctx);awaitthis.db.init();this.historythis.db.getHistory();this.dbReadytrue;// 标记初始化完成}// 在 UI 中禁用按钮Row(){Text( 投掷).fontSize(FontSize.xl).fontColor(#FFFFFF).fontWeight(FontWeight.Bold)}.width(80%).height(56).justifyContent(FlexAlign.Center).backgroundColor(this.rolling||!this.dbReady?this.gc().border:this.gc().primary).borderRadius(BorderRadius.xl).opacity(this.dbReady?1:0.5)// 未就绪时降低透明度.onClick((){if(this.dbReady!this.rolling)this.doRoll();})这样既保证了安全性又给用户明确的视觉反馈。自定义构建器Builder 的组件化实践应用大量使用了Builder装饰器来定义可复用的 UI 片段BuilderDiceTab(){...}BuilderCoinTab(){...}BuilderRandTab(){...}BuilderHistoryTab(){...}Builder是 ArkTS 中实现组件化的重要机制。它和Component的区别在于Component是独立的组件有自己的状态和生命周期Builder是 UI 片段通常用于复用布局逻辑没有独立的状态在这个应用中Builder的使用很合理——每个 Tab 的 UI 逻辑相对独立但又共享Index组件的状态。如果用Component来实现就需要通过Link或Prop把状态传递下去增加了复杂度。什么时候用 Builder什么时候用 Component这是一个常见的决策问题。根据我的经验可以从以下几个维度考虑状态需求如果 UI 片段需要独立的状态用Component如果只是展示数据用Builder复用性如果要在多处复用同一套 UI用Component如果只在一个地方用用Builder通信复杂度如果需要和父组件频繁通信用Builder直接访问父组件状态如果通信少用Component通过 Prop/Link性能Component有独立的渲染上下文性能开销稍大Builder共享父组件的渲染上下文性能更好Builder 的局限性Builder不能有自己的State这意味着它不能响应内部状态变化。如果需要在 Builder 内部维护状态要么把状态提升到父组件要么改用Component。此外Builder的参数传递方式和函数类似不支持双向绑定。如果需要双向绑定必须用Component配合Link。踩坑记录在开发过程中遇到了几个值得注意的问题坑 1ForEach 的性能问题ArkTS 的ForEach在数据量大时可能有性能问题。比如历史记录列表如果用户掷了几百次骰子ForEach每次都会重新渲染整个列表。解决方案是使用List组件的懒加载特性只渲染可见区域的元素。// 优化前ForEach 渲染所有项ForEach(this.history,(r:RollResult){ListItem(){...}})// 优化后List 懒加载List(){ForEach(this.history,(r:RollResult){ListItem(){...}})}.width(100%).layoutWeight(1).scrollBar(BarState.Off)List组件会自动处理懒加载只渲染用户可见的列表项大幅提升了滚动性能。坑 2状态更新的时机在doRoll方法中我用setTimeout来延迟状态更新。但 ArkTS 的状态更新是异步的如果在同一个事件循环中多次修改State框架可能会合并这些更新导致中间状态丢失。测试时要确保每次tick都能正确触发重新渲染。坑 3颜色透明度的字符串拼接代码中用this.gc().primary 20来添加透明度。这依赖于颜色值是 6 位十六进制字符串。如果主题配置返回的是其他格式比如rgb()或rgba()这种拼接就会失效。建议统一使用十六进制格式或者提供一个专门的函数来处理颜色透明度。坑 4数据库初始化的时序aboutToAppear是组件即将出现时调用的生命周期方法但数据库初始化是异步的。如果用户在初始化完成前就点击了投掷按钮db还是 null会导致崩溃。需要添加 loading 状态或禁用按钮直到初始化完成。代码改进建议虽然这个应用功能完整但还有一些可以优化的地方1. 状态管理优化把所有状态都放在Index组件里随着功能增加会变得难以维护。建议把每个 Tab 的状态封装到独立的组件中用Provide/Consume来共享需要跨组件访问的状态比如history2. 错误处理当前代码几乎没有错误处理。比如数据库操作失败时应该给用户友好的提示而不是静默失败。privateasyncclr():Promisevoid{if(this.db){try{awaitthis.db.clear();this.history[];}catch(error){// 这里应该弹出 Toast 提示用户console.error(清空历史失败:,error);}}}3. 无障碍支持应用没有添加无障碍属性ariaLabel等这对视障用户不友好。HarmonyOS 的无障碍框架很完善建议添加。Text( 投掷).fontSize(FontSize.xl).fontColor(#FFFFFF).fontWeight(FontWeight.Bold).ariaLabel(投掷骰子)4. 单元测试rollDice和createRollResult这些纯函数很容易测试但 UI 逻辑的测试需要 DevEco Studio 的测试框架支持。建议为业务逻辑编写单元测试确保核心功能的正确性。替代方案对比在实现类似功能时有几种替代方案值得考虑方案 1使用 ohos.animator 实现动画如果要实现更流畅的 3D 骰子动画可以用ohos.animatorAPI。它提供了更精细的动画控制比如插值器、时间曲线等。但 API 复杂度更高对于简单的滚动效果来说有些杀鸡用牛刀。方案 2使用 Tabs 组件ArkTS 内置了Tabs组件专门用于实现 Tab 导航。它提供了滑动切换、指示器等特性比手写 Tab 导航更方便。但Tabs组件的自定义程度有限如果需要特殊的 Tab 样式还是得自己实现。方案 3使用 State 装饰器的不同变体ArkTS 5.0 引入了Observed/ObjectLink装饰器用于处理嵌套对象的状态管理。如果RollResult对象内部有需要响应式更新的属性可以用这套方案。但对于当前应用State就够了。总结这个随机数应用虽然功能简单但涉及了 ArkTS 开发的多个核心知识点状态管理、自定义构建器、异步操作、数据持久化、主题系统。在实际开发中这些知识点会反复出现只是复杂度不同。对于 ArkTS 新手建议从类似的小项目入手逐步理解框架的设计哲学。ArkTS 的声明式 UI 和 React 有相似之处但状态管理和生命周期有明显区别需要花时间适应。对于有经验的开发者重点是理解 ArkTS 的约束——它不是 TypeScript 的简单扩展而是一个有自己规则的框架。遵循框架的最佳实践才能写出可维护、高性能的代码。适用边界这个应用适合用作 ArkTS 入门学习项目涵盖了 UI 开发、状态管理、数据持久化等核心知识点。但如果要上架应用商店还需要补充错误处理、无障碍支持、性能优化、用户引导等内容。建议在此基础上逐步扩展而不是一次性做完所有功能。
引子一个小应用引发的思考需求不复杂——掷骰子、抛硬币、生成指定范围的随机数再加上历史记录。我顺手用 HarmonyOS 的 ArkTS 写了一个结果发现这个看似简单的应用恰好把 ArkUI 几个核心机制都串起来了状态管理、自定义构建器、组件通信、数据持久化。完整效果技术栈与环境开发框架HarmonyOS ArkTS (ArkUI)开发工具DevEco Studio 5.0目标平台HarmonyOS NEXT语言TypeScript 的超集 ArkTS应用整体架构打开代码第一眼看到的是四个 Tab骰子、硬币、随机数、历史。这四个功能模块通过底部导航栏切换每个模块独立构建。这种结构在移动端很常见但 ArkTS 的实现方式和 React Native 或 Flutter 有明显区别。// 底部 Tab 定义privatetabs:TabItem[][{key:dice,icon:,label:骰子},{key:coin,icon:,label:硬币},{key:rand,icon:,label:随机数},{key:history,icon:,label:历史}];这里用了一个简单的对象数组来管理 Tab 状态配合ForEach渲染。看起来没什么特别的但 ArkTS 的ForEach和 React 的map有一个关键区别ArkTS 的ForEach第二个参数是 item generator第三个参数是 key generator可选。如果数据项会变化比如列表增删一定要提供稳定的 key否则渲染会出问题。为什么选择四个独立 Tab 而不是一个长页面朋友最初的建议是做成一个长页面上下滑动。但考虑到实际使用场景——桌游过程中用户可能频繁切换骰子和硬币功能滑动操作效率太低。底部 Tab 导航让用户可以一键切换这是移动端交互的最佳实践。更重要的是从技术角度看四个 Tab 对应四个Builder方法每个方法内部的逻辑完全独立。如果合并成一个长页面状态管理会变得混乱——比如掷完骰子后页面滚动位置会重置用户体验很差。状态管理State 装饰器的使用哲学整个应用的核心状态都集中在Index组件上Statetab:stringdice;Statetheme:ThemeTypeThemeType.DARK;StatediceType:stringd6;StatediceCount:number1;Stateresults:number[][];Statetotal:number0;Staterolling:booleanfalse;StateshowResult:booleanfalse;Statehistory:RollResult[][];StatecoinResult:string;StaterandMin:number1;StaterandMax:number100;StaterandResult:number0;ArkTS 的State装饰器和 React 的useState有本质区别。React 的useState是函数式的每次调用都会返回新的状态值而 ArkTS 的State是声明式的直接绑定到组件的属性上。这意味着状态变更自动触发重新渲染修改State变量后框架会自动重新执行build()方法中受影响的部分状态是响应式的不是整个组件重新渲染而是只更新绑定了该状态的 UI 部分但这里有个容易踩的坑状态提升State Hoisting。我把所有状态都放在Index组件里是因为这些状态需要在多个子 Tab 之间共享。如果把history放在HistoryTab里DiceTab掷完骰子后就无法更新历史记录了。不过当应用变复杂时这种把所有状态堆在顶层的做法会变得难以维护。ArkTS 提供了State、Prop、Link、Provide/Consume等多种状态管理方案选择哪种取决于数据的流向State组件内部状态父组件不可直接修改Prop父组件向子组件单向传递数据Link父子组件双向绑定Provide/Consume跨层级组件通信对于这个小应用State就够了。但如果要做成生产级应用建议拆分组件用Link或Provide/Consume来管理状态流。状态更新的性能陷阱ArkTS 的状态更新是批量处理的。如果在同一个事件循环中多次修改State框架会合并这些更新只触发一次重新渲染。这在大多数情况下是好事但有时会导致中间状态丢失。比如在doRoll方法中我需要先设置rolling true再设置showResult false。如果这两行代码紧挨着框架可能只渲染一次用户就看不到投掷中的状态了。解决方案是用setTimeout把它们分开或者用State的回调机制如果框架支持的话。骰子滚动动画setTimeout 的妙用骰子投掷的动画效果是这个应用最有趣的部分privateasyncdoRoll():Promisevoid{this.rollingtrue;this.showResultfalse;constsidesthis.cd().sides;constcountthis.diceCount;letc0;consttotal12;consttick():void{consttmp:number[][];for(leti0;icount;i){tmp.push(Math.floor(Math.random()*sides)1);}this.resultstmp;lets0;for(leti0;itmp.length;i)stmp[i];this.totals;c;if(ctotal){setTimeout(tick,40c*10);}else{constfrrollDice(sides,count);this.resultsfr;letfs0;for(leti0;ifr.length;i)fsfr[i];this.totalfs;this.showResulttrue;this.rollingfalse;if(this.db){this.db.add(createRollResult(this.diceType,fr));this.historythis.db.getHistory();}}};tick();}这段代码用递归setTimeout模拟了骰子滚动效果。每次tick都生成一组随机数更新 UI然后设置下一次tick的延迟。延迟时间是40 c * 10毫秒意味着随着滚动次数增加速度会逐渐变慢——这和真实骰子的物理特性很像。为什么用 setTimeout 而不是动画框架ArkTS 的动画系统animation属性、animateTo等适合做平滑的过渡动画但骰子滚动这种快速切换内容的效果用setTimeout更直接。每次tick都重新生成随机数并赋值给State框架会自动触发重新渲染用户就看到了骰子面不断变化的效果。性能考量12 次tick每次间隔 40-150ms总耗时大约 1-2 秒。对于这种轻量级动画setTimeout的性能完全够用。如果要做更复杂的动画比如 3D 旋转建议用 ArkTS 的ohos.animatorAPI。最后一步的处理注意else分支里的逻辑动画结束后调用rollDice(sides, count)生成最终结果然后保存到数据库。这里有个细节——rollDice函数是在../model/Dice中定义的它返回的是一个确定的结果而不是随机数。这样做的好处是可以在测试时 mock 这个函数确保结果可预测。递归 setTimeout vs setInterval这里用递归setTimeout而不是setInterval是有原因的。setInterval的执行时间不固定——如果上一次tick的执行时间超过了间隔时间下一次tick会立即执行导致动画卡顿。而setTimeout是在上一次执行完成后才开始计时保证了动画的流畅性。更重要的是递归setTimeout可以动态调整间隔时间40 c * 10而setInterval的间隔是固定的。这种先快后慢的动画效果用setInterval很难实现。随机数生成的公平性代码中用Math.floor(Math.random() * sides) 1来生成随机数。这个公式是标准的均匀分布随机数生成方法对于骰子应用来说是公平的。但需要注意的是Math.random()的随机性取决于浏览器的实现在某些极端情况下可能不够随机。对于游戏应用来说这完全够用但如果涉及密码学或安全场景应该用crypto.getRandomValues()。主题系统深色模式的实现应用支持深色主题通过getThemeColors函数获取当前主题的颜色配置privategc():ThemeColors{returngetThemeColors(this.theme);}然后在 UI 中通过this.gc().primary、this.gc().text等方式引用颜色。这种模式的好处是主题切换方便只需修改this.theme的值整个应用的颜色就会自动更新颜色一致性所有颜色都从同一个配置对象获取避免了硬编码颜色值散落在代码各处可维护性新增主题只需在Theme.ts中添加配置不需要修改 UI 代码但这里有个问题当前实现是通过this.theme状态来控制主题而ThemeType只有DARK一种值。如果要支持浅色模式需要在Theme.ts中添加LIGHT主题的配置添加切换主题的 UI 控件比如设置页面考虑跟随系统主题使用ohos.app.ability.ConfigurationAPI颜色透明度的处理代码中用this.gc().primary 20来添加透明度。这依赖于颜色值是 6 位十六进制字符串。如果主题配置返回的是其他格式比如rgb()或rgba()这种拼接就会失效。建议统一使用十六进制格式或者提供一个专门的函数来处理颜色透明度。// 更安全的颜色透明度处理functionwithAlpha(hexColor:string,alpha:number):string{constalphaHexMath.round(alpha*255).toString(16).padStart(2,0);returnhexColoralphaHex;}// 使用示例.backgroundColor(withAlpha(this.gc().primary,0.12))这样不仅更安全而且代码意图也更清晰——看到withAlpha就知道是在处理透明度而不是字符串拼接。数据持久化DiceDatabase 的设计应用使用DiceDatabase类来保存历史记录privatedb:DiceDatabase|nullnull;privatectx:common.UIAbilityContext|nullnull;privateasyncinit():Promisevoid{this.ctxgetContext(this)ascommon.UIAbilityContext;this.dbnewDiceDatabase(this.ctx);awaitthis.db.init();this.historythis.db.getHistory();}DiceDatabase封装了底层的存储逻辑可能是 Preferences API 或关系型数据库。这里有几个设计要点异步初始化数据库初始化是异步操作需要在aboutToAppear生命周期中调用空值保护db和ctx都可能为 null所以在使用前要检查数据同步每次掷完骰子后调用this.db.add()保存结果然后重新获取历史列表Preferences API vs 关系型数据库对于这种简单的键值对存储HarmonyOS 的 Preferences API 就够了。Preferences 适合存储少量配置数据API 简单性能好。但如果要支持复杂查询比如按日期筛选、统计分析建议用关系型数据库 RDB。特性Preferences关系型数据库 (RDB)数据结构键值对表、行、列查询能力按 key 获取SQL 查询性能读写快复杂查询慢适用场景配置、少量数据大量结构化数据数据上限约 1MB无硬性限制在这个应用中历史记录可能会增长到几百条。如果用 Preferences每次获取历史记录都需要读取整个数据集性能会下降。而 RDB 支持分页查询可以只获取最近的 N 条记录。数据库初始化的时序问题aboutToAppear是组件即将出现时调用的生命周期方法但数据库初始化是异步的。如果用户在初始化完成前就点击了投掷按钮db还是 null会导致崩溃。需要添加 loading 状态或禁用按钮直到初始化完成。StatedbReady:booleanfalse;privateasyncinit():Promisevoid{this.ctxgetContext(this)ascommon.UIAbilityContext;this.dbnewDiceDatabase(this.ctx);awaitthis.db.init();this.historythis.db.getHistory();this.dbReadytrue;// 标记初始化完成}// 在 UI 中禁用按钮Row(){Text( 投掷).fontSize(FontSize.xl).fontColor(#FFFFFF).fontWeight(FontWeight.Bold)}.width(80%).height(56).justifyContent(FlexAlign.Center).backgroundColor(this.rolling||!this.dbReady?this.gc().border:this.gc().primary).borderRadius(BorderRadius.xl).opacity(this.dbReady?1:0.5)// 未就绪时降低透明度.onClick((){if(this.dbReady!this.rolling)this.doRoll();})这样既保证了安全性又给用户明确的视觉反馈。自定义构建器Builder 的组件化实践应用大量使用了Builder装饰器来定义可复用的 UI 片段BuilderDiceTab(){...}BuilderCoinTab(){...}BuilderRandTab(){...}BuilderHistoryTab(){...}Builder是 ArkTS 中实现组件化的重要机制。它和Component的区别在于Component是独立的组件有自己的状态和生命周期Builder是 UI 片段通常用于复用布局逻辑没有独立的状态在这个应用中Builder的使用很合理——每个 Tab 的 UI 逻辑相对独立但又共享Index组件的状态。如果用Component来实现就需要通过Link或Prop把状态传递下去增加了复杂度。什么时候用 Builder什么时候用 Component这是一个常见的决策问题。根据我的经验可以从以下几个维度考虑状态需求如果 UI 片段需要独立的状态用Component如果只是展示数据用Builder复用性如果要在多处复用同一套 UI用Component如果只在一个地方用用Builder通信复杂度如果需要和父组件频繁通信用Builder直接访问父组件状态如果通信少用Component通过 Prop/Link性能Component有独立的渲染上下文性能开销稍大Builder共享父组件的渲染上下文性能更好Builder 的局限性Builder不能有自己的State这意味着它不能响应内部状态变化。如果需要在 Builder 内部维护状态要么把状态提升到父组件要么改用Component。此外Builder的参数传递方式和函数类似不支持双向绑定。如果需要双向绑定必须用Component配合Link。踩坑记录在开发过程中遇到了几个值得注意的问题坑 1ForEach 的性能问题ArkTS 的ForEach在数据量大时可能有性能问题。比如历史记录列表如果用户掷了几百次骰子ForEach每次都会重新渲染整个列表。解决方案是使用List组件的懒加载特性只渲染可见区域的元素。// 优化前ForEach 渲染所有项ForEach(this.history,(r:RollResult){ListItem(){...}})// 优化后List 懒加载List(){ForEach(this.history,(r:RollResult){ListItem(){...}})}.width(100%).layoutWeight(1).scrollBar(BarState.Off)List组件会自动处理懒加载只渲染用户可见的列表项大幅提升了滚动性能。坑 2状态更新的时机在doRoll方法中我用setTimeout来延迟状态更新。但 ArkTS 的状态更新是异步的如果在同一个事件循环中多次修改State框架可能会合并这些更新导致中间状态丢失。测试时要确保每次tick都能正确触发重新渲染。坑 3颜色透明度的字符串拼接代码中用this.gc().primary 20来添加透明度。这依赖于颜色值是 6 位十六进制字符串。如果主题配置返回的是其他格式比如rgb()或rgba()这种拼接就会失效。建议统一使用十六进制格式或者提供一个专门的函数来处理颜色透明度。坑 4数据库初始化的时序aboutToAppear是组件即将出现时调用的生命周期方法但数据库初始化是异步的。如果用户在初始化完成前就点击了投掷按钮db还是 null会导致崩溃。需要添加 loading 状态或禁用按钮直到初始化完成。代码改进建议虽然这个应用功能完整但还有一些可以优化的地方1. 状态管理优化把所有状态都放在Index组件里随着功能增加会变得难以维护。建议把每个 Tab 的状态封装到独立的组件中用Provide/Consume来共享需要跨组件访问的状态比如history2. 错误处理当前代码几乎没有错误处理。比如数据库操作失败时应该给用户友好的提示而不是静默失败。privateasyncclr():Promisevoid{if(this.db){try{awaitthis.db.clear();this.history[];}catch(error){// 这里应该弹出 Toast 提示用户console.error(清空历史失败:,error);}}}3. 无障碍支持应用没有添加无障碍属性ariaLabel等这对视障用户不友好。HarmonyOS 的无障碍框架很完善建议添加。Text( 投掷).fontSize(FontSize.xl).fontColor(#FFFFFF).fontWeight(FontWeight.Bold).ariaLabel(投掷骰子)4. 单元测试rollDice和createRollResult这些纯函数很容易测试但 UI 逻辑的测试需要 DevEco Studio 的测试框架支持。建议为业务逻辑编写单元测试确保核心功能的正确性。替代方案对比在实现类似功能时有几种替代方案值得考虑方案 1使用 ohos.animator 实现动画如果要实现更流畅的 3D 骰子动画可以用ohos.animatorAPI。它提供了更精细的动画控制比如插值器、时间曲线等。但 API 复杂度更高对于简单的滚动效果来说有些杀鸡用牛刀。方案 2使用 Tabs 组件ArkTS 内置了Tabs组件专门用于实现 Tab 导航。它提供了滑动切换、指示器等特性比手写 Tab 导航更方便。但Tabs组件的自定义程度有限如果需要特殊的 Tab 样式还是得自己实现。方案 3使用 State 装饰器的不同变体ArkTS 5.0 引入了Observed/ObjectLink装饰器用于处理嵌套对象的状态管理。如果RollResult对象内部有需要响应式更新的属性可以用这套方案。但对于当前应用State就够了。总结这个随机数应用虽然功能简单但涉及了 ArkTS 开发的多个核心知识点状态管理、自定义构建器、异步操作、数据持久化、主题系统。在实际开发中这些知识点会反复出现只是复杂度不同。对于 ArkTS 新手建议从类似的小项目入手逐步理解框架的设计哲学。ArkTS 的声明式 UI 和 React 有相似之处但状态管理和生命周期有明显区别需要花时间适应。对于有经验的开发者重点是理解 ArkTS 的约束——它不是 TypeScript 的简单扩展而是一个有自己规则的框架。遵循框架的最佳实践才能写出可维护、高性能的代码。适用边界这个应用适合用作 ArkTS 入门学习项目涵盖了 UI 开发、状态管理、数据持久化等核心知识点。但如果要上架应用商店还需要补充错误处理、无障碍支持、性能优化、用户引导等内容。建议在此基础上逐步扩展而不是一次性做完所有功能。
)
)
