超低配版滚动天空：Canvas 2D实现伪3D飞行背景

最近被一个需求逼着做了一回"减法"——某小游戏的启动场景需要一段3D飞行视角，说白了就是天空一直往身后滚动、地面不断向屏幕下方流动的伪飞行效果。需求方最初提的是"要炫、要立体、要有体积云"，可测试机是一台好几年前的安卓低端机，直接上WebGL渲染那是一帧三卡顿。最后我把方案改成了"3D游戏案例：滚动天空（超低配版）"，砍掉三维模型、砍掉粒子系统、砍掉相机矩阵，用一张贴图加几层视差滚动，硬是把这老机器跑到了能看的流畅度。这篇文章就是这次取舍过程的完整记录，给同样被性能卡脖子、又想出视觉效果的H5项目一个参考路径。

我知道很多人一看到"3D"就觉得必须上Three.js、必须开WebGL，但实际项目里大量场景根本不需要动用GPU重管线。这篇文章适合三类人：一是H5页面里想做飞行/跑酷背景但设备性能吃紧的开发者，二是刚接触游戏前端、想搞懂滚动天空原理的初学者，三是做轻量化页面时想少写代码多点效果的Web前端。我会从视觉欺骗原理讲到Canvas 2D的具体实现，再把我踩过的性能坑一个个摊开讲。

1. "超低配版"到底在省什么：需求边界与目标设备

先给这个项目画个像。我们要做的不是完整3D游戏，只是一个"看起来像在3D世界往前飞"的背景层，通常出现在游戏开始界面、过场动画或者横向跑酷的远景。所谓滚动天空，英文社区一般叫Scrolling Sky，核心视觉效果是：云层不断向后掠过，远处的地平线基本不动，近处的地面/海面快速向屏幕下方流动，给玩家一种正在前进的错觉。

既然是"超低配版"，就必须明确什么不做。我做了个表格来约束自己，也建议每个做性能受限项目的同学先这样列一下：

1.1 项目诞生背景：一次关于"炫酷与流畅"的谈判

事情是这样的，某游戏项目需要一个飞行启动页，原方案是WebGL粒子星空加体积云。开发和设计试了一版，在iPhone上确实漂亮，但换到一台几年前的安卓中低端机上一测，帧率掉到5fps，连UI点击都跟着卡。当时摆在我面前两条路：要么劝甲方把所有高配效果砍掉换普通星空，要么做一个看着还有飞行感、但硬件门槛极低的版本。我选了后者，理由很简单——普通星空太平了，甲方不会满意，而一个"低配但动态丰富"的滚动天空，既能保住场景的沉浸感，又能把所有玩家的设备都拉进可玩范围。

于是这个项目的目标设备被明确为：2015-2018年左右的安卓中低端机、老款WebView、甚至部分无法开启硬件加速的桌面浏览器。目标帧率一开始定在30fps，实测中早期版本只能跑到15-18fps，后面优化完才稳定在30fps附近。整个优化的过程，其实就是在不断追问：哪一帧像素是被浪费的？

1.2 超低配版的"不做什么"清单

做超低配版最忌讳的是"嘴上说低配，手里全高配"。我列一个我在这个项目里强制执行的负面清单，你可以直接抄：

• 不创建任何3D网格对象，连一个Box都不要。低配版的立体感全部依赖贴图本身。
• 不用shader，不代表不能有渐变和光感。我把所有的明暗、边缘光直接画进一张1024x512的PNG里，运行时零光照计算。
• 不每帧调整canvas尺寸。canvas宽高只初始化一次，改变尺寸在低端机上是巨大的重排代价。
• 不用全局blur滤镜，哪怕是CSS的filter也会造成整层重绘。云层边缘模糊直接用软笔刷绘制在贴图里。
• 不做正弦波动态地形。地面滚动就老实滚动，波形起伏放到中等配置的版本再说。

做完这个清单之后，心里反而踏实了——需求被压缩到了一个很小的实现面，剩下的就是如何把这块小实现打磨得尽可能漂亮。

2. 没有相机，没有GPU：滚动天空的视觉欺骗原理

很多人第一次做滚动天空时会陷入一个误区：一定要把相机放在一个三维空间里，然后让世界坐标跟着相机动。结果代码写了一堆矩阵运算，性能也没保住。我后来想明白了一个道理：玩家在滚动天空里的"前进感"，本质上是视觉系统对纹理运动模式的一种解读，只要我们能欺骗眼睛，三维空间里那套完整的数学完全可以不出现。

2.1 你的眼睛以为在前进，实际只是在平移贴图

想象你坐在一趟匀速行驶的火车上，窗外是平原。你的眼睛是怎么判断火车在动的？主要是看窗外物体相对你的移动速度：近处电线杆嗖嗖往后飞，几公里外的山几乎静止，更远处的云和太阳看起来完全不动。这个现象叫视差，也是滚动天空的心理学基础。

超低配版的做法就是把这个现象拆解成三层贴图的平移速度差异。最远处的地平线山峦层，速度最慢甚至静止；中间云层速度中等；近处的云层和地面条带速度最快。只要速度比例关系接近真实经验，大脑就会自动脑补"我们在前进"。这里有个关键点：各层速度不是随便设的，最好符合一个指数关系，比如远层每秒20像素、中层每秒60像素、近层每秒140像素，而不是等差递增，等差显得假，指数更接近真实透视。

2.2 地平线汇聚：最低成本的纵深暗示

光有速度差异还不够，人眼判断深度还需要第二个线索——近大远小。在纯2D滚动里怎么表现近大远小？答案是让地面纹理条带从地平线开始慢慢变宽、变密，越靠近屏幕底部的条带越宽。这样地平线上方是天空的缓慢滚动，地平线下方是不断向下冲刷的地面条带，观众会产生"地面正从我脚下飞速流过"的错觉。

我当时用了一个极其简单的公式，把地面分成N条横带，第i条带的屏幕Y坐标按幂函数分布： y = horizonY + Math.pow(i / N, 1.8) * (canvasHeight - horizonY)

这个幂函数里的1.8就是模拟透视缩短的关键。指数越大，越靠近地平线的条带越密集，视觉上远处的物体被"压扁"，纵深感越强。实测1.6到2.2之间效果都不错，超过2.5会显得地面比例失真。

2.3 为什么"滚动天空"而不是"移动玩家"

另一个容易犯的设计错误是试图移动玩家角色来制造前进感。低配版里没有玩家实体，或者玩家在界面层独立存在，背景不需要反向位移去反映玩家运动。滚动天空里唯一的运动源就是背景纹理的偏移量，它和游戏逻辑里的玩家坐标完全解耦。好处是背景消耗几乎恒定——无论游戏逻辑多复杂，背景每帧只有固定次数的drawImage，不随场景增长。

具体到代码层，所有的滚动都归结为一个数字：offset（偏移量）。云层、地面、甚至偶尔飞过的飞鸟剪影，都基于这个offset加上各自的深度系数算出来。整个天空场景本质上只维护一个不断增长的变量，然后让各个层读取它。

3. 分层视差与伪3D投影：手写滚动天空的完整实现

原理说通了，进入正题。我会把简化版的实现拆成四段来讲，所有代码都是我实际跑过的结构，你可以直接复制改造。

3.1 整体渲染架构：离屏层 + 三层叠加

我的渲染架构很简单，一个主Canvas，三个预渲染的离屏Canvas，每帧做的事情只有平移和绘制：

• 天空渐变层：一张从顶部深蓝渐变到地平线附近淡蓝/橙色的渐变图，完全不滚动或极慢滚动。
• 远山与远云层：一张宽度足够循环的半透明纹理，每秒20-30像素滚动。
• 中近云层：两张不同深度云的纹理，速度一个每秒50一个每秒90。
• 地面透视条带层：用一个单独函数动态绘制，由N条纹理条带构成，每条独立水平滚动。
• 遮罩层：为了增加镜头感，加了一个半透明暗角，静态绘制。

离屏Canvas的好处是，不管你屏幕上叠加多少层，实际每帧drawImage调用次数是固定的，而且预渲染的云层已经包含了alpha混合的结果，运行时不需要多次设置globalAlpha。

3.2 滚动偏移量的数学：时间步长与层深系数

所有层的滚动都来自同一个offset。需要一个平滑的、不受帧率波动影响的时间驱动。我之前先踩过一个坑：直接用requestAnimationFrame的回调次数累加偏移，结果在60Hz屏幕上正常，到30Hz屏幕上跑得慢了一半，游戏体验完全不同步。后来改成用真实时间差来驱动。

单位时间偏移量的核心代码：

const TICK_RATE = 1000 / 60; // 基准速度按60fps定义 function update(scene, timeMs) { let dt = timeMs - scene.lastTime; scene.lastTime = timeMs; // 关键：clamp最大帧间隔，避免切后台回来后云层瞬移 dt = Math.min(dt, 50); // 速度缓动：从当前速度向目标速度靠近 scene.speed += (scene.targetSpeed - scene.speed) * 0.02; // 基础偏移以每秒像素为单位，乘上dt/16.67归一化到60fps const normalizedDt = dt / (TICK_RATE * 16.67); scene.offset = (scene.offset + scene.speed * normalizedDt) % TEXTURE_SIZE; }

TEXTURE_SIZE取纹理的像素宽度，取模的目的是让循环无缝衔接。这里有个细节：所有无缝滚动纹理的宽度务必是2的整数次幂，比如512、1024，这是因为取模运算在二进制位运算里可以直接用按位与完成，同时避免平台在纹理采样时出现接缝。

3.3 Canvas 2D 核心代码：三层天空的绘制循环

直接上一个能跑的最小实现。我为了让代码可读性更好，去掉了项目里的裁切和暗角逻辑，只保留核心。

class ScrollingSky { constructor(canvas, options) { this.canvas = canvas; this.ctx = canvas.getContext('2d'); this.width = canvas.width; this.height = canvas.height; this.skyGradient = this.createSkyGradient(); this.farCloud = this.createCloudLayer('rgba(255,255,255,0.18)', 0.25); this.nearCloud = this.createCloudLayer('rgba(255,255,255,0.36)', 0.55); this.horizonY = this.height * 0.42; this.offset = 0; this.speed = 0; this.targetSpeed = options.speed || 60; this.lastTime = performance.now(); this.groundStrips = this.buildGroundStrips(12); } createSkyGradient() { const off = document.createElement('canvas'); off.width = 2; off.height = this.height; const octx = off.getContext('2d'); const g = octx.createLinearGradient(0, 0, 0, this.height); g.addColorStop(0.0, '#0b1d3a'); g.addColorStop(0.45, '#3d6fa5'); g.addColorStop(0.55, '#d9b98c'); g.addColorStop(1.0, '#6e5340'); octx.fillStyle = g; octx.fillRect(0, 0, 2, this.height); return off; } createCloudLayer(color, alphaBias) { // 生成512x256的重复云纹 const off = document.createElement('canvas'); off.width = 512; off.height = 256; const octx = off.getContext('2d'); const seed = Math.random() * 100; for (let x = 0; x < off.width; x++) { for (let y = 0; y < off.height; y++) { // 用简单的正弦叠加模拟云朵密度 const d = 0.5 + 0.5 * Math.sin(x * 0.02 + seed) * Math.sin(y * 0.03 + seed + 1.3); const a = Math.pow(d, 2) * alphaBias; octx.fillStyle = color.replace(')', `,${a})`).replace('rgba(', 'rgba('); octx.fillRect(x, y, 1, 1); } } return off; } buildGroundStrips(count) { const strips = []; for (let i = 0; i < count; i++) { const t = i / count; const yOffset = this.horizonY + Math.pow(t, 1.8) * (this.height - this.horizonY); const stripHeight = this.height - yOffset - (strips[i - 1]?.yOffset || this.horizonY); strips.push({ yOffset, stripHeight: Math.max(stripHeight, 2), depth: 0.6 + t * 2.2 // 透视越近速度越快 }); } return strips; } render() { const ctx = this.ctx; ctx.clearRect(0, 0, this.width, this.height); // 1. 天空渐变 ctx.imageSmoothingEnabled = true; ctx.drawImage(this.skyGradient, 0, 0, this.width, this.height); // 2. 远云层 - 速度20 const farOffset = -this.offset * 0.35 % 512; ctx.drawImage(this.farCloud, farOffset, 20, 512, 220); ctx.drawImage(this.farCloud, farOffset + 512, 20, 512, 220); // 3. 近云层 - 速度80 const nearOffset = -this.offset * 1.35 % 512; ctx.drawImage(this.nearCloud, nearOffset, 40, 512, 200); ctx.drawImage(this.nearCloud, nearOffset + 512, 40, 512, 200); // 4. 地面透视条带 const baseOff = this.offset % 256; for (const s of this.groundStrips) { const off = baseOff * s.depth % 256; const texWidth = 256 * s.depth; ctx.drawImage(this.nearCloud, off - texWidth, s.yOffset, texWidth + 4, s.stripHeight); ctx.drawImage(this.nearCloud, off, s.yOffset, texWidth + 4, s.stripHeight); ctx.drawImage(this.nearCloud, off + texWidth, s.yOffset, texWidth + 4, s.stripHeight); } } loop(now) { this.update(now); this.render(); requestAnimationFrame((t) => this.loop(t)); } }

注意地面条带这里我偷懒直接用了nearCloud当纹理，实际项目里地面需要单独的草地/粒子纹理，但原理完全一样。每个条带独立计算滚动速度，视觉上就形成了近处快、远处慢的透视效果。

3.4 让"滚动"有速度感：变速与抖动注入

匀速滚动看久了会让人觉得死板，尤其是在游戏启动界面，你希望玩家一进来就感受到"这个游戏是活的"。我用两个技巧增加速度感：

第一个是变速。初始化时让targetSpeed=0，等资源加载完后逐渐加速到目标速度，模拟飞机从静止起飞的感觉。同时每隔几秒让目标速度做一次小幅波动，就像有风吹过一样。

const wave = Math.sin(now * 0.0003); scene.targetSpeed = 80 + wave * 12;

第二个是相机震动模拟。我让整体偏移在极小的范围内做高频抖动，幅度只有1-2像素，人眼不会察觉具体晃动，但会感受到一种"镜头不稳"的运动气息。这个在Canvas里直接在offset上叠加就行：

const jitter = (Math.sin(now * 0.001) + Math.cos(now * 0.0013)) * 0.8; const renderOffset = scene.offset + jitter;

最后还有个很讨巧的经验：给云层加上极其缓慢的Y轴漂移，比如远云每5秒往下移1像素，近云每3秒往上移0.5像素。这点微小的纵向移动会在玩家无意识层面增加场景的丰富度，而几乎不消耗任何性能。

4. 老手机上的性能倒逼：我实测出来的优化清单

做完功能版本之后，我第一次信心满满地拿到旧安卓机上测试，结果被狠狠打脸。帧率长期在15fps徘徊，动画肉眼可见地一卡一卡。于是开始了一轮接一轮的性能排查。这一章是真金白银的踩坑记录。

4.1 第一版为什么卡：Canvas全屏重绘的代价

第一版的卡，我一度怀疑是Canvas绘制太慢，后来用浏览器自带的性能工具跑了一遍才发现问题根本不是drawImage本身，而是整体绘制策略的错误。

首版代码我是这么写的：每一帧先clearRect清空整个画布，然后绘制天空渐变、绘制三层云、绘制12条地面纹理、再画暗角。听起来没什么问题对吧？但性能工具告诉我，卡顿主要来自三处：

• clearRect全屏清除会触发整块画布的像素清除，在低端GPU上开销不小。
• 每帧绘制渐变时都会重新创建一个LinearGradient对象，产生大量短期内存分配，触发GC。
• 近云、远云、地面条带各用不同的globalAlpha值，每切换一次alpha，Canvas底层的绘制状态都要重新切换，成本非常高。

其中globalAlpha切换的问题最隐蔽。它不像fillStyle切换那么肉眼可见，但在低端设备的Canvas 2D实现里，全局透明度状态变化往往意味着一次内部渲染管线的重新绑定。我数了一下，一帧里我切换了不下8次globalAlpha，这个开销远比想象中大。

4.2 完整排查链路：从profiler到逐行砍绘制

排查链路的顺序很重要，我建议按下面几步来，不要上来就改代码：

第一步，确认瓶颈来源。我用DevTools的Performance面板录制10秒，看Scripting、Rendering、Painting三栏谁占时间最长。我这边结果是Painting占68%，所以问题锁在绘制层。

第二步，做单层删除实验。把代码里各层注释掉，跑一遍记录帧率，再恢复一层、再记录。我用这个方法发现地面条带12次drawImage加上云层4次，总共16次drawImage，其实数量不大，但加起来的绘制面积特别大——近地处每个条带被拉伸得很宽，低端GPU的fillrate就爆了。

第三步，优化方向明确了：减少填充面积和减少状态切换。具体做法在4.3里展开。

4.3 我最终保留的优化手段清单

经过一轮轮实验，我把最终有效的手段列成清单，每个项目后面标注它带来的收益：

这里最有争议的可能是"缩小逻辑分辨率"，因为它会让文字变模糊。但我这个场景是纯背景层，没有文字，裁切后反而有一种轻微的胶片颗粒感，某些设计上还觉得更有质感。1280x720的canvas内部缩到960x540，对CPU/GPU的双重压力都降低了。

4.4 低端机的"可接受"标准：稳定比峰值重要

优化完之后，测试机帧率从15fps提升到稳定28-30fps。但这里有个很现实的认知转变：低端机上追求60fps是不现实的，设定30fps为上限反而能带来更平滑的体验。怎么做到？我主动把动画逻辑限制为"名义60Hz更新，实际合帧渲染"：

const frameBudget = 1000 / 30; let accumulator = 0; let lastFrame = performance.now(); function loop(now) { const dt = Math.min(now - lastFrame, 100); lastFrame = now; accumulator += dt; // 逻辑每帧按16.67ms累积，但渲染最高每秒30次 while (accumulator >= frameBudget) { update(16.67); accumulator -= frameBudget; } render(); requestAnimationFrame(loop); }

这样做的结果是，即使设备显示能力只有30Hz，它的update和render节奏也完全一致，不会出现一帧跳好几步的抖动。经验告诉我，稳定在28fps的所见即所得，远比爆冲到50fps又瞬间跌到20fps的"过山车"体验要舒服得多。

5. 如果再给我一次重写机会：架构上的取舍复盘

项目做完之后，我坐在电脑前复盘了很久。有些决定如果再让我选一次，我会直接换方案；有些坑虽然踩了，但也因为踩过才有了更清晰的判断标准。

5.1 这次为什么不直接上WebGL

我承认WebGL在三维渲染上确实更强，但在"滚动天空"这个具体需求上，Canvas 2D反而是更冷静的选择。WebGL要处理顶点缓冲、着色器编译、纹理上传、上下文丢失恢复，任何一个环节出了问题，调试成本都是按小时计算的。而且低端安卓机的WebGL实现并不统一，有的设备连标准浮点数精度都达不到要求。

真正的决定因素还是资源加载体积。我用Canvas 2D+三张PNG，总共不到200KB。上Three.js哪怕是最简版本，也要额外引入几百KB的脚本和编译时间。对一个只出现5秒钟的启动场景来说，这个代价不值得。

但如果需求变成长达数分钟的游戏关卡，或者需要相机转向、地形起伏，那我一定会切回WebGL。Canvas 2D在这个场景的优势体现在"简单且够用"，一旦需求复杂度超过"前景+背景平移"，它的实现成本会直线上升。

5.2 如果需求再加码：哪些地方可以渐进增强

这次"超低配版"最让我满意的部分是它的降级设计——它不是一条路走到黑的，而是一个可以向上渐进增强的地基。如果以后同类项目允许中等配置，我会按这个顺序逐步加东西：

第一步，加动态光斑。在云层上方叠加一个缓慢移动的径向渐变光斑，模拟太阳从云后透出的感觉。这个Canvas 2D就能做，成本只有一次drawImage。

第二步，用离屏Canvas渲染动态地形条带，而不是直接用静态纹理。让地面条带每隔一段时间重绘一次，加入颜色随高度变化，形成类似丘陵的感觉。这时仍然不涉及逐像素逻辑。

第三步，如果设备支持WebGL并且硬件性能足够，可以在Canvas 2D的滚动背景上叠加一层Three.js的场景，只对前景模型做3D渲染，背景继续用2D滚动层。这种混合架构兼顾了视觉层次和性能区间。

5.3 个人复盘：超低配的真正价值是倒逼你理解视觉本质

这次项目最大的收获，不是学会了Canvas 2D的多少个API，而是被性能逼着去拆解"什么是3D感"这件事。当我不能依赖GPU、不能依赖三维数学的时候，我才真正理解了视差、透视、深度暗示这些底层原理——它们才是玩家感受到"立体"的根源，而不是那些华丽的技术名词。

以后再看到有人给轻量页面直接上重型引擎，我都会劝一句：先想想玩家的设备能不能扛住。一次性能事故的教训，比十篇渲染原理文章都来得深刻。我也建议你手头如果有类似"看着挺简单但就是卡"的小动画，试着用我这个思路重新拆一遍——把层拆开、把速度差拉出来、把绘制次数数清楚，往往问题就迎刃而解了。