1. 从一个“不讲道理”的边界说起第一次拿到那份区划边界数据的时候我盯着屏幕看了很久。那是一条由几千个顶点组成的闭合折线形状像被猫抓过的毛线团——有的地方平滑得像用圆规画出来的有的地方突然凹进去一个尖角还有几段几乎重叠在一起放大到最大层级才能勉强分辨出两条线之间的缝隙。这种图形在GIS领域有个很形象的说法叫“无道理的区划边界”。它不像行政区划那样有规整的几何逻辑也不像自然地貌那样有明确的物理成因它就是一堆历史沿革、统计口径、人为划分叠加之后留下的“疤痕”。问题在于这种图形用常规的SVG或者Canvas路径来画性能会非常难看。顶点数量一旦过万浏览器就开始卡顿缩放拖拽的时候帧率掉得厉害。我试过用SVG的path元素直接渲染Chrome的开发者工具里那个“Recalculate Style”的紫色条几乎占满了整个时间轴。后来转向Canvas 2D情况好一些但每次重绘都要重新遍历所有顶点交互体验依然不够顺滑。这时候我想到了CreateJS。这个库在游戏开发圈子里用得比较多尤其是它的EaselJS模块对Canvas的封装相当成熟支持显示列表、事件冒泡、缓存机制而且对不规则矢量图形的处理有一套自己的逻辑。我决定用它来试试看看能不能把这种“无道理”的边界画得既快又稳。这篇文章就是那次尝试的完整记录。我会从数据预处理开始一步步拆解CreateJS绘制不规则矢量图形的流程包括顶点简化、路径构建、缓存策略、交互优化以及我在实际项目中踩过的几个坑。如果你手头也有类似的“毛线团”数据或者你正在找一个比原生Canvas更省心的矢量渲染方案这篇内容应该能帮你省下不少试错时间。2. 为什么CreateJS适合处理这类“毛线团”图形2.1 CreateJS的显示列表与原生Canvas的本质区别原生Canvas的绘制逻辑是“即时模式”你调用ctx.beginPath()、ctx.moveTo()、ctx.lineTo()、ctx.stroke()浏览器立刻把像素画上去画完之后Canvas上只剩像素没有“图形对象”这个概念。这意味着如果你想在鼠标悬停时高亮某条边界必须自己维护一套坐标判断逻辑或者用isPointInPath()反复检测性能开销很大。CreateJS的EaselJS引入了“保留模式”的显示列表。你创建一个Shape对象给它一个Graphics实例在Graphics里定义路径然后把这个Shape加到Stage上。Stage在每一帧的tick里统一重绘所有显示对象。关键在于每个Shape都是一个独立的对象有自己的坐标、变换矩阵、事件监听器。你可以直接给某个Shape绑定mouseover事件CreateJS会自动帮你做命中检测——它内部用的是路径的包围盒加精确路径判断比你自己写要高效得多。对于不规则矢量图形来说这个差异非常关键。假设你有200个区划边界每个边界平均3000个顶点。用原生Canvas你要么每次重绘都遍历60万个顶点要么自己实现一套脏矩形更新机制。用CreateJS你可以把每个边界封装成独立的ShapeStage只重绘发生变化的区域通过update和cache机制而且事件处理是对象级别的代码写起来干净很多。2.2 不规则图形的顶点数据特征与性能瓶颈“无道理的区划边界”通常来自几个渠道遥感影像自动提取、历史地图数字化、统计单元合并。这些渠道产生的顶点数据有几个共同特征顶点密度极不均匀直线段上可能只有两个端点但曲线段上每像素就有一个顶点。存在大量冗余顶点数字化过程中鼠标抖动产生的微小折线在视觉上完全看不出区别但计算量翻倍。自相交与重叠不同层级的边界可能共享一段折线或者因为数据精度问题出现细微重叠。我拿到的数据里有一个区的边界有12400个顶点但实际视觉上需要保留的“关键转折点”大概只有800个左右。这意味着超过90%的顶点是冗余的。如果不做简化直接丢给CreateJS虽然它能画出来但内存占用和重绘耗时都会很夸张。这里有个经验值在1080p屏幕上一个矢量图形的顶点数超过5000之后每次重绘的耗时增长曲线会明显变陡。超过20000之后移动端基本就卡成幻灯片了。所以数据预处理不是可选项是必选项。2.3 选型对比CreateJS vs SVG vs 原生Canvas vs WebGL为了让你更清楚为什么我最终选了CreateJS我把几个方案的实际表现列出来方案优点缺点适用场景SVG矢量清晰CSS样式方便DOM事件天然支持顶点多时DOM节点爆炸重绘性能差顶点数1000的简单图形原生Canvas 2D性能比SVG好控制粒度细无对象模型事件需手动实现重绘逻辑要自己管顶点数5000交互简单的场景CreateJS有显示列表和事件模型缓存机制成熟API友好比原生Canvas多一层抽象极端性能场景不如WebGL顶点数5000-30000需要交互的场景WebGL性能最强适合海量顶点学习曲线陡峭2D图形需要自己写着色器顶点数50000或需要3D效果我的数据顶点数在8000到15000之间需要支持悬停高亮、点击弹窗、缩放拖拽CreateJS正好卡在甜点区。WebGL虽然性能更好但为了画2D边界去写一套着色器投入产出比不划算。3. 顶点简化把“毛线团”变成“可画的线”3.1 为什么不能直接丢原始数据给CreateJS原始数据里有一个区的边界我数了一下12400个顶点。直接构建Graphics对象调用moveTo和lineTo循环在Chrome里跑了一下单次重绘耗时大约48毫秒。这意味着如果每秒重绘60次光这一条边界就吃掉了将近3帧的时间。再加上其他边界和交互逻辑帧率直接掉到20以下。更麻烦的是内存。每个顶点在CreateJS内部会被转换成Graphics命令队列里的一个指令对象12400个顶点大概占用2.3MB内存。如果有50个这样的边界内存占用就超过100MB了移动端很容易触发内存警告。所以顶点简化是第一步。目标是在视觉损失可接受的前提下把顶点数降到原来的10%到20%。3.2 道格拉斯-普克算法的实际应用与参数调优道格拉斯-普克算法是矢量简化里最常用的方法。它的逻辑很直观对于一条折线连接首尾两点画一条直线找到离这条直线最远的顶点如果距离大于阈值就保留这个顶点然后对左右两段递归处理如果距离小于阈值就丢弃中间所有顶点。我在项目里用的是simplify-js这个库它实现了道格拉斯-普克算法而且支持highQuality模式。关键参数是tolerance也就是距离阈值。这个值怎么定我的经验是如果图形用于全局概览tolerance设为屏幕上一个像素对应的地理距离。如果图形需要支持放大到街道级别tolerance要设得更小或者做多级简化。具体到我的数据原始坐标是经纬度缩放级别在10到18之间。我计算了一下在缩放级别12时一个像素大约对应38米。所以我把tolerance设为0.0003度大约33米简化后的顶点数从12400降到了1100左右视觉上几乎看不出区别。import simplify from simplify-js; // 原始顶点数组格式为 [{x: lng, y: lat}, ...] const simplified simplify(originalPoints, 0.0003, true); // simplified 的长度大约是原来的9% console.log(originalPoints.length, simplified.length); // 输出: 12400 1100注意tolerance的单位和你的坐标单位一致。如果坐标是投影后的米就直接用米如果是经纬度就要根据纬度换算。在北纬30度附近1度经度大约对应96公里1度纬度大约对应111公里。别搞混了。3.3 简化后的视觉校验一个容易被忽略的步骤简化完之后千万别直接上线。我吃过一次亏简化后的边界在全局视图下看起来没问题但放大到某个局部时发现一个重要的拐角被“削平”了导致边界和实际地物对不上。所以我加了一个视觉校验步骤把原始边界和简化后的边界用不同颜色画在同一张图上叠加对比。具体做法是用CreateJS创建两个Shape一个用原始数据一个用简化数据原始数据用半透明红色简化数据用半透明蓝色。然后手动缩放拖拽检查每个区域。这个步骤花了我大概两个小时但发现了三处需要调整tolerance的地方。其中一处是一个河流拐弯简化后变成了一条直线视觉上很突兀。我把那一小段的tolerance单独调小重新简化问题就解决了。// 分段简化对关键区域使用更小的 tolerance const segments splitByRegion(originalPoints); const simplified segments.map(seg { const tol isKeyRegion(seg) ? 0.0001 : 0.0003; return simplify(seg, tol, true); }).flat();4. 用CreateJS构建不规则路径的完整流程4.1 初始化Stage与Graphics那些文档里没写的细节CreateJS的初始化看起来很简单但有几个细节如果没处理好后面会出问题。import { Stage, Shape, Graphics, Ticker } from createjs-module; const canvas document.getElementById(map-canvas); const stage new Stage(canvas); // 关键设置 stage 的 mouseEnabled 和 tick 机制 stage.mouseMoveOutside true; stage.enableDOMEvents(true); // 使用 Ticker 驱动重绘而不是手动 requestAnimationFrame Ticker.framerate 60; Ticker.addEventListener(tick, stage);第一个坑是stage.enableDOMEvents(true)。默认情况下CreateJS会监听Canvas上的鼠标事件但如果你的Canvas被其他DOM元素覆盖比如一个工具栏事件可能被拦截。开启这个选项后CreateJS会把事件监听绑定到window上通过坐标转换来判断是否命中显示对象。代价是性能略降但交互更可靠。第二个坑是Ticker和requestAnimationFrame混用。CreateJS的Ticker内部已经用了requestAnimationFrame如果你再手动调一个会导致重绘频率翻倍性能白白浪费。统一用Ticker就好。第三个坑是Graphics的绘制顺序。CreateJS的Graphics是命令队列先调用的命令先绘制。如果你先画填充再画描边描边会覆盖在填充上面反过来填充会盖住描边的一半。对于区划边界我通常先画填充半透明再画描边实线这样边界线更清晰。const shape new Shape(); const g shape.graphics; // 先填充 g.beginFill(rgba(70, 130, 180, 0.3)); g.beginStroke(#2c3e50); g.setStrokeStyle(1.5); // 构建路径 g.moveTo(points[0].x, points[0].y); for (let i 1; i points.length; i) { g.lineTo(points[i].x, points[i].y); } g.closePath(); // 结束填充和描边 g.endFill(); g.endStroke(); stage.addChild(shape); stage.update();4.2 路径构建的性能陷阱moveTo/lineTo的调用开销moveTo和lineTo看起来只是往命令队列里推一个指令但调用次数多了之后开销不容忽视。我实测过在Chrome里连续调用lineTo10000次耗时大约12毫秒。如果每帧都重新构建路径这个开销就太大了。解决方案是只在初始化时构建一次路径之后通过变换矩阵来缩放和拖拽而不是重新构建。CreateJS的Shape对象有scaleX、scaleY、x、y属性改变这些属性不会触发路径重建只会改变渲染时的变换矩阵。这比重新调用lineTo快了几个数量级。// 错误做法每次缩放都重新构建路径 function onZoom(scale) { shape.graphics.clear(); shape.graphics.beginFill(rgba(70, 130, 180, 0.3)); shape.graphics.moveTo(points[0].x * scale, points[0].y * scale); // ... 重新遍历所有顶点 } // 正确做法只改变换属性 function onZoom(scale) { shape.scaleX scale; shape.scaleY scale; stage.update(); }但这里有个问题如果缩放级别变化很大简化后的顶点在放大后会显得不够精细。我的做法是准备两套顶点数据一套是高度简化的用于缩放级别14一套是中度简化的用于缩放级别14。当缩放级别跨过阈值时切换Shape的graphics内容。切换时会有一次重绘开销但频率很低可以接受。4.3 缓存机制把复杂图形“冻”成位图CreateJS的cache()方法是我最喜欢的功能之一。它的原理是把一个显示对象渲染到一个离屏Canvas上之后重绘时直接贴图不再执行路径绘制命令。对于顶点数多、不经常变化的图形缓存能带来巨大的性能提升。// 缓存整个 Shape shape.cache(0, 0, canvas.width, canvas.height); // 或者只缓存边界框区域 const bounds shape.getBounds(); shape.cache(bounds.x, bounds.y, bounds.width, bounds.height);但缓存有几个坑第一缓存后的图形在缩放时会模糊。因为缓存的是位图放大后像素被拉伸。所以缓存适合在缩放级别固定或者变化不大的场景。如果用户会频繁缩放要么在缩放结束后重新缓存要么不用缓存。第二缓存区域要算准。如果cache()的矩形区域小于图形实际范围超出的部分会被裁掉。我一般用getBounds()获取精确边界再往外扩几个像素。第三缓存会占用内存。一个全屏大小的缓存位图在1080p下是1920×1080×4字节大约8MB。如果缓存几十个图形内存很快就上去了。我的策略是只缓存当前视口内的图形视口外的图形取消缓存。// 视口变化时动态管理缓存 function updateCache() { shapes.forEach(shape { if (isInViewport(shape)) { if (!shape.cacheCanvas) { const b shape.getBounds(); shape.cache(b.x - 5, b.y - 5, b.width 10, b.height 10); } } else { if (shape.cacheCanvas) { shape.uncache(); } } }); }4.4 事件绑定与命中检测让不规则图形“可点击”CreateJS的事件系统是基于显示列表的。你给Shape绑定click事件CreateJS会在鼠标点击时遍历显示列表对每个Shape做命中检测。命中检测的默认逻辑是先判断点是否在Shape的包围盒内如果在再进一步判断是否在路径内部。对于不规则图形这个判断过程可能比较耗时。CreateJS内部用的是Graphics的命令队列来重建路径然后调用Canvas的isPointInPath()。如果顶点数很多每次点击都要重建路径体验会卡。优化方法是给Shape设置一个简化的命中区域。CreateJS支持hitArea属性你可以指定一个更简单的Shape作为命中检测区域。比如用一个凸包或者包围盒来代替复杂路径。// 创建一个简化的命中区域凸包 const hitArea new Shape(); hitArea.graphics.beginFill(#000).drawPolyStar(0, 0, 100, 6, 0, 0); shape.hitArea hitArea;但这样会降低命中精度。对于区划边界我通常还是用精确路径因为用户点击的意图很明确稍微慢一点可以接受。如果确实卡可以考虑用四叉树或者网格索引来加速空间查询但那又是另一个话题了。5. 实际项目中的性能调优与踩坑记录5.1 一次诡异的帧率骤降原因竟然在Ticker上项目上线后有用户反馈在某个特定区域拖拽地图时帧率会突然从60掉到15左右。我一开始以为是顶点数太多但那个区域的边界顶点数并不算多。后来用Performance面板录了一段发现Ticker的tick事件处理函数耗时异常达到了40毫秒。排查了半天最后发现是Ticker的timingMode设置问题。CreateJS的Ticker默认使用requestAnimationFrame但在某些浏览器或设备上如果页面不是前台活跃状态requestAnimationFrame会被降频。而我在代码里又手动调用了stage.update()导致一帧内重绘了两次。解决方案是统一用Ticker驱动移除所有手动stage.update()调用。同时设置Ticker.timingMode Ticker.RAF_SYNCHED确保和浏览器的刷新率同步。Ticker.timingMode Ticker.RAF_SYNCHED; Ticker.framerate 60; Ticker.addEventListener(tick, stage); // 移除所有手动 stage.update()5.2 内存泄漏被忽略的uncache与事件解绑另一个坑是内存泄漏。项目运行一段时间后浏览器标签页的内存占用从200MB涨到了1.2GB。用Chrome的Memory面板抓了堆快照发现大量的Graphics和Shape对象没有被回收。原因是每次切换数据层时我创建了新的Shape对象但没有移除旧的。旧Shape还挂在Stage上而且绑定了事件监听器导致无法被垃圾回收。修复方法是在切换数据层时先调用stage.removeAllChildren()然后对每个Shape调用uncache()和removeAllEventListeners()。function clearStage() { stage.children.forEach(child { if (child.cacheCanvas) child.uncache(); child.removeAllEventListeners(); }); stage.removeAllChildren(); stage.update(); }这个操作看起来简单但很容易忘。我后来养成了一个习惯任何创建Shape的地方都配套写一个清理函数确保生命周期可控。5.3 移动端适配触摸事件与性能降级策略移动端的坑更多。首先是触摸事件CreateJS默认支持touchstart、touchmove、touchend但需要设置stage.enableDOMEvents(true)和stage.mouseMoveOutside true。另外移动端的devicePixelRatio通常是2或3Canvas的实际像素尺寸是CSS尺寸的几倍渲染压力更大。我的降级策略是在移动端把Ticker.framerate降到30。简化阈值tolerance调大1.5倍减少顶点数。关闭阴影和渐变填充只用纯色。缓存区域缩小到视口的一半减少内存占用。const isMobile /Mobi|Android/i.test(navigator.userAgent); if (isMobile) { Ticker.framerate 30; tolerance * 1.5; // 使用更简单的样式 }实测下来这些调整能让移动端的帧率从20左右提升到45以上虽然不如桌面端流畅但已经可以接受了。5.4 一个实用的调试技巧用颜色标记重绘区域调试Canvas性能时最直观的方法是看哪些区域在重绘。CreateJS的Stage有一个update方法你可以在重绘前给Canvas填充一个半透明颜色这样每次重绘的区域会叠加颜色颜色越深说明重绘越频繁。stage.update function() { const ctx this.canvas.getContext(2d); ctx.fillStyle rgba(255, 0, 0, 0.05); ctx.fillRect(0, 0, this.canvas.width, this.canvas.height); // 调用原始 update Stage.prototype.update.call(this); };这个技巧帮我定位了好几次性能问题。比如有一次发现某个区域的红色特别深检查后发现是一个Shape的cache区域设置错了导致每帧都在重新缓存。6. 从“能画”到“好用”的进阶思路6.1 多级细节层次与动态切换前面提到过我用两套顶点数据来应对不同缩放级别。更完善的做法是建立多级细节层次类似地图瓦片的LOD机制。比如LOD 0tolerance 0.001顶点数约200用于缩放级别10。LOD 1tolerance 0.0003顶点数约1100用于缩放级别10-14。LOD 2tolerance 0.0001顶点数约4000用于缩放级别14。切换时不是直接替换Graphics内容而是用淡入淡出过渡避免视觉上的“跳变”。CreateJS的Tween模块可以很方便地实现透明度动画。function switchLOD(newPoints) { const oldShape currentShape; const newShape buildShape(newPoints); newShape.alpha 0; stage.addChild(newShape); createjs.Tween.get(newShape).to({ alpha: 1 }, 200); createjs.Tween.get(oldShape).to({ alpha: 0 }, 200).call(() { stage.removeChild(oldShape); oldShape.uncache(); }); currentShape newShape; }6.2 边界线的样式优化虚线、渐变与阴影的取舍不规则边界如果只用一条实线视觉上会比较单调。但加样式是有性能代价的。我实测过几种样式的开销样式相对开销建议纯色实线1x默认使用虚线1.8x顶点数3000时可用渐变描边3.2x仅用于重点区域阴影4.5x移动端禁用我的做法是默认用纯色实线鼠标悬停时切换为高亮色加粗点击选中时加阴影。这样大部分时间开销都很低只有交互时才付出额外代价。6.3 数据更新时的增量渲染策略如果边界数据会动态更新比如实时统计单元变化全量重绘是不可接受的。CreateJS支持Graphics的clear()和重新绘制但更好的做法是只更新变化的Shape。我的策略是给每个Shape绑定一个唯一ID数据更新时对比新旧数据只重建ID发生变化的Shape其他Shape保持不变。这样如果只有5%的边界变化重绘开销也只有5%。function updateData(newData) { const changedIds diff(oldData, newData); changedIds.forEach(id { const shape shapeMap[id]; shape.graphics.clear(); buildPath(shape.graphics, newData[id]); if (shape.cacheCanvas) { shape.uncache(); const b shape.getBounds(); shape.cache(b.x, b.y, b.width, b.height); } }); stage.update(); }这个思路在数据频繁更新的场景下特别有用比如实时监控面板或者动态区划调整。6.4 导出与分享把Canvas内容变成图片有时候需要把绘制好的边界导出成图片用于报告或者分享。CreateJS的Stage底层是Canvas所以可以直接调用canvas.toDataURL()。const dataURL stage.canvas.toDataURL(image/png); const link document.createElement(a); link.download boundary.png; link.href dataURL; link.click();但要注意如果Canvas被污染了比如加载了跨域图片toDataURL会报错。纯矢量绘制不会有这个问题可以放心用。另外如果图形很大导出的图片分辨率可能不够。可以在导出前临时把Stage的scaleX和scaleY调大渲染到离屏Canvas再导出。function exportHighRes(scale) { const offCanvas document.createElement(canvas); offCanvas.width canvas.width * scale; offCanvas.height canvas.height * scale; const offStage new Stage(offCanvas); // 复制显示对象到 offStage设置 scale // ... return offCanvas.toDataURL(image/png); }这个功能在项目里很受欢迎用户可以把当前视图导出成高清图片直接贴到PPT里。7. 一些零散但有用的经验关于顶点数据的预处理还有几个小技巧。一是坐标精度原始数据如果是double类型可以截断到小数点后6位能减少不少内存占用视觉上完全看不出区别。二是顶点顺序确保所有边界都是逆时针或顺时针这样填充规则才一致不会出现“空洞”。三是自相交处理如果边界有自相交填充结果可能不符合预期可以用Graphics的drawPolygon代替手动lineTo它会自动处理。关于CreateJS的版本我建议用createjs-module这个npm包而不是直接引入createjs.min.js。模块化版本支持Tree Shaking打包体积更小而且可以用ES6的import语法代码更干净。关于调试CreateJS有一个Stage的snapToPixel属性开启后会把所有坐标对齐到整数像素减少抗锯齿带来的模糊。对于边界线来说这个属性很有用能让线条更锐利。但注意开启后缩放时可能会有轻微的“跳动”因为坐标被强制取整了。最后如果你也在处理类似的“无道理”矢量图形我的建议是不要试图一次性解决所有问题。先把数据简化到能跑起来再逐步优化交互和样式。CreateJS的灵活性足够你从原型一路迭代到生产环境关键是理解它的显示列表和缓存机制这两个东西用好了性能问题基本就解决了一大半。