01. 聊聊 Web 开发里的“库膨胀”：我们真的需要几百 KB 来画一根线吗？

说个挺无奈的现象：现在的 Web 开发好像陷入了一种“全家桶依赖”。

有时候我就想在页面上搞个简单的绘图功能，去社区一搜，满屏都是推荐上 PixiJS、Three.js 或者 Fabric.js 的。这些库确实牛，但我就画几根线条，至于一上来就加载个几百 KB、甚至几 MB 的 JS 包吗？为了一个简单的交互，引入一套复杂的引擎架构，这在我看来其实是挺“偷懒”的工程实现。

我一直觉得，一个开发者真正的底气，不在于你会调多少个库的 API，而在于你能用最原生的 Canvas 写出多骚的操作。

最近我翻到了 WigglyPaint 的实现，它的思路简直是一股清流。它没有走那种“大而全”的路子，而是借鉴了早期 Decker 里的那种极简哲学。它证明了：只要底层逻辑跑得通，原生代码照样能把性能和效果玩出花来。

02. 底层逻辑：为什么你应该放弃 [{x,y}] 这种写法？

如果你想在 Canvas 上跑每秒 60 帧的实时渲染，第一件事就是得动动数据结构。

平面数组 vs 对象数组
很多人的习惯是存一个对象数组，比如 [{x:1, y:1}, {x:2, y:2}]。这看起来很直观，但在处理几万个点位时，这简直是垃圾回收（GC）的噩梦。浏览器要不断地创建和销毁这些小对象，主线程不卡顿才怪。

WigglyPaint 的思路比较硬核，它受 Lil 语言的启发，采用的是向量式思维。简单说，就是把坐标全部平铺在一个连续的数组里：[x1, y1, x2, y2, x3, y3...]。

为什么这样做快得飞起？
GC 友好： 一个大的 Float32Array 比几万个小对象要稳定得多，内存几乎没有抖动。

缓存友好性（Cache-friendliness）： CPU 读取连续内存的速度远快于跳跃式的引用查找。当你需要处理百万级别的点位计算时，这种底层优化带来的性能红利是代差级的。

03. 核心算法：用正弦波给线条“注入灵魂”

很多人好奇，那些线条是怎么扭得那么自然的？其实背后的数学逻辑特别纯粹。

线条不是在乱动，而是在“偏移”
如果用 Math.random() 来做，线条只会闪烁得像老式电视机的雪花。WigglyPaint 的核心是基于时间的正弦扰动。

代码层面的逻辑其实就是给每个坐标点加一个位移量： newX = x + Math.sin(time frequency + offset) amplitude

这里有三个关键变量：
频率 (Frequency)： 决定了线条“抖”的速度。是慢悠悠的蠕动，还是高频的颤火，全靠这个参数。

振幅 (Amplitude)： 决定了线条偏移的物理距离。振幅越大，线条扭动的幅度就越夸张。

相位差 (Phase Shift)： 这是最关键的一点。如果你给所有线条同样的 time 参数，那它们看起来就像是在跳广播体操，非常呆板。WigglyPaint 给每根线条注入了不同的初始相位，这样它们动起来就有先有后，交织在一起才有那种“生物感”。

这种算法最迷人的地方在于：它用极其微小的计算开销，换取了极其复杂的视觉反馈。这才是硬核技术人该追求的优雅。

04. 性能压榨：在 Web 端稳住 60FPS 的“骚操作”

如果你的 Canvas 上只有几十根线，怎么折腾都没事。但一旦用户画嗨了，屏幕上堆叠了几千个坐标点，浏览器就开始吃不消了。要在 Web 端稳住 60FPS 的实时渲染，靠堆配置是不行的，得靠“省”。

别再傻傻地全量重绘
很多初学者的习惯是每一帧都调用 clearRect 擦掉整个画布再重画。当线条变多时，这简直是 CPU 的自杀行为。在 WigglyPaint 的逻辑里，我们追求的是更聪明的刷新策略：比如只对当前视野内或者有位移变化的路径进行重绘，或者通过分层 Canvas 技术，将背景静态内容和动态扭动线条分离，极大地减少了无效计算。

离屏渲染的降维打击
如果你追求极致，那就得聊聊 OffscreenCanvas。它能把繁重的渲染任务从主线程剥离，扔给 Web Worker 去跑。这意味着即便你在进行高强度的点位偏移计算，页面的 UI 响应、滚动和点击依然丝滑，完全不会被渲染逻辑卡住。

被低估的 RAF 调度
在处理笔触数据时，千万别直接在 mousemove 里写渲染逻辑。鼠标事件的触发频率和屏幕刷新率往往是不对等的。WigglyPaint 的核心调度是靠 requestAnimationFrame (RAF)。我们将捕获到的笔触数据先存入一个缓冲区，然后交给 RAF 统一在每一帧渲染前进行节流处理和平滑插值。只有这样，你画出的曲线才是圆润的，而不是一截一截的折线。

05. 跨端工程：让 iPad 真正成为“生产力”

很多人觉得网页绘图在平板上就是个弟弟，那是因为大多数人还停留在 mousedown 和 touchstart 的旧时代。

Pointer Events API：捕捉灵魂的参数
要让 WigglyPaint 支持 Apple Pencil 的原生手感，必须祭出 Pointer Events API。 这玩意儿不只是能感应点击，它能实时返回 pressure（压力）和 tilt（倾斜度）。

数据映射：让线条“随力而动”
捕捉到压感只是第一步，真正的硬核操作是动态参数映射。 在 WigglyPaint 的逻辑里，我们将 Apple Pencil 的压感数值实时映射到了正弦算法的 amplitude（振幅）参数中。

轻扫： 压感小，振幅低，线条只是微微颤动。

重压： 压感激增，振幅瞬间拉大，线条会像受惊一样剧烈扭动。 这种“随力而动”的交互反馈，才是让用户产生“这笔是活的”那种沉浸感的关键。

06. 结论：Web 工程的减法艺术

写了这么多，我最想表达的是：强大的功能不一定需要庞大的体积。

在现在这个动辄几十 MB 打包包体积的开发环境下，WigglyPaint 像是一次清爽的技术回归。它告诉我们，只要你对底层 Canvas 足够了解，对基础数学运用得够熟练，哪怕不写一行后端代码，不接一个重型框架，照样能玩出极具冲击力的交互体验。

这种“减法艺术”，其实就是理解底层原理后的自由。

如果你也玩腻了那些笨重的库，或者想亲自感受一下原生 Web 开发能达到的上限，我强烈建议你去玩一下。甚至可以去翻翻看它的开源思路，你会发现，回归数学和原生 API，才是 Web 开发最浪漫的地方。