Three.js 场景加载时，为什么连 Loading 都会卡？一次 3D 钓场的首帧优化

最近在做一个电脑端三维垂钓网站「闲钓小栈」。进入钓场时要准备岸边地形、树木、人物、水面反射和阴影。开发时遇到一个问题加载提示已经出现画面还是会停一下。资源下载结束后也不一定能马上进入场景。这次我主要处理的是首次进入场景时CPU 计算、纹理上传和着色器编译集中执行的问题。做法是把准备过程拆开让浏览器在部分工作之间有机会更新界面并提前处理当前场景需要的渲染程序。项目使用 TypeScript 和 Three.js本文对应的 Three.js 版本是0.186.1。一、资源下载完成还不是首帧准备完成我把进入钓场的工作拆成了几部分阶段实际工作资源读取下载模型和贴图解析模型数据CPU 准备计算地形高度、坡度、顶点颜色整理场景物件纹理初始化把贴图准备并上传给 GPU程序准备编译、链接当前材质和渲染路径需要的着色器实际绘制使用正式相机绘制主场景、水面反射及阴影有些资源请求可以和地形计算重叠进行但主线程上的大循环不会因为外面包了一个async函数就自动并行。如果大量工作一直占着主线程页面上的等待动画、按钮和文字更新也会受到影响。只增加一个旋转图标解决不了这些初始化开销。二、先把地形计算拆成短一些的片段场景里同一个地形高度函数同时用于渲染和人物站位。生成网格时每个顶点还会计算坡度和颜色连续执行会占用不少时间。我的实现每处理 256 个顶点检查一次耗时超过约 8ms 就暂停当前计算等待下一次动画帧回调。下面只保留高度更新部分import*asTHREEfromthree;constnextFrame()newPromisevoid(resolverequestAnimationFrame(()resolve()));asyncfunctionprepareHeights(geometry:THREE.PlaneGeometry,heightAt:(x:number,z:number)number,cancelled:()boolean,){constpositionsgeometry.attributes.position;letstartedAtperformance.now();for(leti0;ipositions.count;i){if(i%2560performance.now()-startedAt8){awaitnextFrame();if(cancelled())returnfalse;startedAtperformance.now();}positions.setY(i,heightAt(positions.getX(i),positions.getZ(i)));}if(cancelled())returnfalse;positions.needsUpdatetrue;geometry.computeVertexNormals();returntrue;}这里的 8ms 是软预算。检查之间的计算、单次高度采样以及最后的法线计算都可能超出它不能据此声称所有任务都小于 8ms。requestAnimationFrame的回调发生在下一次重绘之前。这里用它把计算分散到不同的帧调度周期不把它当作“这一帧已经显示到屏幕”的证明后台标签页还可能暂停这类回调。requestAnimationFrame 的调度说明这一步仍然使用主线程。如果后续测量发现地形计算持续占主导再评估 Worker 和数据传输成本不能把分片描述成已经完成了多线程计算。三、把首次纹理初始化分散开另一个集中开销来自贴图图片文件已经读取完成也不代表 GPU 侧的纹理已经准备好。我先遍历当前场景收集材质上的纹理引用用Set去重然后逐个初始化中间让出执行机会asyncfunctionuploadTextures(renderer:THREE.WebGLRenderer,textures:IterableTHREE.Texture,cancelled:()boolean,){for(consttextureofnewSet(textures)){if(cancelled())returnfalse;renderer.initTexture(texture);awaitnextFrame();}return!cancelled();}initTexture是 Three.js 提供的公开接口可以提前初始化纹理减少第一次渲染时才集中处理图片解码和上传的开销。Three.js 纹理初始化说明项目收集的是普通材质直接引用的贴图以及ShaderMaterial中直接作为 uniform 值的纹理。纹理数组等其他结构需要按实际材质另外补充收集规则。这段代码也没有让单张纹理上传变成异步任务。如果某一张图片本身就很大单次调用仍可能阻塞需要继续检查尺寸、格式和解码成本。四、着色器预热要考虑实际渲染路径把纹理上传移开之后还需要处理第一次使用材质时的程序编译。我用renderer.compileAsync(scene, camera)预先准备程序。它利用KHR_parallel_shader_compile扩展提供的能力等待编译状态调用前场景里的灯光、环境和材质要先配置好。Three.js 着色器预编译说明这个扩展主要帮助避免阻塞式查询编译完成状态不意味着编译总耗时消失也不能保证所有浏览器、驱动和调用阶段都完全不阻塞。KHR_parallel_shader_compile 扩展说明闲钓场景里比较容易漏掉的是主画面、水面反射和阴影并不完全走同一条材质程序路径。我的主画面输出到 Canvas水面反射使用离屏渲染目标。核对当前 Three.js 源码后可以看到输出环境参与程序参数选择。因此我在主场景预编译后还切换到一个小的离屏目标准备对应的线性输出路径asyncfunctioncompileMainAndOffscreen(renderer:THREE.WebGLRenderer,scene:THREE.Scene,camera:THREE.Camera,cancelled:()boolean,){if(cancelled())returnfalse;awaitrenderer.compileAsync(scene,camera);if(cancelled())returnfalse;constpreviousrenderer.getRenderTarget();constwarmTargetnewTHREE.WebGLRenderTarget(1,1);try{renderer.setRenderTarget(warmTarget);awaitrenderer.compileAsync(scene,camera);return!cancelled();}finally{renderer.setRenderTarget(previous);warmTarget.dispose();}}这里的 1×1 目标用于切换当前项目所需的编译环境没有绘制一张完整反射图也没有让正式反射的运行开销变成一个像素。它同样不是所有离屏配置都适用的通用预热方案。阴影还需要另外考虑。树叶这类带透明裁切的材质如果深度路径没有沿用贴图、裁切阈值和正确的面方向阴影程序就可能与主材质不同。当前实现会为相关投影物件建立临时的深度材质代理沿用map、alphaMap、alphaTest、面方向和位移等参数再进行深度路径预编译。临时材质保持引用等第一次正式阴影绘制之后再释放。这部分针对的是项目当前使用的阴影和材质。以后增加点光源、定制深度材质、不同反射相机或后处理还要重新检查首次使用的路径不能认为调用过一次compileAsync就预热了所有可能性。五、准备期间正常渲染循环也要等一等如果一边分片准备场景一边让正常循环持续绘制尚未准备完成的物件第一次渲染仍可能提前触发纹理上传和着色器编译。所以世界运行器里有一个preparing状态。准备期间先不进入正常场景更新与渲染显示已有封面和 DOM/CSS 入场动画模型、地形和材质准备完成后再用正式相机实际绘制。当前进入流程可以概括为先显示入场界面 ↓ 启动资源读取并分片计算地形 ↓ 组装人物、植被、装备和水面 ↓ 逐步初始化纹理预编译当前渲染路径 ↓ 使用正式相机实际绘制检查上下文状态 ↓ 结束准备恢复正常循环和操作资源加载失败或 WebGL 上下文丢失就进入失败和重试流程。用户退出等待时异步步骤通过disposed检查停止继续使用已销毁的世界临时渲染目标和材质仍要释放。这里的“准备好”是应用完成了预定准备并走过实际绘制路径不是浏览器提供的“所有 GPU 工作都结束、画面已经呈现”的同步保证。六、看长任务也保留没有解决完的问题检查时我同时看入场动画是否仍有变化、资源失败能否重试以及主线程的长任务。在支持 Long Tasks API 的浏览器里可以用下面的方式记录任务时长constdurations:number[][];if(PerformanceObserver.supportedEntryTypes.includes(longtask)){constobservernewPerformanceObserver(list{for(constentryoflist.getEntries())durations.push(entry.duration);});observer.observe({type:longtask,buffered:false});// 采样结束后调用 observer.disconnect()。}Long Tasks API 记录的是占用 UI 线程约 50ms 及以上的任务不是 GPU 耗时也不能单靠这个数字判断稳定帧率。Long Tasks API 说明项目保留的一次开发检查使用 Mac Chrome、1440×960 视口和 4 倍 CPU 放慢。该次检查主动延迟了 GLB 资源用来验证等待中的动画和准备条件记录中的最大主线程长任务仍有616ms。这个结果说明初始化仍有集中开销不能写成“加载已经完全不卡”。同样人为延迟资源后的总等待时间也不能当成自然网络下的场景加载速度。后续还需要按 Performance 记录继续定位剩余任务并在目标设备验证。当前开发机是 Apple M5 Pro不能用它代替普通集显电脑的首次加载和运行测试。这次实际做的是把首次准备整理成可调度、可取消、能失败恢复的流程。对我来说后面再增加场景、贴图或新效果时也更容易知道该在哪个阶段继续排查。这套实现用在我开发的闲钓小栈中目前是电脑端单人三维垂钓与学习预览。体验地址闲钓小栈。