性能优化：让棋盘更丝滑
性能是没人会主动要求、但一卡就会被察觉的东西。这篇把 YiBoard 的性能优化摊开讲：中端安卓机上测到的四个数字、棋盘从 225 个 DOM 节点改成单个 canvas 的取舍、500 毫秒引擎预算怎么不再冻住棋盘，以及我们拒绝做的几项优化。
性能优化是那种没人会主动提、直到棋盘卡一下才被察觉的工作。在 YiBoard 上它落到几个具体的数字：棋盘画出来要多久、手指按下到棋子出现要多久、引擎搜索的那半秒里画面还顺不顺。下面是我们在一台 2021 年中端安卓机、限速 4G 下测到的数字，由此引出的改动，以及几项我们拒绝做的优化。先去 yiboardgame.com 的对战页落几颗子再往下读，这些数字会更有实感。
我们一开始测到的数字
测试机是一台 2021 年的中端安卓机，网络限速到 4G，因为这比光纤上的笔记本更接近我们的真实流量。改动之前，棋盘首屏绘制 380 毫秒，一次落子平均在手指按下后 140 毫秒才出现，引擎搜索的那 500 毫秒里帧率掉到 41。没有一个数字能让游戏玩不了，但它们合在一起，让这个游戏显得比它实际的做工便宜。
- 棋盘首屏绘制：限速 4G 下 380 毫秒
- 手指按下到棋子出现：平均 140 毫秒
- 引擎搜索期间的帧率：41fps
- 能落第一颗子之前要下载的产物：gzip 后 214KB
棋盘渲染优化：一个 canvas 换掉 225 个 div
第一版棋盘是 225 个 DOM 节点，每个交点一个，网格用 CSS 边框画。它好改样式，可浏览器一重绘就散架。我们把网格和棋子搬到单个 canvas，DOM 只留棋盘外的界面。重画一颗子现在变成裁剪后重绘一格，不再是整块棋盘走一遍布局。这一项把首屏从 380 毫秒压到 190 毫秒，也是我们不做落子动画的原因之一。
网页游戏性能，与 500 毫秒的引擎预算
五子棋引擎在浏览器里跑 alpha-beta，预算 500 毫秒。朴素的写法会把主线程整整吃掉半秒，于是我们把搜索挪进 worker，让棋盘在引擎思考时继续绘制；局面已经定了的时候，改成限制深度而不是限制时间。搜索本身的细节写在引擎那篇。那台安卓机上的结果是：搜索期间帧率从 41 变成 58，棋盘也不再在对手落子之前冻住那一下。
一个不卡的游戏，还欠网络什么
每一步都要送到服务器端校验，这正是作弊做不到的原因，也是延迟藏不住的原因。我们把每一手一个请求改成复用同一条连接，并让自己的棋子先在本地出现、服务器确认在后。如果服务器判定这一手不成立，棋子会被收回，并告诉你原因。猜错一次的代价是一段动画；每一步都等一个来回的代价是整局游戏。
- 每局复用一条连接，不再一手一个请求
- 自己的棋子先本地出现，服务器确认在后
- 断线重连重放棋谱，而不是重开一局
- 对局进行中不为排行榜做后台轮询
我们拒绝做的优化
- 不做落子动画。它在截图里好看，却会让一个快节奏的游戏显得慢
- 不预取对手的可能走法。猜错比多等 40 毫秒更糟糕
- 不用 WebGL 画棋盘。2D canvas 画 15×15 的网格，跑满 60 帧不需要着色器
- 不用 service worker 缓存对局状态。棋盘显示错了，比慢一点更难让人接受
FAQ
AI 思考的时候，棋盘还会卡吗？
这一轮之前会。搜索现在跑在 worker 里，我们测试用的那台中端机上棋盘可以保持 58 帧。桌面浏览器上前后其实都看不出差别。
YiBoard 在移动网络下要用多少流量？
落第一颗子之前约 214KB（gzip 后），之后除了棋步本身不再产生数据。没有广告，没有追踪脚本，也没有分析用的包跟着进来。
既要跑 worker 又要跑服务器，还能一直免费吗？
能。免费在这里是设计选择，不是试用期。引擎跑在你自己的设备上，这正是服务器成本压得住的原因。
老一点的手机能享到这些改进吗？
大部分能，只有一处例外：worker 需要大约 2018 年以后的浏览器。更老的设备会退回主线程，棋盘一样能下，只是保留原来那一下卡顿。
Related
- 真引擎：浏览器里的 alpha-beta
2026-08-09
- 移动端专项优化：为单手而做的棋盘
2026-10-20
- 网页版 vs 桌面版：体验对比
2026-09-06