近两年做数据可视化大家的目光基本都聚焦在 2D 的大屏和后台管理上3D 图表一直是个不太敢碰的领域。原因也很直白3D 渲染天然依赖 WebGL性能瓶颈明显尤其是在移动端GPU 能力和内存都远不如桌面端动不动就掉帧、发热用户体感非常糟糕。但我们今年接了一个比较特殊的项目核心诉求就是在移动端做一套完整的 3D 图表可视化而且要求从交互到性能都达到可商用级别。这不仅仅是“把图表从 2D 换成 3D”那么简单而是要把整个渲染链路、交互模型和性能策略都重新考虑一遍。这就是 raychart 这个项目的由来。这篇文章不打算讲太多虚的直接把我从设计、开发到调优的全过程拆开聊聊我在 Vue 生态里做 3D 图表时踩过的坑、做过的取舍以及为什么最终的性能提升如此明显。无论你是在评估自研 3D 可视化方案还是已经准备动手这篇内容都应该能给你一些参考。raychart 定位是一套基于 Vue 3 的 3D 图表组件库最开始的适用场景是移动端数据报告。我当时给自己定的目标是在 2020 年中低端 Android 手机上也要能跑出 30fps 以上的稳定帧率。这个目标的难度在于3D 图表的每一帧都在变化实时旋转、缩放、点击高亮这些交互如果处理不好很容易让 WebGL 渲染变成一场灾难。下面我会从整体架构、渲染方案选型、交互模型、性能优化和问题排查这几个维度逐层展开把这次系统升级的核心技术点和决策逻辑讲透。1. 这次升级到底要解决什么问题移动端 3D 图表的三个硬门槛在 raychart 立项之前我们团队并不是没有尝试过直接用市面上的 3D 图表库。但测试了一轮之后发现它们的侧重点大多在桌面端移动端体验基本属于“能跑但没优化”的状态。项目要做移动端优先就必须直面三个硬门槛。1.1 问题一3D 渲染在移动端面临“算力赤字”很多开发者会把 3D 图表和普通 3D 游戏画等号觉得移动端的 GPU 足够应付图表这种简单几何体。但实际上图表渲染的瓶颈不在几何复杂度而在绘制调度的开销。一个包含几千根柱子的柱状图每一根都是独立网格体如果分多次 draw call 提交CPU 端就要为每一个网格体做一次状态切换、矩阵运算和 Uniform 更新。移动端 GPU 对这种高频小批量提交尤其敏感帧耗时会被拉得非常高。我在测试阶段用一个很常规的 3D 柱状图做过对比5000 根柱子桌面端 GPU 毫无压力但在一台仅支持 OpenGL ES 3.0 的中端 Android 手机上帧率直接掉到 15fps 以下。这个结果让我意识到raychart 的核心工作之一就是要把绘制开销压下去尽可能把所有柱体合并成少量批次提交。1.2 问题二移动端交互模型与桌面端完全不同桌面端的 3D 图表交互主要依赖鼠标拖拽旋转、滚轮缩放精度高且连续性好。但移动端是触摸操作单指旋转、双指缩放、点击高亮这些手势不仅要被准确识别还要处理手指遮挡、滑动摩擦带来的误触问题。更重要的是移动端屏幕小一个 3D 场景里如果堆了太多信息用户根本看不清交互反馈如果不及时就会感觉“卡”或“迟钝”。有个细节特别明显桌面端的惯性旋转是很自然的加分项但移动端如果惯性计算做得不好画面会像“甩尾”一样反而让用户觉得失控。所以 raychart 在交互层没有直接复用桌面端那套鼠标事件 手动计算旋转角的逻辑而是重新实现了基于双指和单指的独立手势解析器。后面我会专门拆这一块。1.3 问题三性能优化的系统性要求远超 2D 图表2D 图表性能优化无外乎 Canvas 重绘优化、数据降采样、DOM 复用这些手段。但 3D 图表性能优化牵涉面太广场景图的组织方式直接影响剔除效率、材质和纹理的管理直接影响显存占用、渲染循环的调度直接影响 CPU 占用和发热。任何一个环节掉链子都是全局性的帧率崩塌。为了把性能做到可控我在架构上放弃了传统的 DOM 事件监听方案整个图表渲染区域只保留一个 Canvas 元素。所有交互传递、组件通信都走内部的消息总线。这个决定带了一个额外的好处绘制层和业务层完全解耦后续做服务端渲染或 Web Worker 预计算都方便很多。说白了这次系统升级不是给 raychart 打补丁而是彻底换了一个设计思路。2. 渲染方案选型与核心架构解析为什么选 Three.js 而不是纯原生 WebGL在 raychart 启动设计时渲染层的技术选型是我最先决定的事情。当时有两条路摆在我面前直接用原生 WebGL 写底层渲染或者基于 Three.js 这类上层库做封装。我最后选了 Three.js但并不是因为它复杂或高大上而是因为它帮我把底层最麻烦的矩阵运算、视锥体剔除、着色器编译管理都处理掉了。2.1 技术栈选型的基本逻辑原生 WebGL 的优势是灵活性和极致性能如果你的图表只需要渲染一种固定的图元原生方案确实可行。但 raychart 要支持柱状图、折线图、散点图、饼图、热力网格等多种图型每种图型的几何生成逻辑和渲染管线都不同如果用原生 WebGL这些工作全部要自己写。我算过账光是一个带法线计算和索引缓冲生成的圆柱体几何体就要几十行代码而且还要考虑 Buffer 更新时机、上下文丢失恢复等一堆 edge case。Three.js 提供了成熟的几何体抽象、材质系统和 Scene/Graph 管理我可以把精力放在图表的布局计算和交互逻辑上。另一个决定性因素是 TypeScript 支持。Three.js 的类型定义非常完整尤其是 Object3D、BufferGeometry、Material 这些核心类。raychart 本身打算对外作为组件库发布类型定义直接决定使用者的开发体验。与其自己写一层弱类型的 WebGL 封装不如站在 Three.js 的基础上对外暴露类型完备的 Vue 组件接口。2.2 场景图设计与组件分层raychart 的架构我参考了游戏引擎的做法分为四个层次RayChartRoot最外层组件持有渲染器、场景、相机和控制器实例是所有图表的容器。RayScene负责创建场景图管理光源、雾效、地面网格等环境对象。RaySeries数据系列组件内部根据图表类型生成对应的网格体并把数据变化映射到几何体的位置、颜色和旋转属性。RayInteraction交互控制器处理手势解析、射线检测、高亮和联动。这个分层带来的最大好处是组件复用。比如你创建了一个柱状图然后想叠加一条折线只需要在RayChartRoot里嵌套两个RaySeries组件。为了做到这一点我利用 Vue 3 的provide/inject机制把场景、相机、渲染循环全部注册到根组件上。子组件在挂载时从依赖注入中拿渲染器引用向场景中添加网格体卸载时自动从场景移除并释放显存对象。实际编码中最怕是子组件更新数据时误触发了整个场景的重建。我在设计时给RaySeries加了一个明确的约束数据变化只能走几何体的 Buffer 更新路径不允许销毁网格体再重新创建。这个约束在实现层面其实就是一行判断如果图标类型没有变化就复用已有 mesh只更新 geometry 的 attribute。2.3 移动端渲染环境的适配细节选 Three.js 只是完成了一半移动端的适配还有一堆容易被忽视的细节。首先是 DPRDevice Pixel Ratio的限制。默认情况下Three.js 的渲染器会读取window.devicePixelRatio作为渲染分辨率倍数这在桌面端是合理的但移动端 3 倍 DPR 意味着渲染分辨率是 CSS 像素的 9 倍绘制像素数飙升GPU 压力直接爆表。raychart 在创建渲染器时就把 DPR 上限压到 1.5并且只对高分辨率设备提高一档。这个数值是我在真机上反复试出来的保证文字和线条清晰的同时把 fill-rate 控制在移动端可接受的范围内。还有一个是像素比和 CSS 尺寸的计算时机。移动端的长宽比经常变化横竖屏旋转或者浏览器工具栏的显示隐藏都会导致容器尺寸变化如果没有监听 ResizeObserver画面很可能会被拉伸变形。我在RayChartRoot中注册了一个ResizeObserver在回调里同时更新相机的 aspect 和渲染器的 size并且把更新逻辑放进requestAnimationFrame队列避免频繁同步操作。3. 数据驱动的图表生成与交互模型重塑架构定了之后最难的部分就是数据到视觉的映射以及移动端交互模型的设计。这一节我会具体说说是怎么把一组 JSON 数据变成 3D 网格体又是怎么在移动端实现丝滑的旋转和缩放体验的。3.1 从数据到几何体BufferGeometry 的高效构建图表组件接收到的数据通常是一个数组比如柱状图的输入是[{ name: 华东, value: 320 }, { name: 华南, value: 280 }]。如果每一条数据都单独创建几何体那 CPU 和 GPU 的通信压力会非常大尤其是数据量上千时会触发频繁的缓冲区更新。raychart 采取的策略是“数据聚合、几何合并”把同一系列的所有柱子合并进同一个BufferGeometry每根柱子的位置、颜色、尺寸全部编码进 attributes 中。这样做的代价是需要在着色器层面处理每一根柱子的变换。我的做法是为每根柱子生成一个四维向量中心 x、中心 z、高度、宽度存进一个自定义 attribute 里。顶点着色器用这个向量动态计算柱子的四个顶点的位置再乘上模型矩阵。这就让所有柱子只需要一次 draw call性能提升非常明显。折线图和散点图就更容易处理了。折线图的所有顶点直接写入一个positionattribute索引数组描述线段连接方式散点图则用Points材质配合一个自定义圆点着色器。这些都是 Three.js 的成熟能力但需要你对 Buffer 的布局足够熟悉。实践中最容易出错的地方是 attribute 的类型选择。位置和颜色最好都用Float32Arraynormalized参数要按需设置。颜色用normalized: true可以让 GPU 自动把 0-255 的整数转成 0-1 的浮点可以节省不少 CPU 运算。3.2 柱状图、折线图、散点图的场景搭建细节可能有人会觉得 3D 柱状图就是把 2D 柱状图的柱子拉高再换个颜色就完了实际上里面的细节很多。柱状图的地面必须有一个网格参考系否则用户没有空间纵深感柱子显得像悬浮的色块。网格线的设计要克制一格一线颜色要淡透明度控制在 0.15 左右。柱子底部的圆角是另一个细节。在 3D 场景里如果柱子完全是直角棱柱光照一打就会出现明显的硬边视觉上很生硬。我在生成柱状几何体时给柱子的每个边缘添加了倒角成本是每个柱子多了几十个三角形换来的是整个画面精致度上了一个台阶。放射坐标系是另一个挑战。如果把每个扇区当成独立 mesh很容易出现接缝和重叠。我的做法是生成一个统一的网格体直接计算每个扇区对应的顶点扇区间的分隔区域用透明三角形拼接。这样既保证没有缝隙又在选中高亮时方便处理。在实现过程中我还发现一个共性问题网格体的欧拉角旋转有时候会导致“万向锁”现象柱状图在连续旋转时会突然翻转。为了避免这个问题raychart 在相机的旋转控制中统一使用四元数运算而不是手动累加欧拉角。三维旋转的顺序和插值计算都要围绕四元数展开这一点在移动端旋转手势响应时尤其重要。3.3 移动端交互设计手势解析、惯性模拟与视觉反馈移动端 3D 图表交互我的设计原则只有两条手势不跟手就重写反馈不即时就优化。单指旋转的实现不能直接把触摸位移映射为相机旋转角。手指在屏幕上滑动只是滑动起点和终点的角度变化为了让操作更自然我引入了“虚拟轨迹球”算法。简单说用户在屏幕上的移动被映射成轨迹球表面的位移然后转换成四元数增量旋转。这个算法的好处是旋转速度和方向始终与手指同步不会出现“鼠标式”的延迟感。双指缩放则相对直接一些但细节在速度控制上。两指距离变化率需要平滑过滤如果直接用原始帧间的距离增量画面缩放会抖得很厉害。我在手势解析器里加了一个低通滤波器每次缩放增量的计算公式是current lerp(previous, rawDelta, 0.35)实测下来缩放手感非常稳。同时双指缩放的焦点应该锁定在两指中心点让缩放操作看起来是围绕用户关注的区域进行的而不是围绕画面中心。惯性模拟是我要特别强调的内容。很多图表库在桌面端做惯性没有问题但移动端的手指抬起速度非常高如果摩擦系数设得不对画面会惯性滑动半天收不住用户很难定位到自己想看的数据。raychart 采用指数衰减模型每次更新时把旋转速度乘以一个系数这个系数通常在 0.92 到 0.96 之间。系数太大惯性明显但不易停止系数太小则滑不动。我在 iPhone 和 Android 的真机上分别调过参数最终都设在 0.94 附近。交互反馈还有一块是点击高亮。移动端手指点击射线检测非常消耗性能。如果每帧都对所有三角形做射线求交在复杂场景里会带来明显的卡顿。我的优化是两步走先在屏幕空间里做 AABB 粗筛只对包围盒可能被射线击中的 mesh 做精确三角求交。柱状体这种规则几何体的求交其实可以直接用数学公式算出被点的轴和柱子坐标不需要真的去测试三角形。高亮的表现包括三部分目标网格体的颜色变化、选中对象的轻微上浮动效、以及数值面板的定位弹出。动效的时间控制在 180 毫秒左右太慢会让人觉得卡顿太快则看不清过渡。4. 性能优化实战从渲染管线到内存管理的逐层打磨这一节是整篇内容的重头戏。raychart 的性能目标是在中端 Android 手机上稳定 30fps尤其是旋转和缩放这类高频交互状态下也必须保持流畅。为了达到这个目标我从渲染管线、CPU 调度、内存和 GPU 资源管理四个层面分别做了优化每一层都有对应的实战方案。4.1 渲染管线的开销分析与 draw call 削减策略先说 draw call。单个 3D 柱状图在 1000 根柱子时如果不做合并每帧的 draw call 可能超过 1000 次。移动端的 GL 驱动对 draw call 的预算远低于桌面端一般在 200 到 300 次之间超过这个值帧耗时就会非线性上升。为了把 draw call 降下来我在每个图型的几何体生成阶段就完成了“网格合并”数据系列的粒度大到整个图表所有柱子合并成一个 geometry。合并后的材质管理也成为关键。如果 1000 根柱子有 1000 种颜色传统做法是创建 1000 份材质这会导致大量材质切换。raychart 将颜色编码进 attribute在顶点着色器里直接读取并传递给片元着色器。这样所有柱子共享一个材质GPU 在批处理上非常友好。这个方案在大数据量的折线图里同样适用每条线段的颜色、透明度、线宽都可以作为 attribute 传给着色器。还有一点容易被忽略的是阴影。阴影是渲染管线里开销最大的效果之一它需要额外的深度渲染 pass。移动端 3D 图表根本不需要实时阴影。我在 raychart 中完全禁用了阴影地面和网格线直接绘制在场景的前方平面上通过雾效模拟轻微的距离感这样既保留了深度暗示也把阴影的渲染成本省掉一大块。4.2 帧率控制的细节requestAnimationFrame 调度和 FPS 自适应移动端图表长时间运行时如果帧率完全无限制CPU 占用会持续保持高位导致发热和耗电。raychart 引入了一个“动态帧率”机制默认满帧率渲染但检测到设备温度升高或性能下降时自动降为半帧率模式比如从 60fps 降为 30fps。这个检测并不依赖系统的温度 API而是通过主线程的长任务统计和帧耗时的移动平均值来做判断。当最近 20 帧的平均耗时超过 40ms 时渲染循环主动跳过一帧让 GPU 有机会进入低功耗状态用户的感知却不会很明显因为惯性旋转和位移动效都是缓和的。在渲染循环的实现上我没有用简单的requestAnimationFrame(render)递归而是把逻辑拆成三个阶段事件扩散、数据更新、渲染提交。事件扩散处理交互状态和 Raycaster 结果数据更新负责把用户手势转换成四元数或缩放系数渲染提交最终调用renderer.render(scene, camera)。这样的拆分让状态管理更清晰也方便在禁用交互的纯展示模式里直接跳过前两个阶段。requestAnimationFrame在移动端还有一个特点当页面切到后台时浏览器会自动暂停 rAF这本来是好事但图表程序如果在 rAF 回调里监听了数据变化在恢复时可能会一下子堆积多个更新事件。我在渲染循环里对数据版本做了防抖每次回调只处理最新的版本。4.3 内存和 GPU 资源管理防止移动端 OOM 与显存泄漏移动端的内存池比桌面端小一个数量级一个不小心就会触发浏览器崩溃或者 GPU 进程被杀。在 raychart 里我做了三件事来保证内存稳定。第一几何体对象池化。频繁的数据更新场景下柱状图可能需要从 100 根柱子变成 1000 根柱子再变回 100 根。如果每次都重新生成 geometry 并丢弃旧的会产生大量 GPU 缓冲区的临时对象。我维护一个“空闲几何体池”在柱子数量减少时不销毁多余的 geometry而是把它放入池中等待复用数据量增加时直接从池里拿旧的 geometry 来填充数据。实测下来这个机制把 5000 根柱子反复更新的帧内存峰值降低了至少 40%。第二显存对象释放的时机。Three.js 中的geometry.dispose()和material.dispose()必须被主动调用否则 GPU 内存不会自动回收。我在每个RaySeries的onUnmounted钩子里统一处理但有个坑是异步组件可能会重复触发卸载所以我的释放函数带有幂等标记确保不会把同一个资源释放两次。第三纹理资源的压缩。图表的纹理不涉及复杂贴图基本是一些圆形高光、渐变遮罩我会在图片加载后立刻绘制到离屏 Canvas再转成CanvasTexture。这样后续的内存占用完全可控而且还能避免加载外部图片的 CORS 问题。在用 CanvasTexture 时要注意Canvas 尺寸不能无限大像素比太高会直接导致纹理内存翻倍所以纹理像素比默认设置成 2 就足够了。4.4 数据降采样与增量更新机制移动端图表通常会面对大数据量一小时间的数据就有 3600 个点直接全部绘制到 3D 场景里不仅浪费 GPU 像素也会让画面显得杂乱。raychart 在数据层加入了一个“分箱抽稀”模块对折线图把数据按屏幕 X 轴方向等距分箱每个箱子里只保留最大值、最小值和平均值生成三个点。这个结果和原始数据的形态几乎一致但顶点数可以减少 70% 以上。抽稀的粒度不是固定的而是根据当前缩放级别动态调整越放大越精细。增量更新机制则是为了应对数据实时推送的场景。当后端每秒钟推送新的数据点我不需要重建整个几何体而是在 Buffer 的末尾添加新的顶点如果缓冲区空间不足才重新分配新的 Float32Array。移动端实时图表通常数据量不大这种增量更新策略能让 CPU 占用保持在一个很低的水平。4.5 真机负载实测不同机型下的帧率表现说了这么多理论我直接放一组真机的实测数据。测试场景固定为一个 3D 柱状图包含 2000 根柱子启用旋转交互和双指缩放渲染分辨率为 1080p 级别的 DPR 1.5 画面。机型GPU 能力平均帧率最低帧率帧率波动iPhone 14 ProApple A16 GPU59.648.2极小小米 14Adreno 75058.144.5可控荣耀 80Adreno 642L38.725.4明显红米 Note 11Adreno 61930.218.9显著可以看到即使是 Adreno 619 这种相对入门的 GPU在聚合和动态降帧策略的加持下也能保持 30fps 的基准线。低端机上帧率会在交互瞬间下降到 20fps 以下但接下来会根据温度检测自动降帧快速恢复到稳定状态用户感知的“卡顿”会明显弱化。相比之下优化前同样硬件跑同样的场景平均帧率只有 12fps画出完整的图表要等上 2 秒以上。这次系统升级带来的体感提升是本质性的。5. 实战中遇到的坑与排查经验实录写到这里性能优化讲了这么多如果不吐一吐实际开发中踩过的坑总觉得少了点什么。raychart 在开发和上线过程中遇到了好几个非常隐蔽的问题这里挑三个典型的一一分享。5.1 坑位一Vue 响应式数据更新泄漏到渲染循环这是个非常典型的 Vue 3 Three.js 集成问题。我早期的代码里RaySeries组件的数据源是一个由ref()包裹的数组。当我直接用this.geometry.attributes.position.setXYZ()更新柱子位置时Three.js 内部并不会触发 Vue 的响应式依赖但 Vue 可能因为某些代码路径不小心访问了ref的 value 而建立了依赖关系。最直接的后果是数据更新不仅会重绘 WebGL 场景还会触发组件内无关 DOM 的重新渲染严重时形成 CPU 的重复开销。排查方式是用 Vue DevTools 的“性能分析”工具看渲染的组件数量是否多于预期。解决办法也简单粗暴所有传给 WebGL 的数据一律使用不是响应式的普通对象或者用shallowRef和markRaw彻底隔离。Vue 只管组件生命周期和通信图表数据的响应交给 raychart 自己的消息总线处理。这个坑对新手来说非常隐蔽因为功能上没有问题只是性能上多了一个难以察觉的拖油瓶。5.2 坑位二着色器精度设置导致的移动端渲染异常移动端 GPU 对着色器的精度要求很严格。Three.js 的默认着色器根据不同平台自动设置精度但自定义着色器如果忽略了precision声明在某些国产 Android 浏览器上会出现渲染错乱或者直接白屏的现象。我的经验是所有自定义着色器都显式声明precision highp float;。高精度会影响一点性能但移动端现代 GPU 完全能承受。另一个更坑的点是int类型在片元着色器里的支持差异。我在实现折线图端点的箭头形状时最初使用int类型做条件判断结果在某台低端机上出现了奇怪的条纹。排查了半天最终把所有int判断改成float类型比较才解决。5.3 坑位三ResizeObserver 触发后的视觉跳跃移动端浏览器地址栏的收起和展开会导致视口高度频繁变化。很多图表组件在 Resize 时会重置相机位置或缩放比例看起来就像画面瞬间“跳”了一下。我最后的处理方案是只针对容器尺寸变化做 aspect 比例更新保持相机位置和旋转量不变。如果用户正在旋转图表Resize 期间不能打断手势。另外所有 Resize 事件都通过requestAnimationFrame节流一帧内无论触发多少次只执行一次更新。5.4 常见问题速查表问题现象可能原因解决方案移动端画面模糊DPR 设置过高或过低将 DPR 限制在 1.5 到 2 之间按设备能力分级旋转时画面抖动欧拉角累加导致万向锁改用四元数增量旋转长时间运行后崩溃几何体未 dispose 或对象池溢出使用对象池并统一在卸载钩子中释放资源双指缩放“乱跳”缩放增量未平滑加入低通滤波lerp(previous, raw, 0.4)低端机帧率剧烈波动draw call 过多或阴影开启禁用实时阴影合并网格启用动态降帧图表加载时白屏WebGL 上下文创建失败或着色器报错检查着色器精度声明并监听webglcontextlost触摸操作偶尔失灵手势识别与鼠标事件冲突优先使用原生的 touch 事件解析不必强制复用 pointer 事件5.5 关于调试工具的使用心得移动端 3D 性能调试最常用的是 Chrome DevTools 的 Remote Debugging 和 Safari 的 Web Inspector。这两个工具都能显示 GPU 相关的 profiling 指标但要注意的是移动端 WebGL 的 Profile 数据往往不够细很多底层驱动级的瓶颈根本看不到。我的经验是除了依赖 DevTools还要在图表代码里埋一套轻量的性能探针自己在 WebGL 层记录关键指标每次 render 的耗时、draw call 数量、几何体顶点数、上传 GPU 的数据字节数。这些数据打到页面的一个隐藏面板里真机上看一眼就能定位瓶颈在哪一层。调试帧率问题时常犯的一个错误是只盯着平均 FPS。平均 60 帧不代表没有严重卡顿要看每一帧的耗时分布曲线特别是最慢的那几帧是不是超过了 100ms。一次性 GC 或者纹理同步上传经常会造成这种掉帧尖刺。raychart 里我专门记录了一个“最慢 10 帧平均耗时”指标它比平均 FPS 更能反映真实体感排查问题时帮助巨大。6. 升级后的实际效果与后续扩展思考整个 raychart 系统升级完成后交付出去的移动端图表页面的加载耗时从原来的 3.4 秒降到了 1.2 秒其中大部分消耗在 WebGL 上下文初始化和着色器编译上。后续优化还考虑用离屏渲染和预编译着色器进一步压缩这部分耗时但已经不会影响首屏体验了。交互层面用户对旋转和缩放反馈的评价是“跟手了”这就是交互模型从鼠标逻辑切换到轨迹球逻辑后最直接的体感变化。点击高亮从原来的 200ms 延迟降到了 40ms 以内基本上做到了点哪亮哪。我个人实际使用下来的体会是3D 图表可视化最大的风险往往不在图形学本身而在工程整合的细节里。任何一个小地方偷懒比如响应式泄漏、着色器精度问题、内存释放不及时都会在移动端被设备差异无限放大。raychart 这次系统升级验证了一个结论只要在架构设计上把性能当作一等公民而不是功能做完之后再考虑移动端 3D 图表完全能达到令人满意的效果。最后再分享一个后续可以试的方向raychart 当前的事件处理和渲染循环都跑在主线程上未来可以把数据预处理和网格合并计算迁移到 Web Worker用 SharedArrayBuffer 把数据直接传给主线程的 GPU 上传队列进一步释放主线程的压力。对于数据量继续爆炸的场景还可以考虑做几何体 LOD 分级根据摄像头距离自动切换柱子细节层级。这个方向不会停下希望以上经验能帮到正在做类似项目的你。
