在移动端跑 three.js和 PC 上是完全两种体验。PC 上你可能费半天劲调好的场景拿到手机上一打开要么卡成幻灯片要么直接闪退。我之前接手过一个 Vue3 three.js TypeScript 的机房可视化项目PC 端跑得飞起结果换到安卓中端机上转几圈就掉到十几帧内存直接飙到 300 多 MB后台一会儿就被系统杀了。后来一点点排查才发现问题几乎全出在移动端适配的细节上。这期就专门讲讲 three.js 移动端适配需要注意的事项。内容围绕实际操作展开不废话原理重点讲清楚哪些配置必须改、哪些坑必须避以及背后为什么要这么做。适合正在做 WebGL 三维可视化、想兼容手机浏览器的前端同学参考。1. 移动端适配的核心矛盾性能预算是有限的很多人做移动端适配第一反应是把 canvas 弄小一点就行。这是最常见的误区。移动端和 PC 端的差异不是窗口大小的问题而是整套硬件能力和交互方式都完全不同。移动端 GPU 和 PC GPU 的性能差距比你想象的大得多。桌面显卡的填充率fill rate可能是手机 GPU 的十几倍。填充率通俗讲就是 GPU 每秒能往屏幕上画多少像素。你场景里哪怕只有一个全屏的渐变背景加上复杂的模型和粒子移动端 GPU 就可能处理不过来。另外移动端 GPU 往往和 CPU 共享内存带宽。模型、纹理的显存占用一旦上去不光渲染变慢连系统的其他应用都会跟着卡。iOS 和安卓的高端机还好中低端机尤其明显。所以做移动端适配第一原则不是视觉效果最大化而是在有限预算内做到可接受的观感。预算到底怎么定我一般这样锚定指标PC 端可接受值移动端常见瓶颈帧率目标60 FPS30 FPS 可接受60 FPS 最优draw call1000 - 2000300 - 500 以内最佳顶点总数数百万级尽量不超过 30 - 50 万纹理总量1G 显存随便造控制在 200 - 300 MB 内后处理链路Bloom SSAO 景深最多保留一个轻量后处理所谓适配就是在这些指标上做取舍。记住移动端用户不会因为你的场景少一个 Bloom 特效就骂你但一定会因为打开就卡、发热、闪退而流失。2. 像素比DPR处理移动端最关键的参数2.1 为什么不直接用 window.devicePixelRatio这是移动端适配第一坑。iPhone 的 DPR 是 3很多安卓旗舰是 2.75 或 3。如果你写renderer.setPixelRatio(window.devicePixelRatio);那么渲染分辨率就是 CSS 分辨率的 9 倍3×3。一个在 PC 上 1920×1080 的 canvas到了 iPhone 上就变成一堆 2000×3000 以上的像素意味着 GPU 的填充压力直接是 PC 初始画面的好几倍。所以常规做法是加一个 caprenderer.setPixelRatio(Math.min(window.devicePixelRatio, 2));限制到 2 的原因很简单DPR 2 和 DPR 3 在手机屏幕上的观感差异绝大多数人肉眼几乎看不出来但像素量差了 2.25 倍。把 DPR 控到 2等于省掉了 55% 以上的填充率压力。我用这个配置在国产中端机上实测场景帧率能从 18 FPS 提到 35 FPS 左右。2.2 内置渲染分辨率调节有些场景即使是 DPR 2 也扛不住。比如白天的户外场景阳光直射屏幕上用户可能看不太清细节这时没必要以 2 倍分辨率渲染。可以做一个画质档位let QUALITY_LEVEL 2; // 1 低, 2 中, 3 高 function updatePixelRatio() { const dpr window.devicePixelRatio || 1; const capped Math.min(dpr, QUALITY_LEVEL); renderer.setPixelRatio(capped); }结合一个简易帧率监控如果发现连续 3 秒平均帧率低于 24自动把 QUALITY_LEVEL 降到 1.5。降到 1.5 以后画面的锯齿会明显一些但比卡死强太多。2.3 留意 resize 时机移动端比 PC 多一个麻烦浏览器地址栏收起、弹窗拉起都会触发 resize。如果你在 resize 里重建相机或重新加载资源页面会一顿一顿的。稳妥的做法是加一个 debouncelet resizeTimer; window.addEventListener(resize, () { clearTimeout(resizeTimer); resizeTimer setTimeout(onResize, 200); }); function onResize() { camera.aspect window.innerWidth / window.innerHeight; camera.updateProjectionMatrix(); renderer.setSize(window.innerWidth, window.innerHeight); renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2)); }注意手机横竖屏切换时会触发两次 resizedebounce 既能防抖动又不会漏掉方向变化。3. 纹理与内存控制移动端最现实的生死线3.1 纹理尺寸不是越大越好PC 上 4096×4096 的纹理满大街都是但移动端很多中端 GPU 的最大纹理尺寸只有 4096部分老机型更是只有 2048。超出上限的纹理浏览器会直接不显示或者花屏。我在做雨雪雾场景时把雪花的 sprite 纹理从 1024 改成 256肉眼完全无感但粒子系统显存占用直接降到了原来的 1/16。涉及大量粒子时尤其明显。纹理压缩格式里iOS 上用 PVRTC、安卓上普遍支持 ETC2 / ASTC。three.js 加载 .ktx2 格式的压缩纹理可以显著降低显存占用。如果你项目里纹理多建议走一下压缩流程。3.2 纹理命名空间管理还有一个容易被忽视的问题重复加载纹理导致内存翻倍。尤其是 Vue3 three.js 这种 SPA 场景组件卸载再挂载时同样的纹理又 load 了一遍。实际项目里我用一个专门的纹理管理模块做共享缓存核心逻辑类似const textureCache new Map(); function getSharedTexture(url, loader) { if (textureCache.has(url)) { return textureCache.get(url); } const texture loader.load(url); textureCache.set(url, texture); return texture; }这正好对应了three.js 共享 序列化这个方向场景切换时有条件的话用 Worker 来加载并传输纹理。Worker 里解码图片后通过 ArrayBuffer 传输到主线程再创建 Texture主线程不会因图片解码而掉帧。数据在 Worker 和主线程之间可以用 Transferable 转移所有权避免结构化克隆的大拷贝开销。3.3 纹理的 mipmap 和采样细节移动端 GPU 对 mipmap 的依赖比 PC 大。因为屏幕小远处物体很容易产生闪烁和摩尔纹。大部分情况下保持默认生成 mipmap 即可但有一点要留意动态纹理比如视频纹理不要开 mipmap否则每次更新纹理都要重新生成 mipmap开销巨大。各向异性过滤anisotropy在移动端要谨慎高倍率在部分 GPU 上会导致明显的性能下降。一般设 4 就够用了texture.anisotropy 4;想进一步压显存可以把 RGB 纹理的 encoding 设为 sRGB既能省带宽颜色也更接近真实设备效果。4. 几何体与模型适配顶点越多死得越快4.1 顶点数量的实际控制线移动端的顶点处理和内存带宽直接相关。一个常见的坑是从建模软件导出模型时没做减面一个场景几十万个三角形PC 上没问题手机一进去明显卡。我习惯在建模阶段就定好规范角色类模型单个 5 万面内场景建筑 20 万面内。导出时通过 Draco 压缩three.js 加载时解压。这种方法对静态模型效果非常好加载体积可以压到原来的 1/10代价是加载时有几毫秒的解压时间但手机完全扛得住。4.2 用实例化网格InstancedMesh替代重复物体机房项目里一排排服务器机柜、指示灯、传感器点位这种重复物体如果用独立 Mesh 放draw call 数量会爆炸。改成 InstancedMesh一次 draw call 渲染所有实例性能是质变。const geometry new THREE.BoxGeometry(0.8, 2, 1); const material new THREE.MeshStandardMaterial({ color: 0x3a7bd5 }); const mesh new THREE.InstancedMesh(geometry, material, 200); // 设置每个实例的矩阵 for (let i 0; i 200; i) { const matrix new THREE.Matrix4(); matrix.setPosition(x, y, z); mesh.setMatrixAt(i, matrix); } scene.add(mesh);共享几何体、共享材质、实例化渲染这三板斧能让 draw call 从 1000 直接压到 100 以内。实测在安卓中端机上draw call 从 800 降到 120 之后帧率从 22 FPS 提升到 45 FPS 左右。4.3 骨骼动画和粒子系统的取舍骨骼动画在移动端是个大开销。每个骨骼每帧都要更新矩阵顶点数量大时骨骼变换的 shader 计算量会直接拖垮帧率。能用顶点动画比如简单的飘动、闪烁就尽量别上骨骼能预烘焙动画纹理也优先采用。粒子系统方面雨雪雾这些场景粒子数量控制在 2000 - 3000 以内是安全的。用 Points 自定义 Shader 比创建几千个 Sprite 高效得多。实现雾效果时可以只对远处物体做一个透明的平面配合场景的 fog 参数观感不比粒子雾差多少。5. 渲染器配置与后处理取舍5.1 抗锯齿要分平台处理PC 上 MSAA 4x 很常见但移动端很多浏览器对 MSAA 不支持或者实现很粗糙。拿WebGLRenderer创建时的antialias: true来说它在不少安卓机型上反而会导致更明显的性能下降。我的做法是默认不开渲染器的 antialias改用分辨率 后期 FXAA组合拳。FXAA 开销很小画面柔滑效果在手机上看完全够用。关键代码let renderer; try { renderer new THREE.WebGLRenderer({ antialias: false, powerPreference: high-performance }); } catch (e) { // 降级处理 renderer new THREE.WebGLRenderer({ antialias: false }); }powerPreference: high-performance在部分机型上会尝试调起独立 GPU对帧率有帮助。5.2 阴影和后处理移动端的头号性能杀手PC 上随便开 PCFSoftShadowMap两个 2048 的 shadow map再加 Bloom、SSAO都没啥感觉。移动端这么配基本等于自杀。shadow map 的尺寸直接决定 GPU 开销2048 的 shadow map 在手机上要占掉大量带宽。我做过实测PC 上开 4K shadow map帧率几乎不变手机上 2048 的 shadow map 就能让帧率降 30%。所以移动端我一般把 shadow map 控制在 1024使用 PCF 基本阴影不追求 PCFSoft。后处理链路如果实在需要 Bloom用最简单的 UnrealBloomPass并调整参数让采样次数少一些。SSAO、反射、景深这类重后处理移动端强烈不建议开。5.3 CubeCamera 在移动端的替代方案做镜面反射或者正方体摄像机效果CubeCamera 实时环境映射是 PC 端的常规操作但移动端每帧渲染 6 个面到 cube render target开销太大。替代思路有两个单面反射用平面反射THREE.Plane或反射探针替代六面渲染视觉差异在平整地面上几乎看不出来。预烘焙环境贴图如果场景是静态的先把环境贴图烘焙成 PMREM加载时直接作为场景的 envMap。这样实时开销几乎为零观感还更稳定。6. 触摸交互与移动端特有的交互适配6.1 Raycaster 用在哪是性能分水岭PC 端所有 Mesh 都用 raycaster 检测点击每帧开着 mousemove 监听看起来没问题。移动端这种做法会让 CPU 满载。移动端 Raycaster 的优化点只在touchstart/touchend时做检测不要在每个touchmove都检测检测前先做包围盒粗筛避免直接对几十万面的模型精细判定能被射线穿过的物体尽量给它提供一个简单的 hitbox 几何体用于点击判定。6.2 touch-action这个 CSS 属性经常被忽略在移动端做 3D 交互时你会发现页面莫名其妙地滚动、缩放。这通常是 canvas 的默认触摸行为没有处理。最直接的方式#webgl-canvas { touch-action: none; }加上这行浏览器不会拦截你的触摸手势touchmove事件才能连续响应。如果你的需求是场景可缩放 页面可滚动那需要更精细的手势判断比如检测到单个手指时允许滚动两个手指时进入 3D 场景缩放。这个用原生 touch 事件自己做判断即可尽量不引额外手势库。6.3 点击穿透与全屏切换移动端还有一个老问题点击 canvas 里的 3D 物体时偶尔会触发页面其他元素的点击。这与 touch 事件的触发机制有关解决方案是在触摸结束时调用event.preventDefault()并确保 canvas 的z-index层级正确。横竖屏切换或全屏展示时orientationchange事件后需要重新读取宽高并更新渲染器。我之前遇到过一个 BugiPhone 上旋转屏幕后画面被拉伸排查发现是 resize 事件里用的是旧的宽高值改成在orientationchange里重新读取window.innerWidth/window.innerHeight并恢复相机比例就好了。7. 实战中积累的常见问题排查记录7.1 谷歌网页有 three.js 就卡卡的十有八九是这三个原因很多用户反馈 Chrome 打开 three.js 页面卡顿。大多数情况可以用三个方向定位现象根因方向转动视角卡、掉帧明显未限制 DPR、物体过多、阴影开太大先降 DPR 到 2再减粒子、关阴影GPU 占用高、发烫后处理链路过多/复渲染特效减少后处理 pass去掉 SSAO/Bloom 之一页面加载慢、内存大纹理太大、未压缩模型纹理压缩、Draco 压缩模型、懒加载场景还有个细节Chrome 的移动端 GPU 进程不稳定。做 demo 时记得在地址栏开chrome://gpu确认 WebGL 是否启用硬件加速。有的手机浏览器默认关闭了硬件加速three.js 会直接掉到软件渲染那画面帧率约等于 PPT。7.2 场景里模型显示黑色或花屏通常原因是纹理超过设备最大尺寸或者 shader 里用了移动端不支持的精度。排查方法是打开 WebGL 的报错输出在创建 renderer 后挂上const gl renderer.getContext(); // 打印设备相关能力 console.log({ maxTextureSize: gl.getParameter(gl.MAX_TEXTURE_SIZE), maxCubemapSize: gl.getParameter(gl.MAX_CUBE_MAP_TEXTURE_SIZE), antialias: gl.getContextAttributes().antialias, precision: gl.getShaderPrecisionFormat(gl.FRAGMENT_SHADER, gl.HIGH_FLOAT), });同时检查 fragment shader 里的 float 精度。移动端部分 GPU 对highp支持不佳必要时在材质中加入precision highp float;无效的话降级到mediump。7.3 内存暴增导致浏览器崩溃移动端浏览器对页面内存是有硬性限制的iOS Safari 尤其严苛某个版本下单个页面内存超过 1G 就强杀。纹理泄漏是最常见元凶。注意texture.dispose()、geometry.dispose()、material.dispose()这三件套尤其在使用 Vue3 组件销毁时别忘了在beforeUnmount里清资源。我做机房项目时写了一个简单的资源统计工具每 30 秒输出一次内存占用和 draw call 数function logMemory() { const mem performance.memory ? performance.memory.usedJSHeapSize / 1024 / 1024 : N/A; console.log(JS 内存: ${mem} MB, draw call 近似: ${renderer.info.render.calls}); }实际跑下来纹理共享处理前是 380 MB处理后 180 MB。对移动端来说这个差距就是能不能活下来的差距。7.4 热降频性能调试时最隐蔽的敌人手机在性能测试时有个和 PC 完全不同的干扰因素发热降频。场景跑 2 分钟可能还是 60 FPS跑到 5 分钟过热直接掉到 20 FPS。调试时要区分是场景问题还是降频问题。我建议在连续跑 5 分钟后再测一轮帧率如果掉帧严重但 CPU/GPU 占用并不高大概率是设备降频。这种情况下优先优化 GPU 负载减少像素填充率、降低 DPR而不是继续堆代码。8. 实操总结移动端适配的检查清单以我现在做项目的习惯移动端适配不是最后补的而是从一开始就按这个检查清单走[ ] DPR 限制到 2 或按画质档位动态调整[ ] 使用纹理压缩格式KTX2 / ETC2 / ASTC纹理尺寸控制在 2048 以内[ ] 模型经 Draco 压缩单场景顶点尽量低于 50 万[ ] 重复物体全部使用 InstancedMesh 合并渲染[ ] shadow map 不超过 1024后处理 pass 不超过 1 个[ ] 关闭或调低抗锯齿用 FXAA 替代[ ] raycaster 只在触摸结束时判定并做粗筛[ ] canvas 设置touch-action: none[ ] SPA 卸载组件时统一 dispose 几何体、材质、纹理[ ] 真机跑 5 分钟以上确认无发热降频导致的严重掉帧这套清单不复杂但能挡住 90% 的移动端性能事故。最后说点个人实际操作中的体会。three.js 移动端适配这件事本质不是把代码改小而是换一种资源分配思路。PC 上你用性能换画面移动端你要用画面换稳定。最核心的一招永远是最简单的那招把像素总量降下来其次是纹理内存最后才是算法层面的优化。很多项目卡死根本不是算法问题就是像素总和和显存总和超了设备的物理极限。如果你正在做 three.js 移动端项目我建议先从 DPR 和纹理压缩入手改大多数情况下这两个地方的收益立竿见影。搞完以后再去看 draw call 和阴影会轻松很多。