NanoSVG实战：轻量SVG解析与光栅化接入指南

NanoSVG 是我这几年在嵌入式界面和轻量图形工具里反复用到的一个 SVG 解析与光栅化库。它不依赖任何第三方组件，核心就是四个文件：一对头文件和一对源文件，一个负责把 SVG 文本解析成内存里的场景图，一个负责把场景图渲染成 RGBA 像素缓冲区。整个库加起来几千行 C 代码，丢进工程就能编，编完就能用，不需要 libxml2、不需要 Cairo、不需要一堆图形栈的连锁依赖。

它解决的是这样一个具体问题：你手上有一堆设计师给的 SVG 图标，需要在小程序、上位机界面、嵌入式屏幕、离线批处理工具里画出来，但你不想为了几十个图标引入一整套渲染引擎。这时候 NanoSVG 就很合适——它不做网页排版，不做滤镜动画，不做字体渲染，它只干一件事：把路径和填充色变成一个个带透明度的像素。这篇文章面向的是需要自己动手把图标渲染链路搭起来的开发者，从选型判断、编译接入、API 拆解，一直到实际跑通和一个一个踩过的坑，我把这套流程完整过一遍。

1. 选型前的三分钟：NanoSVG 到底解决什么问题

1.1 一个解析器加一个光栅器，边界划得很清楚

我先把它的内部结构说清楚，因为这直接决定了它能干什么、不能干什么。nanosvg.h/nanosvg.c是解析层，内部自带一个手写的小型 XML 分词器，把 SVG 文本读进来，走一遍元素栈，最终产出一个NSVGimage结构体。这个结构体往下挂NSVGshape链表，每个 shape 再往下挂NSVGpath链表，每条 path 里存的是一串已经离散好的折线点坐标。注意这个「已经离散好」，是后面很多问题的根源，我在第六章会专门讲。

nanosvgrast.h/nanosvgrast.c是渲染层，它接收上面那棵场景图，按你给的缩放和平移参数，把每个 shape 的轮廓扫描转换成像素覆盖率，最后混合进你提供的缓冲区。这一层完全不管文件格式，也不管 XML，哪怕你手工构造一个NSVGimage结构体丢进去，它照样能渲染——这个特性在某些需要动态生成图形的场景下非常好用。

两层之间的接口是纯数据结构，没有回调、没有虚函数表、没有全局上下文。这一点我很看重，意味着你可以在解析完成之后自己接管整棵场景图，做裁剪、做变换、做缓存，甚至完全绕过内置光栅器，把路径点喂给别的渲染后端。

1.2 和主流方案摆在一起比，什么情况下别选它

很多人第一次接触 NanoSVG 会问：这和那些成熟的图形库比怎么样？我列个表，把常见的几类方案放在一起对照，你按自己的场景对号入座。

判断标准其实就一条：你要渲染的东西是「图标」还是「文档」。设计师导出的单色或多色图标、简单的品牌标识、UI 里的小图形，NanoSVG 的覆盖率在九成以上。一旦你的 SVG 里出现clipPath、mask、filter、pattern、text、<use>引用展开，或者依赖 CSS 类选择器控制样式，那基本就超出它的能力边界了，老老实实换方案，硬啃只会把自己耗进去。

我个人的经验是：先用 NanoSVG 试渲染一批目标素材，把渲染不出来的挑出去单独处理，剩下的走统一链路。这个「先摸底再定方案」的动作，比一上来纠结选哪个库有用得多。

注意：NanoSVG 的设计目标是「正确渲染常见的图标 SVG」，不是「完整实现 SVG 规范」。评估阶段一定要拿真实的素材库去跑，别看示例图跑通了就下结论。

2. 十分钟接入：从源码到能编译的第一个目标

2.1 文件清单和放置方式

仓库里你真正需要的就四个文件：nanosvg.h、nanosvg.c、nanosvgrast.h、nanosvgrast.c。示例目录和测试素材可以不要，我一般只把这四个文件拷进工程的third_party/nanosvg/下面，目录层级浅一点，后面写构建脚本的时候省事。

有一件事必须提前说清楚：NanoSVG 不是 header-only 库。它是传统的「头文件声明 + 源文件实现」结构，.c文件必须参与编译，不能只把头文件 include 进来就完事。这一点和那些单头文件库不一样，第一次用的人经常在这里卡住，报一堆 undefined reference。我见过不止一个人以为漏了什么宏开关，实际上是压根没把nanosvg.c加进编译列表。

放好之后，头文件搜索路径指向third_party/nanosvg，源文件加进编译单元，就这两步。

2.2 三种接入方式的取舍

第一种，直接塞进现有工程。如果你的工程本身就是一堆.c文件裸编译，没有构建系统，那就把两个.c文件加到编译列表里完事，零配置成本。适合单人小工具、临时脚本、教学示例。

第二种，编成静态库。工程规模大一点，或者有多个可执行目标共用这个库，我建议单独编一个静态库，避免每个目标重复编译，也让依赖关系更干净。

add_library(nanosvg STATIC third_party/nanosvg/nanosvg.c third_party/nanosvg/nanosvgrast.c ) target_include_directories(nanosvg PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/third_party/nanosvg ) target_compile_definitions(nanosvg PUBLIC NANOSVG_ALL_COLOR_KEYWORDS)

这里顺手加了一个编译宏NANOSVG_ALL_COLOR_KEYWORDS，原因后面 2.3 会说。另外我习惯把它编成 C 语言目标而不是 C++，避免某些平台上 C++ 编译器对 C 代码的严格类型检查引发额外告警。

第三种，C++ 工程接入。NanoSVG 是纯 C 写的，C++ 里链接需要处理名字改编。稳妥的做法是用extern "C"把包含语句包起来：

extern "C" { #include "nanosvg.h" #include "nanosvgrast.h" }

我用过的一些版本里，头文件本身已经带了extern "C"保护，包一层也不会有副作用；但如果你遇到链接期符号找不到，先检查这里。这个检查动作花不了十秒钟，能省掉半小时的疑惑。

2.3 编译宏：那个容易被忽略的颜色关键字开关

NANOSVG_ALL_COLOR_KEYWORDS这个宏值得单独拎出来说。SVG 规范里有一套完整的 CSS 颜色关键字表，一百多个名字，从常见的 red、blue、black，到冷门的 gainsboro、mediumaquamarine。NanoSVG 默认只编译进去一部分常用的关键字，目的是省几十字节的常量表——毕竟这个库的设计哲学就是抠门。

问题在于，设计师导出的 SVG 里经常出现fill="gainsboro"这种写法，你不开这个宏，解析出来就是透明，图形直接消失，而且不会报任何错。我第一次遇到的时候盯着代码看了半天，最后才发现是颜色名没被识别。

注意：这个宏必须定义在所有nanosvg.c编译之前，也就是通过构建系统的编译定义传进去，而不是在某个源文件里#define。否则因为编译单元不同，行为会不一致，排查起来极其难受。

除了这个宏，还有几个可选项跟具体版本有关，我这里不逐个列举——不同分支上的宏名字和默认值有差异，照着我写的抄反而可能编译不过。我的做法是打开nanosvg.h开头那几十行，把里面的#define区块从头到尾读一遍，通常五分钟内就能知道你这版有哪些开关。这比看任何教程都可靠。

3. API 逐个拆：解析、场景图、光栅化三段链路

3.1 解析入口和那三个参数

解析入口有两个，功能上是一回事：

NSVGimage* nsvgParse(char* input, const char* units, float dpi); NSVGimage* nsvgParseFromFile(const char* filename, const char* units, float dpi);

第一个吃字符串，第二个吃文件名。注意第一个参数是char*而不是const char*——这是个历史遗留的类型签名的瑕疵，函数内部并不会修改你的缓冲区，传进来之前强转一下就行。

关键在于后两个参数，很多人在这里理解错，导致渲染尺寸不对。

units是「你希望 SVG 里那些不带单位的裸数字用什么单位解释」。比如 SVG 根节点写width="24"，没带单位，你传"px"，那就理解成 24 像素；你传"mm"，就理解成 24 毫米，然后按 dpi 换算成像素。设计师导出的图标绝大多数是隐含像素的，所以传"px"是常态。

dpi只在遇到物理单位时才起作用，用来把 pt/mm/cm/in 这些换算成像素。换算关系是标准的一套：

举个具体的：一个 SVG 写了width="10mm"，你传dpi = 96，那么解析出来的image->width就是 10 × 3.7795 ≈ 37.795。如果你传dpi = 192（模拟高分辨率输出），同一个文件解析出来就是 75.59，等于把整张图放大了一倍。这个机制挺方便，做高倍率导出的时候不用改 SVG 源文件。

em、ex这类依赖字体上下文的单位，NanoSVG 没有字体信息可用，只能按默认值近似，我建议看到这类单位就直接要求设计改稿，别指望它能算对。%依赖父容器尺寸，在根节点上使用同样不可靠。

3.2 场景图结构：三个结构体决定了你能拿到什么

解析返回的NSVGimage是整棵树的根，结构大致是这样：

typedef struct NSVGimage { float width; float height; NSVGshape* shapes; } NSVGimage;

width和height是换算后的画布尺寸，单位是像素。注意如果 SVG 只写了viewBox没写width/height，这个值会从 viewBox 推出来。

NSVGshape是每个图形元素，字段多一些，我把实际会用到的挑出来：

NSVGpath里面最关键的是pts和npts：pts是一个长度为npts * 2的 float 数组，按 x0,y0,x1,y1… 这样交错存放；closed表示路径是否闭合。所有二次和三次贝塞尔曲线在解析阶段就已经被展平成折线了，所以你拿到的点直接用直线连起来就是完整轮廓。

这个设计让我很舒服的一点是：你可以完全不用它的光栅器。拿到这串点，你可以喂给自己的三角化器、可以塞进 GPU 顶点缓冲、可以做碰撞检测、可以算路径长度。这一点在游戏和交互场景里价值很大。

3.3 光栅化接口和坐标变换的坑

渲染层就三个函数：

NSVGrasterizer* nsvgCreateRasterizer(void); void nsvgRasterize(NSVGrasterizer* r, NSVGimage* image, float tx, float ty, float scale, unsigned char* dst, int w, int h, int stride); void nsvgDeleteRasterizer(NSVGrasterizer* r);

重点在tx、ty、scale这三个参数。变换顺序是先缩放后平移，也就是最终像素坐标 = 原始坐标 × scale + (tx, ty)。这个顺序不是随便定的，很多人在做居中显示的时候按「先平移再缩放」去算，结果图形飞出画面，还以为是 bug。

举个实际计算：一张 24×24 的图标，要渲染到 96×96 的画布上并居中，缩放比 4 倍，渲染后尺寸是 96×96，刚好铺满，那scale = 4.0f, tx = 0, ty = 0。如果画布是 128×128，图标还是想在中间，那scale = 4.0f，居中偏移就是(128 - 96) / 2 = 16，tx = 16, ty = 16。

再看一个容易算错的：图标原始 24×24，你要 3 倍图，也就是 72×72，放到 100×100 画布居中。缩放后图标占 72 像素，居中偏移(100 - 72) / 2 = 14，所以scale = 3.0f, tx = 14, ty = 14。别写成tx = 12.5（那是按原始尺寸算的偏移量乘以 3 之前的数），这是最常见的笔误。

还有一个行为必须记住：nsvgRasterize是把结果混合进目标缓冲区，不是覆盖。也就是说，如果缓冲区里已经有内容，新图形会按 alpha 源覆盖规则叠上去。这个设计对多图层叠加很方便，但也意味着如果你不清空缓冲区就重复渲染，会得到一堆叠加的鬼影。第一次用的时候我在这上面浪费了半小时。

注意：stride是每行字节数，通常等于w * 4。但如果你的缓冲区是内存对齐的（比如某些图形 API 要求 4 字节或 16 字节对齐的行宽），那就要传对齐后的值。传错stride的表现是图像斜切，很容易识别。

4. 手把手跑通：一个完整的 SVG 图标渲染小程序

4.1 最小可运行代码

下面这段是我常用的骨架，去掉业务逻辑之后能直接编译跑。假设你已经有icon.svg放在同目录。

#include <stdio.h> #include <stdlib.h> #include <string.h> #include "nanosvg.h" #include "nanosvgrast.h" int main(void) { /* 1. 解析 */ NSVGimage* image = nsvgParseFromFile("icon.svg", "px", 96.0f); if (image == NULL) { fprintf(stderr, "parse failed\n"); return 1; } printf("canvas: %.2f x %.2f\n", image->width, image->height); /* 2. 准备输出缓冲区 */ int w = (int)(image->width + 0.5f); int h = (int)(image->height + 0.5f); if (w <= 0 || h <= 0) { nsvgDelete(image); return 1; } size_t bytes = (size_t)w * (size_t)h * 4u; unsigned char* pix = (unsigned char*)malloc(bytes); if (pix == NULL) { nsvgDelete(image); return 1; } memset(pix, 0, bytes); /* 必须清空，见 3.3 的说明 */ /* 3. 光栅化 */ NSVGrasterizer* rast = nsvgCreateRasterizer(); if (rast == NULL) { free(pix); nsvgDelete(image); return 1; } nsvgRasterize(rast, image, 0.0f, 0.0f, 1.0f, pix, w, h, w * 4); /* 4. 此处 pix 里就是 RGBA 像素，交给你的编码器 */ nsvgDeleteRasterizer(rast); nsvgDelete(image); free(pix); return 0; }

编译命令大概长这样：

cc -O2 -o svgrender main.c nanosvg.c nanosvgrast.c -lm

注意最后那个-lm，NanoSVG 内部用了sqrtf、fabsf这些数学函数，漏掉会报一堆未定义符号。Windows 上 MSVC 一般不需要显式链接数学库，但 GCC/Clang 环境基本都要加。

image->width加 0.5 再取整，是我做四舍五入的习惯写法。因为解析出来的尺寸经常是 23.999 这种浮点误差值，直接截断会得到 23，少一个像素。这个细节在小图标上特别明显，一行像素的差异肉眼能看出来。

4.2 输出到 PNG

NanoSVG 只管生成像素，不管文件格式。要落地成 PNG，我一般接一个单头文件的无损图像编码库，几行代码就搞定：

#include "stb_image_write.h" stbi_write_png("out.png", w, h, 4, pix, w * 4);

这里第四个参数是通道数 4，最后一个是每行字节数，和nsvgRasterize里的stride保持一致。

有个细节：NanoSVG 输出的像素是非预乘 alpha的直通 RGBA，直接写 PNG 完全正确。但如果你要把这堆像素喂给某些 GPU 纹理上传接口，那些接口往往要求预乘 alpha，就得自己过一遍：

for (size_t i = 0; i < bytes; i += 4) { unsigned int a = pix[i + 3]; if (a == 0) { pix[i] = pix[i+1] = pix[i+2] = 0; continue; } pix[i + 0] = (unsigned char)((pix[i + 0] * a + 127) / 255); pix[i + 1] = (unsigned char)((pix[i + 1] * a + 127) / 255); pix[i + 2] = (unsigned char)((pix[i + 2] * a + 127) / 255); }

顺手处理了a == 0的分支，避免全透明像素留下残留色值，后面做双线性插值的时候边缘会渗出脏颜色。这个坑我在做图标图集的时候踩过，边缘一圈发黑，查了两天才定位到是透明像素的颜色没清零。

4.3 渐变填充的处理

NanoSVG 支持线性和径向渐变，但你需要自己读那几个字段。NSVGshape的fill和stroke是NSVGpaint结构，里面有个type字段区分四种情况：无色、纯色、线性渐变、径向渐变。纯色时color有效，渐变时gradient指针有效。

NSVGgradient里最关键的是xform，一个 6 个 float 的 2×3 仿射矩阵，用来把渐变坐标从用户空间映射到对象空间。这个矩阵是 NanoSVG 在解析阶段已经算好的，你直接拿来做坐标变换就行，千万别自己再乘一遍画布缩放。

我的做法是：既然内置光栅器已经能把渐变画出来，那就别自己搞。只有在你要走自己的渲染后端时才需要读这些字段，那时候把xform应用到你自己的着色器里即可。

注意：渐变停止点数组里每个 stop 的offset是 0 到 1 的归一化值，但顺序不保证严格递增，某些导出工具会写乱序。做插值之前先排一遍序，否则颜色会跳变。

4.4 想更高保真，就得自己接管

内置光栅器的抗锯齿是用亚像素覆盖率近似做的，不是解析式求交。对 UI 图标来说够用，但如果你要输出大幅面印刷图，或者要做 8 倍以上的高清导出，边缘的锯齿感和曲线的多边形感就会显出来。

想改善只有两条路。第一条是提高解析精度：因为曲线展平发生在解析阶段，容差是相对的，你可以在解析前把整个坐标系放大——比如把units换成物理单位再配一个很大的 dpi，让所有坐标数值变成原来的若干倍，展平出来的折线段数自然就多了。这个技巧挺取巧，但确实有效，我在做高分辨率导出时用过。

第二条是自己接管渲染：拿NSVGpath里的点做多边形三角化，走自己的光栅化。听起来简单，实际上要处理孔洞、要处理 fill-rule 的两种规则、要处理自相交，工作量比想象中大得多。除非你已经有现成的三角化模块，否则我不建议为了这个需求单独造一遍轮子。

5. 性能与内存：资源受限场景下的调优手法

5.1 别每帧都解析

这是我见过最高频的性能问题。有人在渲染循环里，每一帧都调用一次nsvgParseFromFile，理由是「怕文件改了」。实测下来，解析一个中等复杂度的图标，耗时是渲染本身的几十倍。

正确的做法是解析一次，场景图常驻内存，每帧只调nsvgRasterize。如果图标会变，用文件修改时间戳或者版本号做脏检查，变了才重新解析。

如果图标有多套尺寸（比如 1x / 2x / 3x），也没必要解析多份。NSVGimage是矢量场景图，和尺寸无关，一份数据配不同的scale参数渲染即可。这一点是矢量方案的天然优势，别浪费了。

5.2 光栅器的生命周期

NSVGrasterizer内部有可复用的临时缓冲区。如果你每次渲染都nsvgCreateRasterizer然后nsvgDeleteRasterizer，等于每次都重新分配一遍内存，在嵌入式环境里碎片化会很严重。

我的习惯是：一个渲染上下文持有一个光栅器实例，生命周期跟上下文一致。多线程场景下，每个线程各持一个，不要跨线程共享——这个库没有内部锁，共享实例会出问题。

内存池的做法也值得做。如果你的平台支持自定义分配器，可以在编译期把malloc/free替换成自己的池子，避免长时间运行后的内存碎片。NanoSVG 里所有堆分配都走了几个固定的入口，替换起来不难，具体位置就在那几千行源码里搜malloc，改动量很小。

5.3 几个实测下来值得注意的性能点

缓冲区大小是主要开销。渲染一张 1024×1024 的图，光缓冲区就 4MB。如果同时在界面上显示几十个图标，加起来就是几百兆。我的做法是按实际显示尺寸渲染，别用一个巨大的离屏画布做超采样再缩——那个流程的内存代价在嵌入式设备上基本不可接受。

scale 越大越慢，但不是线性的。因为覆盖率的计算量和像素面积成正比，而边缘处理量和轮廓长度成正比。所以放大渲染一个小图标到很大尺寸时，耗时增长会超过你的直觉预期。这种情况我一般限制最大渲染尺寸，超过就分块渲染再拼接。

复杂路径的展平成本在解析期一次性付出。一条带几十个贝塞尔段的路径，展平后可能有几千个点。这些点会一直占着内存。如果你的图标集很大，加起来的内存不容忽视，必要时可以在渲染完之后调用nsvgDelete释放，下次要用再解析——用时间换空间。

6. 踩坑实录：六个高频问题和排查套路

6.1 图形不显示，也不报错

这是最经典的问题，八成是下面三个原因之一。

第一，颜色关键字没识别，参考 2.3 节的编译宏。判断方法很简单：把 SVG 里的fill="gainsboro"手工改成fill="#d3d3d3"，如果图形出现了，那就是这个问题。

第二，opacity或画笔 alpha 被算成了 0。有些导出工具会写opacity="0"作为过渡状态的残留，直接看源码就能发现。

第三，flags里可见位没置上。某些版本的解析器遇到display:none或者空路径时会把可见位置零，你在遍历 shape 链表的时候要判断一下再渲染。

6.2 渲染出来缺了一块，或者镂空对不上

大概率是 fill-rule 的问题。SVG 里有两种填充规则：非零环绕和奇偶。同一组路径，两种规则下填充结果可能完全相反。NanoSVG 会把fill-rule属性解析到NSVGshape的fillRule字段里，如果你的渲染后端没读这个字段，默认按某一种规则处理，就会出问题。

我在处理带内部镂空的图标（比如带圆孔的齿轮、中间掏空的字母 O）时遇到过这个，表现是孔洞被填实了。解决方式就是在自己的填充逻辑里明确按fillRule的值走对应分支，不要默认。

6.3 描边的粗细和设计稿对不上

SVG 的stroke-width单位是用户坐标，会跟着整体缩放一起变。如果你按 1 倍渲染觉得刚好，放大到 3 倍就会觉得线太粗——这其实是正确的行为，因为矢量放大本来就该这样。

真正容易出错的是stroke-linejoin、stroke-linecap、stroke-miterlimit这几个属性。NanoSVG 会把它们解析出来，但内置光栅器对描边的支持是简化版的，某些尖角连接的处理和浏览器渲染有细微差别。如果你的图标依赖很精细的描边效果，建议在设计阶段就把描边转成轮廓（也就是「轮廓化描边」），导出成纯填充路径，这样任何渲染器的结果都一致。

6.4 一个大表格把常见现象串起来

6.5 不支持的 SVG 特性，提前列个清单

与其等到渲染出错再一个一个试，不如一开始就把常见的不支持项列出来，跟设计侧对齐产出规范。

• 滤镜：模糊、阴影、色彩矩阵，全部不支持。
• 蒙版与裁剪路径：mask、clipPath不会被应用，图形会完整画出来。
• 图案填充：pattern不支持，会退化成透明或纯色。
• 文本：text元素不会渲染，因为库本身不带字体引擎。设计稿里的文字必须转曲。
• 引用展开：<use>、<symbol>的展开能力有限，不同版本表现不一，别依赖。
• CSS 类选择器：内联的style属性支持，外部的<style>块和类名大概率不生效。
• 动画：animate系列完全不处理，只渲染静态首帧。

我的建议是给设计侧出一份「导出规范」：单色或多色填充、描边尽量轮廓化、文字必须转曲、不要用滤镜和蒙版、颜色用十六进制。这份规范一页纸，能避免后面大量的来回返工。

6.6 曲线精度那个坑，单独再说一次

前面提过但我还是想单独强调，因为它影响的是方案可行性判断，不是一个小 bug。

NanoSVG 把贝塞尔曲线展平成折线的动作，发生在解析阶段，容差是基于用户坐标系里的相对尺寸算的。这意味着：一张 24×24 的图标，解析出来的折线段数是固定的，跟你后面放大到多大渲染完全无关。你把它渲染成 24 像素，曲线看起来很圆滑；渲染成 2400 像素，同一个轮廓就暴露出明显的折线段。

我第一次遇到是在做一个导出工具，用户在界面上看小图标一切正常，点了「导出高清图」，输出一张 2048 的大图，边缘全是硬折线。当时以为是光栅器的抗锯齿问题，查了半天才反应过来是数据源头就那么多点。

解决办法前面 4.4 提过：在解析之前把坐标系数值放大。具体操作是把units传成物理单位，配合一个很大的dpi，或者更直接一点——在调用nsvgParse之前，对 SVG 文本做一个字符串层面的宽高数值放大。后者虽然土，但确实管用，我在一个不起眼的小工具里就这么干过。

判断你的场景会不会踩这个坑，很简单：算一下最终渲染尺寸和原始尺寸的比值，超过 8 倍就要警惕，超过 20 倍基本一定会看出来。这种时候就该考虑换方案，或者接受「高倍输出靠预放大解析」这个折中。

提示：如果你的产品要同时支持屏幕显示（1x~3x）和打印导出（300dpi 以上），建议把这两条链路的解析参数分开配置，别指望一套参数通吃。

7. 我把它放进工程时的几个固定动作

接手一个新工程，我要接 NanoSVG 的时候，基本会按固定顺序走一遍：先把四个文件拷进去，加编译定义，写一个最小 main 跑通单图标渲染，确认像素输出正确；然后拿真实素材库批量跑一遍，统计失败率，把渲染不出来的挑出来单独处理；最后把「解析一次 + 缓存场景图 + 每线程一个光栅器」这套结构固化到渲染上下文里，再谈优化。

这套动作做下来大概半天，之后这个库在项目里就基本不需要再动它了。它的稳定性和可预测性是我一直愿意用它最主要的原因——行为边界很清楚，出错的时候也总能定位到具体原因，不会出现那种「黑盒里不知道发生了什么」的情况。

真要给个建议的话：如果你的需求里出现了滤镜、蒙版、文字这三样中的任何一样，别在这个库上耗时间，它的定位从一开始就不在这儿。反过来，如果你只是要把一批设计好的图标在受限环境里准确、稳定、快速地画出来，那它可能是你能找到的最省心的选择之一。