前段时间我一直在写一个很轻量的小游戏糖果从屏幕顶部落下来玩家拖动下方的小篮子接住它接住加分漏掉扣命。听起来简单但真正做下来绕了不少弯。最终确定的技术组合是 React PixiJS跑通了桌面浏览器、移动浏览器和部分竖屏小游戏容器核心玩法逻辑几乎一套代码复用。这篇文章把这套实践从选型、架构、代码到踩坑都记下来给想用前端技术栈写多平台小游戏的人做个参考。1. 整体设计与技术选型为什么偏偏是React PixiJS1.1 多平台小游戏到底难在哪先说结论多平台小游戏最难的三个点不是特效多炫也不是玩法多复杂而是性能、适配和状态管理。以糖果接接乐为例核心场景里同时存在糖果、篮子、背景、分数、特效这些元素每秒都在变动位置。如果全用 DOM 去做节点一多移动端直接卡成幻灯片。因为 DOM 的每一次位置修改都要走样式计算、布局、绘制浏览器根本扛不住高频更新。这时候需要 Canvas 或者 WebGL 来做真正的游戏渲染层。纯 Canvas 2D 能做游戏但如果你要管理几十个精灵对象、做图集、做粒子、做缓动几乎都得自己造轮子。PixiJS 的好处是它已经把 WebGL 渲染封装得很成熟Sprite、Container、Ticker、Loader、Interaction 这些游戏开发必备件都有性能上限也比纯 Canvas 2D 高很多。另一个难点是状态管理。游戏里有一大堆高频变化的数据角色的坐标、糖果的下落速度、碰撞结果、连击分数。这些数据如果都塞进 React 的 state 里每帧 setState 一次React 会疯狂重渲染整个页面直接废掉。React 能管的是游戏的大状态比如当前处于开始界面还是游戏中或者暂停菜单是否弹出而游戏内部的帧级状态应该交给 PixiJS 自己管。再有就是平台适配。桌面端是鼠标移动端是触摸某些容器还有自己的生命周期回调比如从前台切后台再回前台游戏会加速。这些东西都要在设计之初就留好口子。1.2 React与PixiJS怎样分工我最后定下来的架构思路简单说就是两句React负责壳PixiJS负责肉。React 负责所有不需要高频更新的界面开始菜单、暂停按钮、结算弹窗、音效开关、设置面板。这些东西用 React 写太舒服了组件化、状态化、条件渲染都很自然。PixiJS 负责游戏主舞台所有 Sprite、纹理、动画、粒子、碰撞检测、帧循环。它自己在 Canvas 上绘制不经过 React所以即使游戏里有几百个精灵开发时也不会因为状态更新引发 React 重渲染。两者之间通过事件或者回调通信。比如玩家点击开始按钮React 把消息告诉游戏引擎层引擎层开始执行主循环游戏结束时引擎层抛一个gameover事件React 收到后展示结算 UI。这种单向通信非常简单不需要引入复杂状态库。我项目里把目录结构设计成下面这样src/ engine/ ## PixiJS 相关的封装 createApp.ts loadAssets.ts GameLoop.ts scenes/ ## 游戏场景 PlayScene.ts LoadingScene.ts ui/ ## React 组件 Menu.tsx HUD.tsx GameOver.tsx hooks/ useGameEngine.ts state/ gameState.tsengine 层完全不依赖 React拆出来以后可以单独测试也可以在其他非 React 项目里复用。React 层通过useGameEngine这个 hook 拿到引擎实例只管界面逻辑。1.3 为什么不是纯Canvas、Three.js或游戏引擎也对比过其他方案说说我的取舍。纯 Canvas 2D 适合做简单动画但游戏一复杂就会陷入重复造轮子。对象管理、渲染批次、纹理集、事件系统、缓动这些每个都要自己设计开发周期太长。Three.js 是 3D 渲染引擎做 2D 小游戏属于杀鸡用牛刀。它会引入大量 3D 概念比如相机、透视投影、场景图虽然也能做 2D但成本和收益不成正比。糖果接接乐这种玩法根本用不到。重型游戏引擎比如 Unity 导出的 Web 包功能强大但体积巨大首屏加载很重而且和前端团队的技能栈不匹配。团队需要重新学 C# 和编辑器迭代效率反而不高。PixiJS 恰好落在中间比 Canvas 2D 强大很多比 Unity 轻量很多而且和 TypeScript、React 一起用非常顺手。它的 API 很贴近传统 Flash 开发习惯有过游戏开发经验的人几乎零成本上手纯前端工程师也很快能理解 Container/Sprite 这套对象模型。2. 核心协作机制与生命周期设计2.1 初始化与销毁的正确姿势React 和 PixiJS 的协作最关键的其实是生命周期。PixiJS 的 Application 实例不是普通 DOM 元素它内部有 WebGL 上下文、渲染循环、事件总线如果你初始化了却不销毁组件卸载之后它还在跑内存泄漏会很严重。我的做法是把 PixiJS 的初始化放在useEffect里依赖项为空数组确保只在组件挂载时创建一次。组件卸载时在清理函数里调用destroy()。import * as PIXI from pixi.js; import { useEffect, useRef } from react; export default function GameCanvas() { const containerRef useRef(null); useEffect(() { const app new PIXI.Application({ width: 750, height: 1334, backgroundColor: 0x1a1a2e, antialias: true, resolution: Math.min(window.devicePixelRatio || 1, 2), autoDensity: true, }); containerRef.current.appendChild(app.view); // 这里后续会初始化场景和循环 initGame(app); return () { app.destroy(true, { children: true, texture: true }); }; }, []); return div ref{containerRef} classNamegame-canvas /; }有几个细节我测下来很重要。resolution不要直接取window.devicePixelRatio的最大值。很多安卓机的 devicePixelRatio 是 3甚至更高如果全量适配渲染压力会翻好几倍帧率直接崩。我通常限制到 2视觉上几乎看不出差异性能却能保住。destroy(true)的第一个参数是removeView表示把 canvas 从 DOM 里移除。第二个参数里的children和texture一定要设成 true否则你创建的 Sprite 和纹理不会释放下次进入页面时显存占用会一直涨。还有一个我踩得很深的坑如果 React 组件在 StrictMode 下运行开发环境会执行两次 effect 挂载再卸载再挂载如果清理逻辑没写好你就创建了两个 WebGL 上下文。虽然浏览器一般能撑住但某些容器里会直接黑屏。所以要确保destroy是完整且幂等的。2.2 帧循环与React状态如何划界这是整个方案里最需要想清楚的地方。游戏引擎一般有一个主循环PixiJS 里对应的是app.ticker。Ticker 每帧都会执行一次回调传入 delta 参数表示上一帧到当前帧的时间比例。常规 60FPS 下 delta 接近 1如果你在 120Hz 的屏幕上delta 会接近 0.5所以所有移动距离都应该乘以 delta保证速度一致。在这个回调里所有游戏对象的位置、速度、碰撞都是逐帧更新的。这些数据千万不能同步到 React state 里。我最初犯过这个错误为了让 HUD 显示实时分数我每帧都setScore一次结果整个 UI 树每秒重渲染六十次菜单和按钮都变得很卡。后来我改成 PixiJS 的 Text 对象直接绘制分数分数字段的更新根本不经 React帧率一下就稳了。反过来真正的 UI 界面事件就不要放到游戏主循环里。开始按钮、暂停按钮、弹窗开关这些低频状态保存在 React 里通过事件通知引擎。两者之间的桥接我用了最简单的事件回调// engine 触发 playScene.on(score, (value: number) { scoreText.text 分数 ${value}; }); playScene.on(gameover, (finalScore: number) { // 通知 React 层展示结算面板 eventBus.emit(gameover, finalScore); });这样 React 只知道游戏开始了、结束了、当前分数是多少至于糖果怎么掉、篮子怎么移都是 PixiJS 自己的事。2.3 资源加载与异步处理的坑小游戏的素材包括音效、背景图、糖果精灵图一般不用在运行时每帧下载。PixiJS 提供了 Loader可以批量加载并支持进度回调。const loader PIXI.Loader.shared; loader .add(bg, assets/bg.jpg) .add(candy, assets/candy.png) .add(basket, assets/basket.png) .load((loader, resources) { const texture resources.candy.texture; startCreateCandy(texture); });这里有几个问题项目里反复出现。第一个是加载进度和 React 界面的联动。如果你在 Loader 的回调里直接 setState 更新进度条一定要先确认组件还没卸载。更好的做法是封装一个加载管理类把进度回调通知到事件总线React 侧自己决定要不要展示。第二个是参数传递。resources.candy.texture有可能在加载成功后读取但如果你打包成某些容器格式路径会变化最好用相对路径或者统一资源管理函数。第三个是加载失败重试。Loader 本身没有很好的重试机制我封装了一个简单的loadWithRetry失败后延迟一秒重新加载同一个资源最多重试三次。小游戏在线加载时总会有网络波动这个兜底能救回不少玩家。3. 从零完成一款“糖果接接乐”小游戏3.1 项目初始化与目录结构我用 Vite 搭的基础工程加上 TypeScript这步没什么特别的按照常规前端工具链初始化就行。这里额外说一下目录结构里最重要的 interface 定义。把游戏对象拆成 TypeScript 接口后面维护能省很多事。interface Candy { sprite: PIXI.Sprite; speed: number; active: boolean; } interface Player { sprite: PIXI.Sprite; targetX: number; }接口的意义不在于多写几个字段而在于后来加功能时能快速定位问题。比如糖果要支持不同分数权重我给 Candy 加了一个scoreValue碰撞时直接读取不需要再老花眼一样地找魔法数字。3.2 舞台适配与多分辨率适配多平台小游戏绕不开分辨率适配。桌面上可能是 1920x1080 的横屏手机上可能是 390x844 的竖屏某些平板又是 1024x1366。全都按像素去写坐标游戏就没法看了。我采用的方法是固定设计宽高 750x1334然后在运行时计算缩放比例。这个思路非常像前端的 rem 适配先给一个标准画布再等比缩放到实际屏幕上。const DESIGN_WIDTH 750; const DESIGN_HEIGHT 1334; function resize(app: PIXI.Application) { const scale Math.min( window.innerWidth / DESIGN_WIDTH, window.innerHeight / DESIGN_HEIGHT ); app.stage.scale.set(scale); app.renderer.resize(DESIGN_WIDTH * scale, DESIGN_HEIGHT * scale); }逻辑是取两个方向缩放的较小值保证画面完整显示不留黑边也不裁剪内容。这个方法在极端比例的屏幕上会有一些剩余空间可以用背景图或渐变色盖住。真正容易踩的坑是事件坐标的换算。玩家点击屏幕你拿到的是 CSS 像素坐标而游戏内部对象是在 PixiJS 的逻辑坐标里。如果 stage 缩放过了直接拿点击坐标去判断碰撞就会错位。这种情况我用边缘情况测试才定位到点击图层时命中区域明显偏了检查之后发现坐标没有除以缩放值。规范做法是在 stage 的 scale 变化后通过容器的toLocal方法转换坐标const localPoint app.stage.toLocal(globalPoint);这样点击坐标和逻辑坐标就完全对上之后再做碰撞或者拖拽都稳。另外 canvas 元素的 CSS 也很关键。游戏画布必须设置.game-canvas canvas { touch-action: none; user-select: none; -webkit-touch-callout: none; }touch-action: none告诉浏览器这个区域的事件不交给默认滚动和缩放否则手指在屏幕上拖动时页面会跟着滚还会触发 iOS 的橡皮筋效果。3.3 核心玩法与交互实现糖果生成的逻辑用了对象池。预先创建 20 个糖果 Sprite初始active为 false不可见。每帧检查当前活跃的糖果数量不足就往池子里取一个未激活的从屏幕顶部随机位置下落。对象池的理由是避免频繁销毁创建 Sprite。我给一个数字游戏进行两分钟大约会产生 120 个糖果。如果每个糖果都是一个新 Sprite加载纹理、分配显存、触发 GC手机上很容易出现卡顿。对象池复用实例渲染压力和内存波动都小很多。运行逻辑的伪代码大致是app.ticker.add((delta) { // 1. 更新玩家位置 player.sprite.x (player.targetX - player.sprite.x) * 0.1 * delta; // 2. 更新场景里所有糖果位置 candies.forEach((candy) { if (!candy.active) return; candy.sprite.y candy.speed * delta; if (candy.sprite.y DESIGN_HEIGHT) { deactivateCandy(candy); lives - 1; } }); // 3. 碰撞检测 checkCollision(); // 4. 更新 HUD 文本 scoreText.text 分数 ${score}; });碰撞检测是 AABB 思路比较两个矩形的边界。PixiJS 每个 Sprite 都有getBounds()方法可以直接拿到世界坐标的矩形范围function hitTest(a: PIXI.Sprite, b: PIXI.Sprite) { const r1 a.getBounds(); const r2 b.getBounds(); return !( r1.x r1.width r2.x || r2.x r2.width r1.x || r1.y r1.height r2.y || r2.y r2.height r1.y ); }这个方法对小游戏足够用又不需要引入物理引擎。注意getBounds()本身有计算开销几百个对象以内没问题但如果同时有好几千个对象就要考虑自己用坐标维护包围盒减少引擎内部计算。交互层用 Pointer Events 统一处理鼠标和触摸不区分 mouse 和 touch 两套事件。app.stage.eventMode static; app.stage.on(pointermove, (event) { const local app.stage.toLocal(event.global); player.targetX local.x; });这里pointermove的好处是桌面鼠标移动、手指滑动都能覆盖而且移动端不会触发 300ms 点击延迟。targetX不直接赋值而是通过插值平滑移动过去手感更柔和也不容易手指一抖飞出去。游戏结束时引擎抛事件React 层展示结算弹窗这个流程和前面讲的状态划界完全一致。4. 多平台运行与性能调优4.1 桌面端与移动端的适配细节先说视觉区域的差异。竖屏小游戏容器通常有自己的安全区概念刘海屏的顶部是传感器区域底部是 Home 指示条。如果 UI 死贴屏幕边缘看起来很怪。我给两种平台做了公共的 safe area 处理React 层的 HUD 用 CSS 的env(safe-area-inset-top)和env(safe-area-inset-bottom)做内边距。PixiJS 层则尽量把核心玩法放在设计稿中央不依赖边缘区域。移动端另一个常见问题是页面滚动穿透。手指在 canvas 上拖动时如果 canvas 的touch-action没设置页面会跟着滚动。我在前面的 CSS 里已经处理了但还要再强调一次因为这个问题反复出现尤其是有底层页面滚动的时候。桌面端的细节在于鼠标事件。pointermove在鼠标移动时会持续触发但如果玩家鼠标移出 canvas 区域事件可能丢失导致篮子停在原地。我加了一个兜底监听pointerleave事件把 targetX 设置为当前坐标防止角色卡在边缘。某些小游戏容器在切到后台时会停止帧循环但容器的逻辑时间不会暂停。回到前台时delta 可能跳到一个很大值导致糖果瞬移。这是特别经典的 bug。我的处理是监听容器组的visibilitychange或者pause事件切出时暂停 ticker切回时重置 delta。document.addEventListener(visibilitychange, () { if (document.hidden) { app.ticker.stop(); } else { app.ticker.start(); } });我不建议直接用app.ticker.stop()和start()之外的方法因为 ticker 本身内部状态保持得还行直接启停就够了。音频的自动播放策略也是个坑。很多浏览器要求用户先有交互行为才能播放声音否则直接被忽略。我的做法是游戏开始按钮的点击回调里先 resume 一次 AudioContext后续所有音效都从这里创建。这样既满足浏览器限制又不会在最开始就让玩家听到尴尬的欢迎音。4.2 令帧率稳定的性能手段如果只是接糖果这种数量级优化空间不大。但既然面向多平台保不齐后续会加特效、加金币、加敌人性能手段我提前花了心思。第一个是纹理图集。把所有糖果的不同颜色、不同分值合到一张 PNG 图集里运行时只加载一次大纹理多个 Sprite 用不同 frame 显示。这样 GPU 不用频繁切换绑定纹理Draw Call 降得很明显。PixiJS 支持 TextureAtlasJSON 格式可以直接加载工具方面美术同事那边用常见图集工具导一下就行。第二个是对象池前面讲玩法时已经实现了。我再补充一个细节对象池不只用于糖果特效粒子也可以用同一个池子。爆炸碎片、得分飘字全部走池化逻辑。我统计过特效不池化的时候卡顿是肉眼可见的池化之后同样特效量下帧率稳在 60。第三个是裁剪。屏幕外的对象直接设置visible false不参与渲染。PixiJS 本身没有自动视锥剔除对场景图里的所有子对象都会尝试绘制所以手动管理可见性是必要的。candy.sprite.visible candy.sprite.y -50 candy.sprite.y DESIGN_HEIGHT 50;这个操作成本几乎为零却能减少不少裁剪计算和渲染指令。第四个是避免每帧创建对象。循环里尽量不要写new关键字玩家移动、糖果下落都不需要重复生成对象。偶尔需要临时变量时也尽量在循环外复用。第五个是控制 resolution。前面已经提到这个开发初期直接设成 2 倍像素比从 60 帧到 45 帧的问题很多人第一反应是优化渲染代码最后查下来只是像素倍数太高了。5. 常见问题与排查技巧实录5.1 高频问题速查现象可能原因解决方案重新进入页面后游戏卡死上一次 PixiJS Application 未销毁清理函数里调用 destroy并释放 texture 与 children图片看起来很糊resolution 设置太小或缩放后纹理采样模糊适当调大 resolution必要时使用 mipmap按钮点了没反应上层 DOM 遮挡了 canvas或 interactive 没开检查 z-index统一用 stage 的 eventMode 管理事件回到前台后糖果瞬移帧循环暂停后 delta 暴涨监听隐藏/显示事件恢复时重置 delta游戏区域页面滚动缺少 touch-action 处理设置 touch-action: none手机端点击反应慢使用了 click 事件等待 300ms使用 Pointer Events 替代音效不播放浏览器自动播放策略限制在首次交互时 resume AudioContextWebGL 上下文创建失败多个 PIXI.Application 实例同时存在销毁不用的实例限制实例数量这个表基本是我整理项目时最常翻的部分。说实话出了问题以后靠记忆排查效率很低我建议你把项目的典型报错和对应解法也建一个文档。5.2 可复用的排查思路一个特别有效的排查方法先分辨问题出在渲染层还是逻辑层。如果画面卡但日志正常多半是渲染层先调 resolution、看看有没有 Draw Call 异常。如果对象位置不对但画面流畅多半是逻辑层比如坐标换算、delta 使用错误。另一个思路拿掉 PixiJS 的渲染逻辑只看 React UI看卡顿是否消失。如果消失了说明问题在这两者的协作边界而不是引擎本身。这样能省很多定位时间。我调试的时候习惯在 stage 顶层挂一个调试 Text实时显示当前 FPS、对象数量、碰撞次数。这个文本只在开发模式下开放上线时通过app.stage.removeChild(debugText)移除。好处是任何性能波动都能肉眼看到不用依赖外部性能工具。const debugText new PIXI.Text(, { fontSize: 24, fill: 0xffffff, }); app.stage.addChild(debugText); app.ticker.add(() { const fps app.ticker.FPS; debugText.text FPS: ${fps.toFixed(1)}; });这个习惯帮我快速定位过两三次疑似卡顿的问题每次都能明确到底是渲染还是逻辑导致的。还要提醒一点多端环境要提前准备真机测试环境。有些问题在浏览器模拟器里根本复现不了比如手势冲突、安全区遮挡、前后台切换后的异常表现。我项目在开发中期就固定了每周一次真机回归与其等用户反馈不如自己提前暴露。最后分享一个小心得这个项目让我对 React PixiJS 这套组合的看法更清晰了它解决的是“前端团队低成本进入游戏开发”的问题而不是“做一个大型 3D 游戏”的问题。和传统游戏引擎相比它在界面搭建和业务代码复用上优势非常明显和纯 Canvas 方案相比它把渲染、图集、交互、缓动这些底层脏活扛了下来。我个人在实际操作中的体会是真正耗时间的不是写玩法逻辑而是反复处理平台差异和生命周期问题。如果一开始就在架构层面想清楚渲染层和 UI 层的边界后面能少踩一大半坑。你要是有类似的小游戏想法也建议先拿这套组合快速出一个可玩原型再逐步迭代体验细节。扩展方向上后续我准备加一下排行榜系统和皮肤系统核心思路不变React 管页面PixiJS 管舞台这套架构完全撑得住。