一、最小的小游戏最全的交互要素前面几个案例都是演示型的画个滚动视图、放张地图、给块画布功能摆在那里用户自己去看。案例 5.1 变脸游戏不一样它第一次有了游戏的味道页面上有一张脸谱点一下随机换一张摇一摇手机再换一张还弹一个提示框。功能不大但用户第一次有了玩法——触发一个动作期待一个不确定的结果。这种小小的随机惊喜感正是一切小游戏的心理内核。从技术视角看这个案例把三个重要角色凑到了同一张桌子上图片数组与下标绑定的数据驱动写法、随机数在界面切换中的应用、以及加速计这种让手机本身成为输入设备的传感器。三件事单独看都不难组合起来就是完整的交互闭环。二、界面一张图片就是全部舞台界面上没有花哨的东西一张脸谱图片居中摆放。真正值得留意的是图片路径的写法图片地址没有写死而是绑定到数组的一个下标上。数组里放着一整套脸谱图片的路径下标指向哪张页面就显示哪张。这个写法是数据驱动思想的又一次现身说法界面永远只是数据的镜子想让画面变化不需要去操作那张图片只要改下标这一个数字。案例里整个游戏的换脸动作最终都归结为改一个数字简洁得近乎优雅。样式层面图片加了外边距外面套着带紫色边框的卡片盒子标题文字用紫红色加粗居中——和前几个案例一脉相承的排版风格此处不再赘述。三、随机换脸一行公式背后的大学问换脸的核心是随机数。把随机小数乘以数组长度再向下取整就得到一个从零开始、不含数组长度本身的随机整数正好用来当数组下标。这条公式几乎出现在所有需要从一组东西里随机挑一个的场景中值得单独记下来。不过这个公式里藏着一个游戏设计的经典问题随机换脸可能换出来的是同一张脸。用户点了画面没变会觉得没反应。真正的川剧变脸是不允许原地不动的。案例遵循教材写法保持了简单但如果要提升体验正确的做法是先随机出一个下标如果和当前下标相同就重随一次或者干脆从除当前之外的下标集合里挑。这类排除自身的细节是从演示程序走向真产品的分水岭。四、摇一摇加速计让手机变成输入设备案例的重头戏是加速计接口。手机里有三轴加速度传感器分别在宽度、高度、厚度三个方向上感知加速度。注册一个监听函数后传感器每隔一小段时间就把三个方向的读数交给回调函数静止时读数很小猛地一摇读数瞬间飙高。案例的判断逻辑因此非常直白只要任何一个方向的加速度超过某个阈值就认定用户摇了手机随即触发换脸并弹出摇一摇成功的提示框提示停留几秒后自动消失。这里有几层经验值得提炼。第一监听的注册放在页面显示的生命周期函数里最合适——页面可见时传感器才有意义这是把资源和界面状态对齐的好习惯。第二阈值判断天然防误触手机放在桌上、装在口袋里正常走动读数都不会越线只有刻意摇晃才会触发。第三也是最容易忽略的一点这种持续监听的回调在页面销毁后最好主动注销否则后台还挂着无用的监听属于隐性的资源浪费。教材案例为了简短没写注销工程实践里应该补上。还有一点开发者要有预期加速计在开发者工具的模拟器里模拟不了真实摇晃必须用真机预览来测。调试传感器类功能手机永远比电脑靠谱。五、功能扩展让次数看得见作业要求动态显示累计变脸次数。这件事在思路上和前面 canvas 案例的颜色扩展如出一辙把一个本不存在的东西变成页面数据里的状态再用界面把它映射出来。具体做法分三步。第一步在页面数据里加一个计数器初始为零。第二步找到所有发生变脸的出口——不管这一脸是用户点出来的还是摇出来的最终都汇入同一个换脸函数——在这个函数里让计数加一。这里体现了代码组织的好处因为案例把换脸逻辑收拢成了一个函数点击和摇晃两条路径共用它扩展时只需要改一处两条路自动都生效。如果当初点击和摇动各写各的换脸代码这次扩展就得改两处还容易漏。这印证了一个朴素的工程原则相似的行为收拢到一个函数里扩展的成本才最低。第三步在界面上加一行文字把计数绑定显示出来。数据一变显示自动刷新“动态二字由此而来。有一个设计小决策值得说明随机换脸偶尔会换出同一张脸此时画面没变但计数照样加一。这算不算变了一次”可以争论。严格的做法是只在脸确实变了时才计数把计数逻辑挪到确认换了新脸之后。作业场景下按每次触发算一次理解即可但知道这个分歧点在哪比稀里糊涂照做更重要。d