1. 为什么运算定律适合做成拼图游戏规则与关卡设计1.1 把抽象等式转成可触碰的拼图块做HarmonyOS应用实例做到第73期我明显感觉到教育类小工具比纯工具类更考验交互设计。这一期想聊的定律拼图游戏是我给家里正在学运算定律的小朋友做的一个鸿蒙原生小应用。很多孩子看到“加法交换律”“乘法分配律”这些词就头皮发麻本质原因不是数学难而是他们在课本上看到的全是静态公式。你让他在纸上反复读三遍不如让他亲手把数字块拖到正确的位置上拼成等式来得直观。拼图游戏的核心思路就是把一个完整的运算定律等式拆成若干“拼图块”再让玩家把它们放回正确的位置。以加法交换律为例一个等式是3 5 5 3我不会把整个式子一次性显示出来而是拆成四个拼图卡片和一个等式骨架。等式骨架是这样展示的[空槽] [空槽] [空槽] [空槽] [空槽] [空槽]其中第一个空槽需要放入“3”第二个空槽需要放入“”第三个空槽需要放入“5”等号右边同理。卡片区则放着打乱顺序的数字卡片、运算符卡片。孩子需要自己观察左右两侧哪些卡片应该放在哪里这个观察、比较、放下的过程就是对运算定律的学习过程。这里有一个很关键的设计取舍运算符和数字要一起打乱而等式骨架不变。如果只打乱数字孩子很容易通过排除法做出来把运算符也打乱他就必须理解“等号左右两侧的运算符顺序是相反的”这个核心规则题目才真正有意义。我在第二版迭代时加入了运算符打乱实际测试下来孩子犯错率明显提升但也恰恰说明他开始动脑了。1.2 三种核心定律的关卡拆解游戏内容围绕小学数学里最常考的三种运算定律展开加法交换律、乘法结合律、乘法分配律。我把它拆成了七个关卡每关换一种定律组合方式难度逐步递增关卡定律类型题目示例设计目标1加法交换律3 5 5 3认识“交换位置、结果不变”2乘法交换律2 × 4 4 × 2把交换律扩展到乘法3加法结合律(2 3) 4 2 (3 4)理解括号改变顺序不变4乘法结合律3 × (2 × 4) (3 × 2) × 4结合率与括号配对5乘法分配律(正向)3 × (2 4) 3 × 2 3 × 4拆分后逐项相乘再相加6乘法分配律(逆向)2 × 5 2 × 3 2 × (5 3)会把“公共因数”提取出来7混合随机不限定律类型综合运用检验掌握程度关卡的边界划分不是随便定的。交换律和结合律对小学生来说理解难度差异很大如果一上来就混合出题孩子会完全不知道从哪下手。前两关先建立“左右两边长得不一样但数值一样”的心理认知中间两关引入括号让他理解结合顺序不影响结果最后才是分配律这种带有乘法和加法混合的复杂结构。每一道题的道具数量也有讲究。数字范围控制在10以内运算符只使用加号和乘号。一开始我也做过20以内的数但从实测反馈来看数值一变大孩子容易把注意力放在“计算20加18”上反而忽略了“定律关系”。控制在10以内能保证孩子一眼就能判断两侧结果相等把全部精力放在等式结构上。1.3 数据驱动的题目结构所有关卡题目都用一个JSON结构描述UI层完全不硬编码题目。这个设计看起来很基础但对于这个游戏来说意义重大——它让运营、教师、家长都能在不改代码的情况下增删题目也让后续加入Python脚本自动出题成为可能。我初步设计的题目结构是这样的export interface LevelData { levelId: number; lawType: string; // commutative / associative / distributive title: string; // 关卡标题 expressionBefore: string; // 等号左边如 3 5 expressionAfter: string; // 等号右边如 5 3 slots: SlotConfig[]; // 槽位配置 cards: CardConfig[]; // 卡片配置 } export interface SlotConfig { slotId: string; expectCardId: string; // 期望放入的卡片ID placeholder: string; // 未放入时的占位文本 } export interface CardConfig { cardId: string; text: string; kind: number | operator | bracket; widthWeight: number; // 卡片宽度权重用于自适应布局 }题目的组装逻辑是这样的系统先根据表达式拆出所有数字和运算符生成卡片列表再按照等号两侧的顺序生成槽位列表最后把卡片列表打乱显示在候选项区域。比如3 5 5 3这道题最终实际展示的卡片可能是[5] [3] [3] [] [] [5]这样一套混合排列。这样的数据驱动设计让组装关卡非常快。想新增一道题只需要在levels.json里加一个对象不需要重新打包逻辑。整个游戏核心逻辑只关心“拖到哪”“对不对”这两个问题剩下的事情全交给数据。2. HarmonyOS NEXT API 12下的技术选型与架构思路2.1 ArkTS声明式框架带来的优势这个项目跑在HarmonyOS NEXT SDKAPI 12 / 5.0.0(12)上开发语言用ArkTS。选这套技术栈不只是因为项目属于原生鸿蒙应用系列更重要的是拼图游戏这个场景和声明式UI范式天然匹配。拼图游戏的界面看起来是卡片在移动、槽位在变色实际上所有视觉变化都是同一份数据在不同状态下的投影。当玩家拖一张数字卡片放到槽位上时底层发生的事情很简单某个cardId从“候选项数组”移动到“已填充映射表”。UI层只需要根据这份数据重新渲染即可。这就是ArkTS声明式开发的舒适区。用State或ObservedV2装饰器标记游戏状态数据框架自动追踪依赖关系并刷新界面我完全不需要手写刷新命令。对比一下如果用命令式UI拖放事件发生时得手动查找卡片组件、移除旧位置、渲染新位置、再更新分数组件逻辑越写越长状态一多必然乱。声明式开发省掉的正是这部分最容易出Bug的黏合代码。2.2 状态管理选型对比在一个中等复杂度的小工具里状态管理最忌讳一上来就用全局复杂方案。这个游戏项目的状态其实就三类当前关卡数据、玩家已填充的槽位映射、得分和关卡进度。我在开发过程中对比过三种做法方案适用场景本项目使用情况State 子组件参数传递层级简单、状态集中在一个页面第一版采用够用但组件间传参略繁琐Link / Prop 双向同步父子组件需要同步修改数据实际用来做槽位和候选区的局部状态ObservedV2 Trace数据模型独立成类多个页面共享最终版本采用逻辑更清爽第一版我用的是页面级State所有槽位和卡片状态都放在主页面子组件通过参数接收。这种做法只有二三十行数据时完全没问题但搭配拖拽动画之后子组件回调一层层往上抛事件代码很快就变得绕。重构的时候我把游戏状态抽成了一个独立的PuzzleGameModel类用ObservedV2和Trace装饰组件直接观察模型里的字段变化。举个例子补全一张卡片时我只改filledSlots这个字段候选项区、槽位区、得分面板三个组件各自感知变化并做对应UI更新。在这个模型里“哪张卡片填到哪个槽位”是唯一数据源无论交互从哪个入口进来最终都落到模型更新上杜绝了多个组件状态互相打架的问题。2.3 拖拽交互方案选型拼图游戏的核心手势是拖拽。HarmonyOS NEXT的ArkUI框架提供了两条路线一是通用拖拽能力即组件设置draggable(true)配合onDragStart、onDrop做事后数据交换二是自定义PanGesture手势完全由开发者控制移动、碰撞检测和落位。我的建议是通用拖拽适合本项目的绝大多数场景。原因有三点首先通用拖拽自带系统级的拖拽视觉反馈卡片在拖动过程中会生成跟随手指的半透明浮层这个效果看起来很高级完全不需要自己写其次拖拽数据通过DragData传递天然能跨组件、跨页面槽位组件可以在onDrop里直接拿到拖拽源卡片的信息不用管这个卡片原先在哪个列表里最后框架处理了大部分手势识别细节手指稍微偏移也不容易误触其它组件。泛路径中我需要做的反而是减法。第一版我试图让卡片支持双击选中、再单击落位这样照顾不擅长长按拖拽的低龄用户。但实际测试中发现同时支持点击和拖拽会带来手势判定混乱系统无法区分“用户是想拖动卡片”还是“想点击卡片”。最终砍掉了点击交互只保留拖拽。这个决策让我少做了很多手势判断逻辑——鸿蒙开发里绝大多数交互问题是“想要的功能太多”造成的。3. 核心实现从数据模型到拼图交互3.1 数据模型与题目资源先看看最终的实际代码结构。我把题目数据放在entry/src/main/resources/rawfile/levels.json中运行时通过资源管理加载。Python脚本负责生成它运行时不硬编码。levels.json简化版长这样{ levels: [ { levelId: 1, lawType: commutative, title: 加法交换律, slots: [ { slotId: s1, expectCardId: n3, placeholder: ? }, { slotId: s2, expectCardId: op1, placeholder: ? }, { slotId: s3, expectCardId: n5, placeholder: ? }, { slotId: s4, expectCardId: n5, placeholder: ? }, { slotId: s5, expectCardId: op2, placeholder: ? }, { slotId: s6, expectCardId: n3, placeholder: ? } ], cards: [ { cardId: n5, text: 5, kind: number, widthWeight: 1 }, { cardId: n3, text: 3, kind: number, widthWeight: 1 }, { cardId: op1, text: , kind: operator, widthWeight: 1 }, { cardId: op2, text: , kind: operator, widthWeight: 1 } ] } ] }注意slots的顺序就是等式从前往后的阅读顺序。卡片列表是去重后的“唯一卡片集合”因为题目里同一个数字可能出现在多个位置比如交换律里3出现两次5也出现两次。如果我在卡片列表里放两张n3和两张n5那么拼图校验时就要区分“哪张3应该放进哪个槽”会让逻辑复杂很多。我的做法是卡片按ID识别唯一性允许同一张卡片对应多个槽位。3号数字无论放进左边的第一个槽还是右边的最后一个槽只要槽位期望的卡片ID是n3校验就通过。加载题目时还要做一次洗牌。ArkTS里数组没有原生的shuffle方法我用一个简单的Fisher-Yates洗牌函数实现function shuffleT(arr: T[]): T[] { const result arr.slice(); for (let i result.length - 1; i 0; i--) { const j Math.floor(Math.random() * (i 1)); [result[i], result[j]] [result[j], result[i]]; } return result; }卡片列表原始排列是有序的每次进入关卡时对它做一次洗牌就能保证候选项的随机性。3.2 拼图板、卡槽与候选区的组件设计页面布局分三块顶部的进度与得分区、中间的等式拼图区、底部的候选项卡片区。等式拼图区是核心我用Row排列每个槽位槽位之间的运算符号如果是固定内容就直接渲染成文本不参与拼图。一开始我把等号左边和右边分别放在两个Row里中间塞一个Text()组件。实测后发现这种情况在窄屏手机上容易出现两边挤压间距失衡。后来改成整个等式放在同一个Row里所有元素包括等号、槽位、固定符号统一用Flex的spaceEvenly对齐这样不管屏幕多宽等号始终处在视觉中心点。候选区使用Grid组件排列四列布局。每张卡片是一个GridItem内层放一个带圆角背景的Text。通道卡片支持拖拽我给它设置.draggable(true)然后在onDragStart里把自己写入拖拽数据对象Builder TrayCard(card: CardConfig) { Text(card.text) .width(this.cardWidth(card)) .height(56) .textAlign(TextAlign.Center) .fontSize(24) .backgroundColor(Color.White) .borderRadius(12) .shadow({ radius: 4, color: rgba(0, 0, 0, 0.15), offsetY: 2 }) .draggable(true) .onDragStart(() this.startDrag(card)) }startDrag函数返回一个DragData对象携带当前卡片的id和kind信息。这里有一个细节数字卡片和运算符卡片的拖拽行为其实完全一致我并没有区分处理因为槽位校验只关心ID是否匹配。槽位组件使用Stack实现下层是一个半透明的占位框上层在“已填充”时显示卡片文本否则显示一个“?”。同时给整个槽位组件设置.allowDrop(true)并监听onDrop事件。这样一个槽位既能展示当前状态又能接收外部拖入的卡片。3.3 拖拽、吸附与正确性判定的完整链路拼图游戏的完整交互链路分四步拖起卡片、拖到槽位上方、松手落位、校验并更新状态。先说拖起。在onDragStart中设置拖拽数据时我并没有把卡片从候选区立即移除。这样做的目的是让玩家拖拽过程中原位置仍然保留一张“半透明占位卡片”视觉上更清楚。真正移除要等到落位结果出来之后。落位校验在槽位的onDrop回调中完成核心代码如下.onDrop((event: DragEvent, slot: SlotConfig) { const dragInfo event.getDragData() as DragInfo; if (dragInfo.cardId slot.expectCardId) { this.gameModel.fillSlot(slot.slotId, dragInfo.cardId); this.gameModel.markCardUsed(dragInfo.cardId); this.playCorrectFeedback(slot.slotId); this.gameModel.score 10; } else { this.playWrongFeedback(slot.slotId); this.gameModel.score - 3; } })这里有个容易踩坑的地方onDrop事件传入的对象需要自己解析拖拽数据而且不能假定拖拽数据一定来自本页面的卡片。我在解析前先判断了数据格式是否合法防止外来拖拽数据导致崩溃。校验通过后槽位要做出“吸附”效果也就是让卡片文本以动画方式出现在槽位中。我在SlotView组件里给文本加了一个scale过渡动画卡片刚被放入时文本从0.8倍大小弹到1.0倍模拟“卡到位”的手感。校验失败的卡片系统会把它弹回候选区。但注意不能让这个卡片掉在屏幕上任意位置。我的实现方式是目标槽位短暂显示红色闪烁然后通过事件回传给页面页面把当前卡片标记为“需要重置”配合动画延迟200毫秒后恢复原状。3.4 即时反馈、得分与动画教育类游戏最怕的是玩家做错之后没有任何解释。如果只是“叮”一声报错孩子根本不知道自己错在哪。所以我在得分反馈之外增加了视觉对比提示当放错槽位时等式两边对应的两个数值会同时高亮比如加法交换律中左边第一格高亮显示数字3右边最后一格高亮显示数字3用同样的颜色暗示“这两个位置其实放的是同一个数”。得分规则也做了精心设计正确得10分错误扣3分一关全部填对奖励20分。扣分力度不能太轻也不能太重。太轻孩子会随便乱拖试错太重会打击自信心。3分刚好是一道题得分的30%既能让孩子意识到错误要付出代价又不至于连续错几次就分数归零。动画方面我用了三种卡片被正确放置时槽位背景由半透明变为淡绿色卡片文本做一次轻微弹跳放错时槽位边框变红并抖动卡片自动飞回候选区整关完成时等式上出现一个短暂的彩色光晕扫过效果。这些动画都是基于ArkUI的animateTo实现的加上curve参数控制缓动曲线整体效果比较轻快没有过度花哨符合学习工具的气质。这里想强调一个观点教育游戏中的动画不是越多越好。动画的唯一职责是“传递状态变化信息”那些纯装饰性的动画反而会分散注意力。所以我把动画控制在三种状态反馈之内每一帧都要为学习目标服务。4. 实测踩坑记录拖拽冲突、刷新时序与屏幕适配4.1 拖拽手势和Scroll容器的消歧这个坑是上线前测试机上一眼发现的当候选区卡片超过一屏时我把它放在了Scroll组件里结果用手指拖卡片时上下滑动的页面和横向拖拽的卡片开始抢手势。手指稍微向上动一点整个页面就跟着滚想拖卡片到等式拼图区结果页面疯狂上下滑动卡片就是提不起来。排查过程大致是这样我先怀疑是Grid嵌套Scroll的问题于是单独把Grid拆出来测试发现单Grid里拖拽正常那问题基本锁定在Scroll组件对手势的竞争上。再查ArkUI的手势事件分发机制发现Scroll默认会把垂直方向的PanGesture吞掉我的onDragStart虽然在子组件上但父级Scroll在疑似垂直滑动时优先响应。最终的解决办法分两步。第一把候选项区改用固定高度的Grid不放在Scroll里卡片数量最多只有8张四列两行完全放得下根本不需要滚动。第二也是更偏防御性的做法在拖拽开始时把当前页面滚动设为禁用拖拽结束再恢复。不过既然是固定高度这个防御性处理其实也没触发。关键是第一点不要把需要拖拽的组件放在任何可滚动容器里否则一定会出现手势竞争。这是鸿蒙拖拽场景里非常典型的一个坑。4.2 拖放之后状态刷新时序问题第二个坑很隐蔽测试时只有我自己能感受到拖放正确之后槽位确实填上了卡片但候选项区原位置上的卡片在视觉上存在“过早消失”的问题。因为我在onDrop里立刻对候选卡片做了markCardUsed框架立刻从候选列表里移除该卡片此时槽位里的新卡片还在播放进入动画两者的时间差导致视线“跳跃”了一下。我最初觉得这是小事但给几个朋友试用后他们一致反馈有“顿挫感”。后来我调整了处理顺序先在UI层标记卡片为disabled并降低透明度同时启动槽位动画动画完成回调里再从候选项数组移除该卡片。整个时间差控制在250毫秒左右人的视觉刚好能接受既看到卡片从原位置飞出的过程又不会觉得拖拽响应迟钝。这个问题本质上说的是动画和状态更新必须共享同一个时间轴。状态更新不是越快越好要跟着动画节奏走。鸿蒙ArkUI的animateTo支持时间回调我把移除操作放在动画的onFinish里整个项目就顺畅了很多。4.3 小屏手机适配与卡片排版适配是另一个让我反复调的地方。最初设计时我按开发机尺寸测试卡片宽度固定90vp高度固定56vp。放到小屏手机上问题全来了9张卡片挤在四列里每张宽90vp总宽度早就超出屏幕运算符卡片和数字卡片混排后不同卡片文字宽度不一致有的挤成一团有的空一大片。后来我把固定宽度全部改成了按网格权重自适应的方式。数字卡片和运算符卡片的widthWeight不同简单起见数字五等宽运算符稍微窄一点。具体做法是在Grid外面包一层GridItem用栅格系统的columns属性把屏幕宽度平均分配然后每个卡片的width取“单元格宽度的90%”。字号也跟着屏幕宽度走小屏上自动从24vp缩到20vp。还有一种更精细的方案就是根据卡片kind动态计算宽度运算符卡片占整数格栅格的0.5格数字卡片占0.8格括号占0.6格。这个方案视觉效果最好但代码复杂度高一些。最终我给这个项目只保留了一个简化版本——所有卡片等宽因为本项目的运算符和数字在文本长度上差距不大等宽方案已经是性价比最高的适配方案了。5. 从“能玩”到“好用”扩展方向与题目生成自动化5.1 混合定律关卡与错题复盘七关做完之后我最大的感受是这个游戏完成了“能玩”要到“好用”还有很长的路。核心缺口有两个个性化的薄弱点追踪以及混合定律的变式训练。错题复盘是我优先级最高的扩展功能。目前的逻辑只记录得分没有记录“哪个定律类型容易错”。下一步我计划在每个关卡完成后把错误的卡片ID和定律类型写入本地数据库累计到一定量级后在首页生成一个“易错定律”推荐入口。比如孩子在分配律关卡连续错三次首页就会优先推送分配律的变式题而不是继续线性闯关。这里顺便可以接上HarmonyOS的ohos.data.relationalStore能力做本地持久化也可以先用简单的PersistentStorage字段存统计数据前期数据量不大时完全够用。5.2 用Python脚本批量生成题目数据热词里提到Python应用实例其实我确实在这个项目里用了Python只不过是在工程之外。用纯手写JSON维护七关题目每关又有多道变式非常容易出错。我写了一个Python脚本批量生成合法的定律等式输出成可直接合入工程的JSON文件。原理很简单枚举所有可能的数字组合按照定律模板生成等式左右两侧表达式再校验左右两侧计算结果相等消除重复题最后随机抽样组成关卡数据。比如生成分配律题目的核心逻辑import json import random def default_levels(): problems [] for a in range(2, 10): for b in range(2, 9): for c in range(2, 9): left f{a} × ( {b} {c} ) right f{a} × {b} {a} × {c} # 校验数值相等是多余的结构天然相等 problems.append({ lawType: distributive, expressionBefore: left, expressionAfter: right }) random.shuffle(problems) return problems[:20]生成后的JSON通过脚本直接写到entry/src/main/resources/rawfile/levels.json然后交给UI层运行。经过这步自动化我从“人工录入题目”变成了“审核题目”节省的精力可以用在更有价值的游戏机制设计上。5.3 下一步接成就体系和分享能力游戏化机制也是锦上添花的方向。我计划加入三档成就完成全部基础关卡、连续五关无失误、单关达到满分。成就信息展示在主页配合简单的进度环动画这会让孩子的完成欲直接提升一截。HarmonyOS的卡片服务还能将这个进度外溢到桌面小组件孩子不用打开App就能看到今天的定律拼图进度这个想法我等API能力稳定后会先做个原型。分享功能建议谨慎教育类应用分享太多反而打扰学习节奏我会做成“通关后家长可选择分享成绩单”避免在游戏过程中出现任何社交入口。说回这个项目本身定律拼图游戏的核心其实不复杂——一个小巧的拖拽拼图容器加上一套数据驱动的题目配置再加上恰如其分的反馈动画。它真正有价值的地方在于把一个抽象数学概念通过触觉和视觉具象化让孩子在动手的时候自然完成思考。做这个项目最大的感受是教育App首要目标不是让用户“觉得好玩”而是让用户“在玩的过程中产生有价值的思考”。如果你也打算做类似的数学启蒙小工具牢牢记住这一点就够了技术反而永远不是真正的门槛。