分数这个概念成年人觉得简单到不值一提但对第一次接触它的小学生来说却是一道实实在在的坎儿。分子在上、分母在下为什么分母越大数反而越小为什么二分之一和四分之二是一回事——这些问题靠口头讲孩子真的很难转过来。我做了这个分数的意义演示器目的很直接通过HarmonyOS应用把整体1用圆形和矩形两种模型可视化切分让分子分母的含义变成一眼就能看懂的画面。这个项目适合正在学ArkTS和ArkUI的开发者练手也适合想做教育类应用的团队参考交互设计。整篇文章会从需求拆解讲到Canvas绘制、状态管理、动画过渡再到调试中踩过的坑把我实际做这个应用的过程完整捋一遍。1. 项目概述与核心需求拆解1.1 分数演示器到底解决什么问题分数的核心意义是把一个整体平均分成若干份表示其中的一份或几份。这句话很短但拆开全是抽象概念整体是什么、平均分长什么样、其中的几份又是什么意思。孩子没见过这些光靠背定义记住分母表示分的份数分子表示取的份数做题照样错。所以这个演示器的第一个需求就是把抽象定义变成可交互的画面。我选择了两种图形模型圆形和矩形。圆形是最贴近一个整体的直觉模型切披萨、切蛋糕都是这个场景矩形则方便后续延伸到长度、面积、体积等更广义的整体理解。孩子可以拖动滑块调整分母看图形实时被等分成不同份数再调节分子看哪些份被高亮选中。来回拖几下分数的部分与整体关系自然就建立了。第二个需求是让意义被文字同步说出来。图形是直觉层语言是抽象层。当孩子把圆切成8份、选中3份时界面下方同时显示把1个整体平均分成8份表示其中的3份图形和语义对应起来这才算真正理解了分数。第三个需求是为后续学习打基础。分数比较、等值分数、同分母加减这些知识点都建立在部分与整体的可视化之上。所以我在应用里加了等值分数自动生成和双画布对比功能虽然只是两个按钮但演示效果一下子从认识分数扩展到了玩转分数。1.2 核心技术选型与方案取舍这个项目的技术栈很明确HarmonyOS Next SDKAPI 12对应版本号5.0.0(12)开发语言ArkTSUI框架ArkUI。选择ArkTS而不是Java或C原因很实际HarmonyOS Next的主推语言就是ArkTS它有完整的声明式UI能力和状态管理机制做这类交互密集的应用开发效率最高编译产物体积和运行性能也符合移动端的要求。在图形绘制方案上我纠结过两条路一是用ArkUI的Shape组件通过Circle、Path等组件描画二是用Canvas组件通过CanvasRenderingContext2D 2D上下文绘制。最终选了Canvas。原因有两个第一分数演示需要动态等分扇形、矩形区域这些图形需要大量循环生成Canvas的一套2D绘制APIarc、fillRect、beginPath可以直接在循环里调用代码简洁Shape组件虽然也能画但动态调整多个子组件的属性要维护大量状态效率低。第二Canvas天然适合做动画后续要做切分动画、对比动画直接用requestAnimationFrame或者插值计算就能实现不需要额外引入动画库。状态管理选用了State和Link的组合方案。父页面维护 numerator分子和 denominator分母两个核心状态通过Link传给子组件。这样Slider调节、等值分数切换、Canvas重绘全部围绕统一数据源展开避免多处备份导致的不同步问题——这个选择在后期调试中帮我省了不少事。1.3 功能清单与交互流程设计最终实现的功能列表是这样的分子分母调节两个Slider分别控制分子1~12和分母2~12也可以直接用Stepper按钮细调圆形分数模型Canvas绘制圆根据分母等分扇形分子前的扇形高亮填充矩形分数模型Canvas绘制矩形按分母等分为竖条前分子个竖条高亮填充语义讲解区实时更新把1个整体平均分成X份表示其中的Y份文字描述等值分数推荐自动计算当前分数的等值分数如1/2对应2/4、3/6一键切换双画布对比模式左右两个Canvas并排分别显示两个分数直观比较大小交互流程是进入页面默认显示1/2圆形模型用户拖Slider改变分子分母两个Canvas同步重绘讲解文字同步更新。点击等值分数按钮画面切换成对应的分数组合。点击对比模式按钮页面进入双画布布局可以选择两组分数进行大小比较。整个过程不需要页面跳转所有交互在一个页面上完成这对儿童用户来说是最友好的方式——一键操作、即时反馈注意力不会被界面跳转打断。2. 环境准备与工程搭建2.1 DevEco Studio与SDK版本配置这个项目是基于HarmonyOS Next API 12开发的对应版本号是5.0.0(12)。开发工具用DevEco Studio 5.0.0版本及以上因为API 12的SDK需要新版工具链支持。安装完DevEco Studio之后需要在SDK Manager里确认已经下载了API 12的SDK——如果你之前只装了API 9或者API 10编译时会直接报SDK version not found。工程创建很简单选择Empty Ability模板包名我建议用com.yourname.fractiondemo这样的格式项目语言选ArkTS兼容版本选5.0.0(12)。这里需要注意一个细节HarmonyOS Next的工程默认compileSdkVersion和targetSdkVersion都指向当前安装的SDK版本如果你的电脑上装了多个API版本编译前在build-profile.json5里检查一下这两个字段确保指向API 12。真机调试时需要在AppGallery Connect里申请调试证书配置好设备的UDID。模拟器调试则简单很多DevEco Studio自带的HarmonyOS模拟器可以直接跑Canvas渲染在模拟器上的表现和真机基本一致。我整个开发过程中绝大部分调试都用模拟器完成只有最后验证性能时才上了真机。2.2 创建工程与基础目录结构工程的目录结构我做了分层避免所有逻辑堆在Index.ets里变成巨型文件entry/src/main/ets/ ├── entryability/ │ └── EntryAbility.ets // 应用入口 ├── pages/ │ └── Index.ets // 主页面分数演示器 ├── components/ │ ├── CircleFraction.ets // 圆形分数模型组件 │ ├── RectFraction.ets // 矩形分数模型组件 │ ├── FractionText.ets // 语义讲解文本组件 │ ├── SliderPanel.ets // 分子分母调节面板 │ └── EquivalentChips.ets // 等值分数按钮组 └── common/ ├── FractionData.ets // 分数数据结构定义 └── PaintUtil.ets // Canvas绘制工具函数这个结构的好处是每个组件各司其职。CircleFraction和RectFraction只负责接收分子分母然后绘制图形SliderPanel只负责输出数值变化事件主页面Index负责状态管理和组件间的数据流转。后面如果要加分数运算功能直接再加一个组件不需要动已有代码。module.json5文件里我设置了页面为竖屏锁定因为儿童使用平板场景下旋转屏幕容易误触。另外把entry的deviceTypes配置了phone和tablet两种这样在平板上也能跑大屏显示分数图形效果更好。3. 核心实现数据模型与状态管理3.1 分数数据结构设计分数的数据模型很简单就两个整数分子 numerator 和分母 denominator。但在ArkTS里我建议用一个类而不是两个散装的State变量来管理尤其是后续要扩展等值分数、对比模式时封装的好处会越来越明显。// common/FractionData.ets export class FractionData { numerator: number 1; denominator: number 2; constructor(numerator: number 1, denominator: number 2) { this.numerator numerator; this.denominator denominator; } // 生成等值分数列表 getEquivalentFractions(): FractionData[] { let list: FractionData[] []; for (let k 2; k 6; k) { let num this.numerator * k; let den this.denominator * k; if (den 24) { list.push(new FractionData(num, den)); } } return list; } // 以a/b字符串形式返回 toString(): string { return ${this.numerator}/${this.denominator}; } }这里有一个设计上的约束我限制了分母最大到12等值分数的分母最大到24。原因很务实Canvas等分扇区时分母超过12之后每个扇区的角度只有30度再小的话视觉上很难区分而且扇形上的文字标签也放不下。另一方面分母太大意味着等分数量多绘制循环变长低端设备上的重绘会开始掉帧。在演示器这个场景里分母控制在12以内完全不牺牲教学效果反而让画面更清晰。数据模型里加一个toString和getEquivalentFractions方法是为了让讲解文字、等值分数按钮都能直接复用这段逻辑不要在UI层到处内联计算。3.2 状态管理方案State、Link与组件通信HarmonyOS Next的ArkUI状态管理最核心的就是State。它标记的变量发生变化时依赖它的UI会重新渲染。我选择在Index页面持有唯一的FractionData实例子组件不自己维护数据而是通过Link获得双向绑定。// pages/Index.ets 部分代码 State fractionData: FractionData new FractionData(1, 2); State isCompareMode: boolean false; State compareFraction: FractionData new FractionData(2, 3); build() { Column() { // 圆形模型 CircleFraction({ fraction: this.fractionData }) // 矩形模型 RectFraction({ fraction: this.fractionData }) // 语义讲解 FractionText({ fraction: this.fractionData }) // 调节面板 SliderPanel({ fraction: this.fractionData, onFractionChange: (num: number, den: number) { this.fractionData.numerator num; this.fractionData.denominator den; } }) } }子组件使用Link接收// components/CircleFraction.ets Component export struct CircleFraction { Link fraction: FractionData; build() { Canvas(this.context) .width(100%) .height(200) .onReady(() { this.draw(); }) } }这里要强调一个在API 12上必须注意的点Link要求父组件传进来的是一个状态变量所以父组件里必须以State fractionData形式声明不能写成普通变量再传否则编译时会报Link can only be used to bind state variables的编译错误。主页面充当了中介者角色SliderPanel不直接修改fractionData而是通过回调函数把新值抛给父页面父页面更新状态再由Link驱动两个Canvas子组件自动重绘。这个流程看似多了一层回调但好处是所有状态变更都收敛在Index这一个地方排查问题时只需要关注Index里的逻辑不用在多个组件之间追踪数据流。为了让Canvas在数据变化时自动重绘我用了一个小技巧在State变量上添加Watch装饰器。只要fraction.numerator或fraction.denominator变化就触发重绘方法Link Watch(onFractionChanged) fraction: FractionData; onFractionChanged() { this.draw(); }注意Watch监听的是整个对象。由于FractionData是一个引用类型直接修改它内部的属性this.fraction.numerator newValue不会触发UI更新。所以父页面里要整体赋值一个新的FractionData实例或者把numerator和denominator拆成两个State属性。我最终采用了拆分方案Index页面声明State numerator: number和State denominator: number再用getter方法组装FractionData传给子组件。这样既保留了类的封装能力又避免了对象内部属性变更不触发视图更新的坑。4. 可视化核心Canvas绘制分数模型4.1 圆形模型扇形等分与动态高亮圆形模型是分数可视化里最直观的呈现方式。核心逻辑是根据分母的数值把360度均匀切分每个扇区对应一份然后从0度开始前分子个扇区填充高亮色其余用浅色打底。在API 12的Canvas组件中绘制扇形需要先创建CanvasRenderingContext2D实例。这段代码和Web Canvas很像但有几处细节不同我在移植时踩过坑值得展开说说。// components/CircleFraction.ets private settings: RenderingContextSettings new RenderingContextSettings(true); private context: CanvasRenderingContext2D new CanvasRenderingContext2D(this.settings); private draw() { const ctx this.context; const width this.context.width; const height this.context.height; const cx width / 2; const cy height / 2; const radius Math.min(width, height) / 2 - 10; const den this.fraction.denominator; const num this.fraction.numerator; const angleStep Math.PI * 2 / den; ctx.clearRect(0, 0, width, height); // 先绘制所有扇区 for (let i 0; i den; i) { const startAngle -Math.PI / 2 i * angleStep; const endAngle -Math.PI / 2 (i 1) * angleStep; ctx.beginPath(); ctx.moveTo(cx, cy); ctx.arc(cx, cy, radius, startAngle, endAngle); ctx.closePath(); ctx.fillStyle i num ? #0A59F7 : #F1F3F5; ctx.fill(); // 扇区边框 ctx.beginPath(); ctx.moveTo(cx, cy); ctx.lineTo(cx radius * Math.cos(startAngle), cy radius * Math.sin(startAngle)); ctx.strokeStyle #FFFFFF; ctx.lineWidth 2; ctx.stroke(); } // 绘制外圈 ctx.beginPath(); ctx.arc(cx, cy, radius, 0, Math.PI * 2); ctx.strokeStyle #333333; ctx.lineWidth 3; ctx.stroke(); }在ArkTS里画扇形有几个注意点。第一RenderingContextSettings构造函数传入一个boolean表示是否开启抗锯齿。我建议开启否则弧形边缘在Retina屏上会有明显的锯齿感。第二startAngle我做了偏移-Math.PI / 2也就是从12点钟方向开始绘制。如果不偏移第一个扇区会从3点钟方向开始整个图形看起来像被切了一刀观感不好。第三绘制完每个扇区后在内部再画一条从圆心到弧边界的线这是为了在扇区之间形成清晰的白色分隔线否则相邻扇区颜色边界太生硬孩子看不出平均分的效果。高亮色的选择上我用了蓝色#0A59F7填充选中区、浅灰#F1F3F5打底未选中区、白色分隔线。这个配色经过了实际测试在屏幕上色差足够明显但又不刺眼适合儿童长时间观看。有人会想用红色、绿色这种更艳的颜色实测下来大面积高饱和色会让视觉疲劳来得很快反而不利于专注。4.2 矩形模型行列分割与交互标注矩形模型我按竖条等分的方式实现——把矩形从左到右均分成den份前num份填充高亮色。比起横条竖条更符合从左往右读写的阅读习惯孩子看高亮区域时目光移动更自然。// components/RectFraction.ets private draw() { const ctx this.context; const width this.context.width; const height this.context.height; const padding 8; const left padding; const top padding; const rectWidth width - 2 * padding; const rectHeight height - 2 * padding; const den this.fraction.denominator; const num this.fraction.numerator; const cellWidth rectWidth / den; ctx.clearRect(0, 0, width, height); // 背景 ctx.fillStyle #F1F3F5; ctx.fillRect(left, top, rectWidth, rectHeight); // 绘制每个单元 for (let i 0; i den; i) { const x left i * cellWidth; if (i num) { ctx.fillStyle #ED6A0C; ctx.fillRect(x, top, cellWidth, rectHeight); } // 每个单元顶部标注编号 if (cellWidth 18) { ctx.font 12px sans-serif; ctx.fillStyle i num ? #FFFFFF : #86909C; ctx.textAlign center; ctx.textBaseline middle; const labelX x cellWidth / 2; const labelY top rectHeight / 2; ctx.fillText(${i 1}, labelX, labelY); } } // 分割线 for (let i 1; i den; i) { const x left i * cellWidth; ctx.beginPath(); ctx.moveTo(x, top); ctx.lineTo(x, top rectHeight); ctx.strokeStyle #FFFFFF; ctx.lineWidth 2; ctx.stroke(); } // 外框 ctx.beginPath(); ctx.rect(left, top, rectWidth, rectHeight); ctx.strokeStyle #333333; ctx.lineWidth 3; ctx.stroke(); }矩形模型的等分逻辑和圆形模型本质相同都是均分前num份高亮。但矩形模型上我额外加了编号标注每个单元内部显示1、2、3这样的序号。这个设计是我在真实测试后加进去的。孩子第一次看高亮的3块时确实能数出来这是前3块但要理解3/8是第1、2、3块还是有困难加上序号后位置的对应关系直接可视化了。关于序号字体大小的判断条件cellWidth 18是因为当分母增大到12时每个单元宽度可能不足18像素这时候数字会挤成一团反而不美观。所以我设了一个阈值单元格不够宽就自动隐藏编号只保留色块分割。4.3 动画过渡与重绘时机控制Canvas的重绘和状态更新必须精确配合。如果状态改了但画布没重绘画面和文字不一致孩子会困惑。反过来如果不需要重绘时频繁调用draw则浪费性能。我的方案是所有变更统一走onFractionChanged回调再触发draw。具体流程是Slider变化 - 父页面更新numerator/denominator状态 - Watch触发onFractionChanged - 子组件调用draw这里要注意Slider是连续滑动组件onChange回调触发频率很高。如果每次滑动都同步重绘Canvas会有一个问题当分母是12时一次滑动要重绘12个扇区加12条线对低端设备来说是明显的压力。我试验过后发现在模拟器上还好但上了真机尤其是低端麒麟芯片的设备拖动分子滑块时画面会有明显迟滞。解决办法有两个层次。第一层是减小Canvas绘制区域让圆形模型和矩形模型分别占屏幕的一部分而不是全屏这样每次重绘的像素量小了很多。第二层是给Slider的onChange做一个轻量节流——不是每个回调都立刻重绘而是收集最后一个值在下一帧统一触发一次重绘。我这里用requestAnimationFrame做了一步简单的合并private pendingDraw: boolean false; private scheduleDraw() { if (this.pendingDraw) { return; } this.pendingDraw true; const animator: Animator new Animator({ duration: 16, iterations: 1, delay: 0, direction: normal, fill: none, easing: ease-out }); animator.onfinish () { this.draw(); this.pendingDraw false; }; animator.play(); }用Animator做一个16ms的定时器把高频回调合并成每秒最多60次重绘。这个思路本质是帧同步实际效果是在频繁操作滑块时画面始终跟手不抖动也不掉帧。动画过渡方面我给分子变化比较明显的情况加了一点视觉上的增量感当分子增加时新高亮的那个扇区用更深一点的蓝色填充当分子减少时取消高亮的那个扇区用浅灰填充。这个渐进色处理让孩子的注意力能自然聚焦到多出来或减少的那一份上对理解分数加减也有促进作用。5. 交互面板与辅助功能实现5.1 滑块调节与数值回显调节面板是整个应用的交互入口必须做到最小步骤完成一次调节。我用两个Slider分别控制分母和分子并用两个文本框实时显示当前数值这样操作的反馈链路最短。// components/SliderPanel.ets Component export struct SliderPanel { Prop numerator: number; Prop denominator: number; onFractionChange: (num: number, den: number) void () {}; build() { Column({ space: 12 }) { Row() { Text(分母) .fontSize(16) .width(50) Slider({ value: this.denominator, min: 2, max: 12, step: 1, style: SliderStyle.OutSet }) .layoutWeight(1) .onChange((value: number) { let den Math.round(value); if (this.numerator den) { this.onFractionChange(den, den); } else { this.onFractionChange(this.numerator, den); } }) Text(${this.denominator}) .fontSize(18) .fontWeight(FontWeight.Bold) .width(40) } Row() { Text(分子) .fontSize(16) .width(50) Slider({ value: this.numerator, min: 1, max: this.denominator, step: 1, style: SliderStyle.OutSet }) .layoutWeight(1) .onChange((value: number) { let num Math.round(value); this.onFractionChange(num, this.denominator); }) Text(${this.numerator}) .fontSize(18) .fontWeight(FontWeight.Bold) .width(40) } } .padding(16) } }两个Slider的联动规则是分子Slider的max值动态绑定为当前分母。分母从4调到3时如果分子当时是4已经大于新分母了我会在分母变化回调里把分子也同步改成新分母——这就是上面代码里this.onFractionChange(den, den)的逻辑。这个规则是为了保证界面始终处于有意义的状态分子也不可能大于分母避免出现取了5份但整体只有4份的荒谬画面。这里还想提一个体验细节Slider的step属性一定要设为1让滑块按整数格跳动而不是连续值。因为分数只有整数份的概念如果step不设为1Slider会产生小数拖动时产生大量无意义的中间状态视觉上会看到分子值在小数之间乱跳很影响孩子对分数的理解。5.2 文本讲解区让图示与语义联动图形下方的文字区是连接具象画面与抽象定义的关键。我的实现方式是Canvas重绘的同时根据当前分子分母动态渲染一段完整的话。// components/FractionText.ets Component export struct FractionText { Prop numerator: number; Prop denominator: number; private getDescription(): string { return 把1个整体平均分成${this.denominator}份表示其中的${this.numerator}份。; } build() { Column() { Text(${this.numerator} / ${this.denominator}) .fontSize(42) .fontWeight(FontWeight.Bold) .fontColor(#1D2129) Text(this.getDescription()) .fontSize(20) .fontColor(#4E5969) .margin({ top: 8 }) } .padding(16) .backgroundColor(#F7F8FA) .borderRadius(12) } }细心的读者会发现我在这里用了Prop而不是Link。因为讲解区只需要读取数值不需要修改数值用Prop单向绑定就足够了没必要引入双向绑定的复杂度。这也是一个状态管理设计上的小原则能读就单向需写再双向。讲解文字的文案必须严谨。一开始我写的是把整体分成8份取其中的3份后来觉得取字不够精确——分数不一定是取出的概念可能是已经存在的3份。所以最后改成了表示其中的3份。表示这个词更中性也更贴切分数的定义。这种细节在儿童教育应用里值得较真孩子对词汇的语义吸收比成年人敏感得多。6. 进阶功能等值分数与对比展示6.1 等值分数的自动生成与一键切换等值分数是分数学习里公认的难点。二分之一等于四分之二等于六分之三这个分子分母同时翻倍的规律光靠文字推导孩子很难信服。但如果是同一个圆形从切成2份选中1份变成切成4份选中2份看起来确实一样多这个规律就变成了可观察的事实。我在应用里加了等值分数推荐区实现逻辑是基于当前分数自动计算倍数后的等价分数private getEquivalentFractions(): FractionData[] { let list: FractionData[] []; for (let k 2; k 6; k) { let num this.numerator * k; let den this.denominator * k; if (den 24) { list.push(new FractionData(num, den)); } } return list; }界面上一行排列这些等值分数的按钮比如当前是2/3就显示4/6、6/9、8/12三个按钮。点击按钮后整个画面切换到对应的分数组合。孩子可以来回切换观察图被分得越来越细但高亮部分的总面积始终相同这一现象。这个功能的代码量很小但教育价值很大。它让孩子在操作中自己发现规律而不是被动接受结论。从应用的完成度来看等值分数这个模块让演示器从单一知识点扩展成了一个有纵深的学习工具。6.2 双画布对比分数大小关系可视化对比模式是我在设计后期加上的功能。场景是孩子已经理解单个分数的含义后自然会产生那3/4和5/8谁更大的问题。传统教法是把两个分数通分到同分母再比较但这个逻辑很抽象。更直接的做法是两个分数用同一个尺寸的圆形展示面积大的自然就是数大的。双画布布局用的是Row组件并排两个Canvas同时传入不同的FractionData实例Row() { CircleFraction({ fraction: this.fractionData }) .layoutWeight(1) CircleFraction({ fraction: this.compareFraction }) .layoutWeight(1) }对比模式下我在两个圆的下方分别显示对应的分数标签并且在两个圆之间动态绘制一个大于号/小于号提示规则是比较数值大小后显示、或符号。这里有一个实现细节当两个分数分母不同时平均分成的份数不同每个扇区的弧长也不同但我不需要为它们统一换算成相同份数。因为两个图形都是用同一种整体模型表示只要高亮面积能直观看出差异孩子就能感受到大小关系。如果两个分数恰好相等比如2/4和4/8两个圆的高亮面积完全一致这个视觉事实比任何文字解释都有说服力。从技术上来说双画布模式只需复用CircleFraction组件传入不同的Link状态对象即可。但注意Link要求传状态变量所以父页面要额外声明两个状态State compareNumerator和State compareDenominator再组装成compareFraction传给子组件。这一步如果直接用一个普通变量传参会触发编译报错。7. 常见问题与调试经验实录7.1 Canvas闪烁与context生命周期在开发过程中我遇到的第一个明显问题是画面闪烁。现象是每次滑动SliderCanvas会短暂变成全白再重新绘制内容。排查后确认问题出在context的创建时机上——我最初把CanvasRenderingContext2D写成子组件内部每次build都重新new导致Canvas的底层渲染上下文被反复创建销毁绘制结果不稳定。正确的做法是context作为组件实例的属性只创建一次onReady回调里把它绑定到Canvas上。private settings: RenderingContextSettings new RenderingContextSettings(true); private context: CanvasRenderingContext2D new CanvasRenderingContext2D(this.settings); build() { Canvas(this.context) .onReady(() { this.draw(); }) }这里我额外说明一下onReady只会在Canvas首次挂载时触发一次之后组件更新不会再次调用。所以我的onFractionChanged里必须手动调用draw不能指望onReady每次数据变化都自动执行——它不会。这个机制一开始很容易忽略等发现画面只在应用启动时画了一次就再也不更新时就要检查是不是漏了在数据变化回调里重绘。7.2 Slider高频回调导致的卡顿优化真机测试时我遇到的第二个问题是性能在低端设备上拖动分母Slider时画面会出现卡顿。分析下来有两个原因一是Canvas重绘耗时过长二是一次拖动触发了多次重复重绘。关于第一个原因最大开销在于每次重绘都要执行clearRect、循环绘制12个扇区、画12条线、画外圈这些操作在API 12 Canvas上是逐指令执行的像素填充量不小。优化思路是缩小绘制区域并把Canvas的尺寸设置为屏幕宽度的90%而不是全屏这样单位像素填充成本降了约20%。另外扇区边框的strokeStyle每次循环都设置可以提到循环外减少状态切换的开销。关于第二个原因就是我前面提到的帧同步优化。本质上是把高频的onChange回调合并为一帧一次draw这个优化做完后即使在四年前的中端机上拖Slider画面也能稳定在50fps以上基本不卡了。我实测在模拟器上跑帧率稳定在60fps真机上略低但体感流畅。7.3 不同设备上的适配问题平板和手机上Canvas的宽高完全不一样。我最初在代码里写死了Canvas高度200vp结果在平板上显得很小在手机上又偏大。后来改成了相对尺寸方案圆形模型的高度占屏幕可用高度的30%矩形模型高度占20%。CircleFraction() .width(80%) .height(this.screenHeight * 0.3)这里涉及一个HarmonyOS布局的单位差异vp是虚拟像素会随屏幕密度自动缩放px是物理像素在不同设备上表现不同。Canvas内部的绘制基于像素坐标系实际获取的宽高是vp对应的物理像素值。所以代码里我统一用Canvas的context.width和context.height作为绘制的参考坐标系不直接硬编码数值这样画布的宽高自动适应设备分辨率。7.4 问题排查速查表问题表现可能原因解决方案Canvas不显示任何内容CanvasRenderingContext2D未绑定或onReady里未调用draw检查context是否在组件属性中单例创建onReady里调用首次draw滑动Slider后画面不更新状态变化没有触发重绘在State/Link属性添加Watch装饰器或显式调用draw画面闪烁白屏context被反复创建销毁context作为实例属性只创建一次onReady只做绑定低端设备卡顿重绘频率过高或绘制区域太大用帧同步合并重绘缩小Canvas绘制区域分子Slider的max未随分母变化缺少联动逻辑在分母onChange里同步约束分子范围ArkTS编译报Link错误传入的变量不是状态变量确保父组件里用State声明变量再传给Link子组件字体在设备上模糊Canvas字体指定了px单位使用vp单位并适配取整或改用百分比等值分数按钮不出现denominator超过24被循环过滤检查getEquivalentFractions里分母上限条件对比模式下两个圆大小不一致两个Canvas控件宽度不一致用layoutWeight(1)分配权重保持等宽7.5 几个值得单独强调的调试经验实际开发中还有三个细节虽然没严重到报错的程度但处理不好会明显影响体验。第一个是Canvas的文字渲染。在绘制矩形模型里的编号时如果直接用ctx.fillText配合font 12px sans-serif在部分真机上会出现文字边缘发虚。我后来改用vp转换函数font ${12 * this.context.density}px sans-serif让字体大小跟随屏幕密度缩放文字清晰度有明显提升。第二个是动画曲线的选择。给分子分母切换做animateTo的时候默认curve是Linear视觉上有些生硬。我试过Curve.EaseOut和Curve.EaseInOut最终选了EaseOut。原因是EaseOut在动画结束阶段减速配合Canvas从旧画面淡出到新画面的过程更柔和孩子视觉上更容易接受变化。第三个是等值分数按钮的状态同步。当通过等值分数组件切换分数后主界面的分子Slider和分母Slider的位置必须同步更新——因为它们和状态是绑定的所以这个同步是自动完成的。但要注意回调的顺序等值分数切换是直接修改父页面状态而Slider的onChange是用户手动操作才会触发。两者路径不同不会循环调用这点设计时要想清楚避免状态越改越乱。8. 实测效果与扩展方向整个应用开发完之后我做了两轮实测。第一轮是功能验证覆盖了分子分母从1到12的全部组合检查了等值分数生成、对比模式切换、双画布一致性所有功能在API 12模拟器上表现正常。第二轮是性能验证在真机上连续拖动Slider 100次记录了绘制耗时。分母为12时的单次重绘耗时在13~18毫秒之间帧率稳定在55fps以上分母为2时的重绘只有几毫秒流畅度没有任何问题。在整个过程中我最大的体会是HarmonyOS Next的ArkUICanvas这套组合做教育类工具应用的效率确实高。ArkTS的声明式语法和Web前端很像但有更严格的类型检查写代码时能提前暴露问题。Canvas的2D API虽然和Web Canvas有差异但核心的arc、fillRect、stroke这些概念完全互通有Web开发经验的人很快能上手。后续扩展我计划做两个方向一个是在现有圆形和矩形模型之外增加数轴模型让孩子看到分数在数轴上的位置——这是分数比较和加减法的重要基础另一个是把演示器扩展成分数实验室加入分数加法、约分、通分等操作的拖拽演示形成完整的分数学习工具链。如果要把这个应用发布到应用市场还需要补充教育类应用的申请材料和应用内购买支持这块是产品化的事了。最后分享一个做这类教育应用的小心得图形绘制一定要孩子看得懂优先于开发者写着方便。我最初写圆形模型时把扇区的边框和填充合并成一次绘制代码确实更简洁但视觉上扇区之间的边界模糊孩子很难数清份数。后来拆成先画填充、再画分隔线、最后画外框三步画面清晰度提升立竿见影。做教育软件永远要站在使用者的视角去审视每一个视觉细节这个原则比任何技术优化都重要。