1. 项目缘起与整体设计思路1.1 为什么会有 artcraft 这个想法做创意工具这些年我最大的感受就是灵感来得快工具跟不上。脑子里冒出一个画面想快速拼贴、调色、加纹理结果打开专业软件要等半分钟加载图层逻辑还没理清楚灵感已经凉了一半。artcraft 这个项目就是冲着这个痛点去的——它想做的事情很朴素把“创意拼装”这件事的门槛降到最低让手比脑子快。artcraft 本质上是一个轻量级的创意合成工具核心能力围绕“素材叠加 实时预览 参数微调”展开。你可以把它理解成一个数字化的手工台左边是素材架中间是画布右边是调节旋钮。它不追求替代重型设计软件而是专注解决“快速出效果”这个场景。适合谁用独立创作者、做社交内容的小团队、需要快速出视觉草稿的产品经理以及所有不想为了调一个渐变就去学整套图层系统的人。我最初做这个项目的动机很实际帮一个做手工饰品的朋友解决产品图批量加背景的问题。她不会用专业软件每次上新都要找人帮忙修图周期长、成本高。我就想能不能做一个“选素材、拖进去、调两下、导出”的极简流程。artcraft 的第一版就是这么来的后来慢慢扩展成了现在这个支持多图层、混合模式、参数化纹理的创意工具。1.2 技术选型的取舍逻辑artcraft 的技术栈选择经历了几轮反复。最开始想用纯前端方案Canvas 2D 起步理由是部署简单、跨平台无压力。但做到混合模式和实时滤镜的时候Canvas 2D 的性能瓶颈很明显——每加一个图层重绘开销线性增长到五六个图层就开始掉帧。后来切到 WebGL用片元着色器做混合和滤镜性能问题基本解决但开发复杂度上来了。最终的架构是WebGL 渲染核心 Canvas 2D 做辅助绘制 状态管理层独立。为什么这么分WebGL 负责图层合成、混合模式、实时滤镜这些 GPU 擅长的活Canvas 2D 处理文字渲染、矢量路径这些 WebGL 做起来别扭的部分状态管理单独抽出来保证撤销重做、参数联动这些逻辑不跟渲染耦合。这个分层看着简单但实际写的时候边界很容易模糊后面我会细说踩过的坑。选 WebGL 而不是 WebGPU原因很直接兼容性。WebGPU 虽然性能更好、API 更现代但当时覆盖的设备比例还不够artcraft 的目标用户里有大量中低端设备不能冒这个险。片元着色器用 GLSL ES 2.0 写虽然老但稳。实测下来在中端手机上跑六个图层的混合合成稳定在 55 帧以上够用了。1.3 核心功能模块拆解artcraft 的功能模块可以分成四块素材管理层、图层合成引擎、参数调节系统、导出与分享。这四块不是并列关系而是有明确的依赖方向——素材管理层向上提供资源图层合成引擎消费资源并产出画面参数调节系统作用于合成引擎的各个节点导出模块把最终结果序列化。素材管理层负责加载图片、纹理、字体、预设配置。这里的关键设计是资源懒加载 缓存池。用户可能导入几十张素材但同一时间只有少数几张在画布上活跃。懒加载保证内存不被撑爆缓存池避免重复解码。实测下来一个包含 50 张 2K 图片的项目内存占用控制在 200MB 以内比全量加载省了将近 70%。图层合成引擎是核心中的核心。每个图层是一个独立的渲染单元有自己的变换矩阵、混合模式、不透明度、滤镜链。合成顺序从下往上逐层混合。混合模式支持正常、叠加、正片叠底、滤色、柔光等常用类型每种模式对应一个片元着色器分支。这里有个性能技巧把混合模式编码成整数在着色器里用 switch 分支比用 if-else 链快不少因为 GPU 对整数分支的预测更友好。参数调节系统是 artcraft 区别于普通拼图工具的地方。每个可调参数都绑定了一个“参数描述符”包含最小值、最大值、步长、默认值、是否支持曲线调节。这样做的好处是 UI 可以完全由数据驱动生成加一个新参数只需要注册描述符不用改界面代码。参数变化时通过发布订阅模式通知渲染引擎更新对应的 uniform 变量避免全量重绘。导出模块支持 PNG、JPEG、WebP 三种格式分辨率可选原始尺寸或自定义缩放。导出时会把画布内容渲染到一个离屏 framebuffer再用readPixels读回像素数据最后通过toBlob生成文件。这里有个细节导出前要临时把设备像素比设为 1否则在高分屏上导出的图会带额外的缩放尺寸对不上。2. 核心细节解析与实操要点2.1 图层合成引擎的实现细节图层合成的核心逻辑在片元着色器里。每个图层渲染时把下层合成结果作为纹理传入当前图层的纹理作为另一个输入根据混合模式计算输出颜色。以正片叠底为例公式是result base * blend其中 base 是下层颜色blend 是当前图层颜色。这个公式看着简单但实际写的时候要注意颜色空间——如果纹理是 sRGB 编码的直接乘会偏暗需要先转到线性空间计算再转回 sRGB 输出。混合模式的着色器实现有个容易忽略的点Alpha 通道的处理。很多教程只讲 RGB 的混合公式但实际图层往往带透明度。正确的做法是先把当前图层的颜色按其 Alpha 预乘再与下层做混合最后根据混合后的 Alpha 还原。我一开始没注意这个导致半透明图层叠加时边缘发灰排查了半天才发现是 Alpha 没处理好。图层变换矩阵用 3x3 的仿射矩阵表示支持平移、旋转、缩放、斜切。矩阵乘法顺序很重要先缩放、再旋转、最后平移这个顺序符合大多数人的直觉。如果顺序反了旋转中心会跑偏。矩阵通过 uniform 传给顶点着色器每个图层渲染时更新一次。实测下来每帧更新六个图层的矩阵开销可以忽略不计。注意图层数量超过十个之后建议开启“合并静态图层”选项把不常变动的下层图层预合成到一张纹理减少每帧的绘制调用次数。这个优化在低端设备上效果尤其明显。2.2 参数调节系统的数据驱动设计参数描述符的结构大概是这样{ key, label, type, min, max, step, default, curve }。type 支持 number、color、boolean、select 四种。curve 字段决定 UI 上是用滑块还是曲线编辑器。这个设计的好处是新增一个“噪点强度”参数只需要在配置里加一行UI 自动生成滑块渲染引擎自动监听变化完全不用碰界面代码。参数联动是个麻烦事。比如“亮度”和“对比度”同时调节时如果分别独立作用结果可能过曝或死黑。我的做法是把相关参数打包成一个“调节节点”节点内部按固定顺序应用参数节点之间再按图层顺序合成。这样既保证了参数间的逻辑关系又保持了灵活性。节点配置用 JSON 描述可以保存成预设一键套用到其他图层。参数变化的通知机制用的是发布订阅。每个参数有一个唯一的 key渲染引擎订阅自己关心的 key。参数变化时发布者只通知订阅了该 key 的订阅者避免全量遍历。实测下来一百个参数同时变化时通知开销在 2ms 以内完全不影响帧率。这里有个小技巧把参数变化合并到下一帧统一处理用requestAnimationFrame做节流避免连续拖动滑块时触发大量重复计算。2.3 素材管理与内存优化素材加载用createImageBitmap而不是new Image原因是createImageBitmap可以在 Worker 里执行不阻塞主线程而且解码后的位图可以直接传给 WebGL 作为纹理省去了中间转换。实测下来加载一张 4K 图片用createImageBitmap比传统方式快 40% 左右主线程卡顿明显减少。缓存池的设计是按尺寸分桶。比如 512x512 的纹理放一个池1024x1024 的放另一个池。需要纹理时先从对应桶里找空闲的找不到再新建。这样做的目的是复用 GPU 纹理对象减少频繁创建销毁带来的开销。池的大小设了上限超过上限时按 LRU 策略淘汰最久未使用的纹理。这个策略在素材频繁切换的场景下很有效纹理创建次数减少了 80% 以上。提示如果项目里大量使用同一张素材的不同缩放版本建议预先生成 mipmap而不是每次缩放都重新采样。mipmap 虽然多占 33% 显存但渲染质量和性能都更好尤其是缩小显示的时候。素材的元数据尺寸、格式、来源、标签存在 IndexedDB 里方便快速检索和分类。IndexedDB 的读写是异步的不会阻塞 UI。我试过用 localStorage但容量太小几张图就满了而且同步读写会卡界面果断换掉。3. 实操过程与核心环节实现3.1 从零搭建渲染管线搭建渲染管线的第一步是初始化 WebGL 上下文。这里有个兼容性处理优先尝试webgl2失败则回退到webgl。虽然 artcraft 主要用 WebGL1 的特性但 WebGL2 在纹理格式和着色器语法上有一些便利能用到就用。上下文初始化时要把preserveDrawingBuffer设为 false除非需要截图功能否则开着会影响性能。第二步是创建着色器程序。artcraft 用了三个着色器程序一个用于图层合成一个用于滤镜链一个用于最终输出到屏幕。图层合成着色器接收下层纹理、当前图层纹理、混合模式、不透明度四个输入输出合成结果。滤镜链着色器接收输入纹理和滤镜参数数组按顺序应用每个滤镜。最终输出着色器负责把合成结果绘制到默认 framebuffer处理视口适配和色彩空间转换。第三步是 framebuffer 的管理。每个图层合成后需要写入一个离屏 framebuffer作为下一层的输入。这里用了双缓冲 乒乓切换的策略两个 framebuffer 交替作为输入和输出避免读写同一张纹理导致的未定义行为。framebuffer 的尺寸跟随画布尺寸画布缩放时同步调整。实测下来1080p 画布下六个图层的合成耗时在 8ms 左右留足了 60 帧的预算。// 创建离屏 framebuffer 的简化示例 function createFramebuffer(gl, width, height) { const texture gl.createTexture(); gl.bindTexture(gl.TEXTURE_2D, texture); gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, width, height, 0, gl.RGBA, gl.UNSIGNED_BYTE, null); gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, gl.LINEAR); gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_WRAP_S, gl.CLAMP_TO_EDGE); gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_WRAP_T, gl.CLAMP_TO_EDGE); const fb gl.createFramebuffer(); gl.bindFramebuffer(gl.FRAMEBUFFER, fb); gl.framebufferTexture2D(gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT0, gl.TEXTURE_2D, texture, 0); return { fb, texture }; }3.2 混合模式的着色器实现混合模式的着色器代码是整个项目里最需要仔细调试的部分。以柔光模式为例公式分两段当 blend 颜色小于 0.5 时result 2 * base * blend base^2 * (1 - 2 * blend)当 blend 大于等于 0.5 时result 2 * base * (1 - blend) sqrt(base) * (2 * blend - 1)。这个公式在纸上看着清楚写成 GLSL 的时候要注意向量运算和标量运算的混合base 和 blend 都是 vec3但 0.5 是标量需要显式写成 vec3(0.5)。调试混合模式有个笨办法但很有效用纯色图层做测试。底层放红色上层放蓝色切换不同混合模式看结果是否符合预期。我整理了一张对照表把每种模式的预期结果和实际结果对比很快就能定位问题。这个方法比对着公式一行行查快得多推荐你也试试。混合模式底层颜色上层颜色预期结果常见错误正常红蓝蓝Alpha 未处理导致偏紫正片叠底红蓝黑颜色空间未转换导致偏暗滤色红蓝品红公式符号写反叠加红蓝深蓝判断条件边界错误柔光红蓝暗紫分段公式衔接不连续注意混合模式的结果受颜色空间影响很大。如果发现混合结果和设计软件对不上先检查是不是 sRGB 和线性空间混用了。统一在线性空间计算最后转回 sRGB 输出结果最接近主流设计软件。3.3 参数曲线的实现与调节参数曲线是 artcraft 的一个特色功能。普通的滑块只能线性调节但很多参数比如对比度、饱和度的非线性响应更符合视觉直觉。曲线调节允许用户拖拽控制点定义参数输入到输出的映射关系。实现上用三次样条插值控制点数量限制在 2 到 5 个避免曲线过于复杂。曲线数据存储为控制点数组每个控制点有 x 和 y 两个坐标x 范围 0 到 1y 范围 0 到 1。渲染时把曲线采样成一张 256x1 的纹理着色器里用 x 坐标查表得到 y 值。这样做的好处是曲线求值在 GPU 上完成不占 CPU。采样精度 256 级对大多数场景够用如果觉得不够平滑可以提到 512 级纹理内存开销可以忽略。调节曲线的时候有个体验细节控制点拖拽要有吸附效果。当控制点接近水平或垂直对齐时自动吸附到整数网格方便用户精确调节。这个功能实现起来简单但用户反馈很好说“终于不用眯着眼睛对齐了”。吸附阈值设的是 0.02太大会影响自由调节太小又起不到吸附作用这个值是我试了好几次才定下来的。4. 常见问题与排查技巧实录4.1 渲染异常排查速查表做 artcraft 的过程中遇到的渲染问题五花八门我整理了一张速查表覆盖了八成以上的常见故障。排查思路遵循“从简到繁”的原则先检查参数传递再检查着色器编译最后检查 framebuffer 状态。大部分问题出在参数传递上比如 uniform 没更新、纹理没绑定、视口没设置。现象可能原因排查方法解决方案画面全黑着色器编译失败检查getShaderInfoLog修复着色器语法错误画面全白纹理未绑定或为空检查activeTexture和bindTexture确保纹理正确加载颜色偏暗颜色空间未转换对比 sRGB 和线性空间结果统一在线性空间计算边缘锯齿未开启抗锯齿检查antialias上下文属性开启 MSAA 或后处理抗锯齿帧率骤降图层过多或纹理过大用性能面板分析绘制调用合并静态图层压缩纹理导出尺寸不对设备像素比未重置检查导出时的devicePixelRatio导出前临时设为 1半透明边缘发灰Alpha 未预乘检查混合公式的 Alpha 处理预乘 Alpha 后再混合这张表是我踩坑踩出来的每一条都对应至少一次深夜调试。比如“半透明边缘发灰”这个问题我一开始以为是纹理过滤的问题换了各种过滤模式都没用后来才发现是 Alpha 预乘没做对。所以排查的时候先怀疑逻辑再怀疑配置能省不少时间。4.2 性能优化的几个关键手段性能优化是 artcraft 从“能用”到“好用”的关键。我总结了几个最有效的手段按投入产出比排序第一减少绘制调用。每个图层至少一次绘制调用图层多了调用次数线性增长。优化方法是把不常变动的下层图层预合成到一张纹理这样绘制调用从 N 次降到 2 到 3 次。实测下来十个图层的场景预合成后帧率从 30 提升到 60。第二纹理压缩。WebGL 支持压缩纹理格式如 ETC2、ASTC显存占用能降到 RGBA 的六分之一到四分之一。但压缩纹理的兼容性参差不齐需要做格式检测和回退。我的策略是优先用 ASTC不支持则用 ETC2再不行回退到 RGBA。这样在保证兼容性的前提下尽可能省显存。第三按需渲染。artcraft 不是每帧都在变的用户不操作的时候画面是静止的。所以渲染循环里加了一个“脏标记”只有参数变化或图层变动时才重绘。这个优化让静止状态下的 GPU 占用降到接近零笔记本用户反馈续航明显改善。提示性能优化不要凭感觉一定要用工具量化。Chrome 的 Performance 面板和 WebGL Inspector 是我最常用的两个工具前者看整体帧率和调用栈后者看着色器执行和纹理状态。优化前后各跑一次数据说话。4.3 跨设备兼容性踩坑记录跨设备兼容性是 artcraft 最头疼的问题没有之一。不同浏览器、不同 GPU、不同驱动行为差异大到让人怀疑人生。我挑几个典型的坑说说。第一个坑是浮点纹理支持不一致。某些移动设备不支持浮点纹理导致滤镜链里的高精度计算回退到低精度结果出现色带。解决方案是检测OES_texture_float扩展不支持时改用半浮点或整数编码。虽然精度损失一些但至少能跑。第二个坑是着色器编译时间过长。低端设备上复杂的片元着色器编译可能要几百毫秒导致首次渲染卡顿。我的做法是预编译着色器在应用启动时就把所有着色器编译好缓存起来。用户第一次操作时直接取缓存不用等编译。这个优化让首次交互的响应时间从 500ms 降到 50ms 以内。第三个坑是画布尺寸限制。某些设备对 framebuffer 的最大尺寸有限制超过限制会静默失败。artcraft 在初始化时会查询MAX_RENDERBUFFER_SIZE和MAX_TEXTURE_SIZE如果画布尺寸超过限制自动降级到安全尺寸并提示用户。这个检测很有必要不然用户看到白屏完全不知道发生了什么。5. 一些实操心得与后续扩展思路artcraft 做到现在我最深的体会是创意工具的核心不是功能多而是反馈快。用户拖一个滑块画面立刻响应这种即时反馈才是创意的催化剂。为了做到这一点我在渲染管线上做了大量优化把延迟压到 16ms 以内。实测下来用户的操作流畅度感知提升非常明显很多人反馈“用起来很跟手”。另一个心得是预设系统的重要性。artcraft 内置了二十多套预设覆盖常见的视觉风格。用户不需要从零调参数选一个预设微调两下就能出效果。预设的数据结构就是参数描述符的快照保存和加载都很简单。我建议做类似工具的朋友一定要把预设系统做扎实这是提升用户留存的关键。后续扩展方向有几个一是支持图层蒙版让合成更灵活二是加入简单的动画功能让静态图动起来三是开放插件系统让社区贡献滤镜和混合模式。这几个方向都在规划中但优先级要看用户反馈。我个人最想做的是蒙版因为很多用户问“能不能只让滤镜作用在局部”蒙版是刚需。最后分享一个小技巧调试着色器的时候把中间结果可视化。比如混合模式算出来的颜色不对可以把 base 和 blend 分别输出到屏幕看看哪个环节出了问题。这个方法比对着代码干瞪眼高效得多。我习惯在着色器里加一个debugModeuniform切换不同的调试输出定位问题非常快。
