翻到一个刚建 4 天的 .NET 图像库，代码还没人用过，但我读完了它全部源码 - 张善友 - 博客园

今天在 GitHub 上翻到一个挺有意思的仓库：ImageFacade。
它干的事情一句话能说清：让你在 SkiaSharp、OpenCvSharp、ImageSharp 和纯托管软渲染之间换后端，业务代码一行不用改。
干过 .NET 图像处理的都知道这个痛点有多真实。SkiaSharp 绑的是 Google Skia 原生库，OpenCvSharp 绑 OpenCV，ImageSharp 从 2.0 开始改成了商业许可证。三家的 API 长得完全不一样——换个库，Resize、画笔、文字排版、像素布局全得重写。要是哪天因为许可证、部署形态（容器、NativeAOT、不想带原生依赖）被迫换库，改动面就是整个业务层。
这个库的思路是把这些差异全部收进一个叫 IImageBackend 的接口后面，你平时打交道的只有 ImageEngine 和 FacadeImage 两个类。换后端？就换一行构造代码。
我花了一些时间把它的 README、三份设计文档（加起来 23 万字节）和核心源码读了一遍，重点看了它那个纯托管软后端 Sevencat.ImageFacade.SdcbSimdCodecs。这篇文章就是我的读书笔记。
先说结论：设计思路非常成熟，代码和测试都看得出功力，但这是个刚建 4 天、1 个 star、NuGet 下载量不过百的全新项目。 值不值得用，看到最后自己判断。
一般做这种抽象层的库，思路都是"某个后端不支持的功能，我帮你降级到别的实现"。ImageFacade 早期也这么干过，还设计了三种回退模式。
现在的规则简单粗暴：后端支持就原生执行，不支持直接抛 FeatureNotSupportedException，异常里带后端名和能力名。
初看觉得不近人情，细想其实很对。自动回退意味着你不知道哪次调用悄悄慢了十倍——本来在 GPU 加速的原生库上跑，一个不支持的操作就把整张图搬到软渲染那边画完再搬回来。性能特征全藏起来了，出了问题你都没法定位。
抛异常虽然丑，但行为完全可预期。调用之前查一下能力矩阵，或者上线前用 Capabilities 自检一遍，该换后端换后端，该绕开绕开。工程上这种"丑但诚实"的设计，我一般是加分的。
四个后端里我最感兴趣的是 SdcbSimdCodecs，也就是纯托管软后端。原因很简单：它是唯一一个同时满足零原生依赖、声明 NativeAOT 兼容、宽松许可证的全能后端。容器、CI、AOT 发布、甚至 browser-wasm，它都能跑，而且同一份输入在任何平台上输出的字节完全一样。
最上面是渲染层。 这里有个容易误解的点：包名叫 SdcbSimdCodecs，但渲染跟 Sdcb 一点关系没有。绘制、Resize、文字这些活儿，全部来自作者另一个项目 ImgProcSharp 的源码复制——大概 47 个文件，预乘 RGBA 画布、扫描线光栅化、8 种重采样核、自己写的 TrueType 解析和字形光栅化，一应俱全。而且不是那种"能跑就行"的玩具实现，预乘内核用了 Vector128 做 SIMD，一轮处理 4 个像素，还配了单元测试保证向量化路径和标量路径逐字节一致。
顺带一提，这个渲染层里的字体引擎被提升到了核心包，OpenCV 后端也借它画中文——所以 OpenCvSharp 不用 Cv2.PutText（那个 Hershey 字体只支持 ASCII）也能画出中文和半透明文字，这个坑填得漂亮。
中间是编解码基类。 它只引用 Sdcb.SimdCodecs.Abstractions 这一个包，自己不带任何编解码器。想读写什么格式，就引对应的 Sdcb.SimdCodecs.Xxx 包，启动时调用一次 RegisterCodec 注册。只存 PNG 的服务，就不用把 WebP、TIFF、JPEG 2000 的代码扛进包里。注册表是进程级静态的，幂等、线程安全、无反射，对 AOT 没影响。
这个"按需接入"的思路我很认可。甚至可以一个格式都不注册——绘制、Resize、文字跟编解码完全无关，照样是个功能完整的纯渲染后端。
最底下是 Sdcb.SimdCodecs，这才是这个包真正的编解码引擎，也是下一个话题。
软后端的编解码能力全部来自另一个库：Sdcb.SimdCodecs（MIT 协议，作者 sdcb 是 .NET 社区的老面孔了）。
这个库的口气不小：JPEG 解码是 libjpeg-turbo 的 0.82 倍耗时，而且 0 字节托管分配；PNG 是 libpng 的 0.88 倍；WebP 是 libwebp 的 0.53–0.88 倍。注意这是纯 C# 实现跑赢了对应的 C 参考库。
除了快，还有几个硬承诺：WebP 解码和 libwebp 逐字节一致，BMP 和 WIC 逐像素一致，无损 JPEG 2000 位精确。这种"可机械验证"的承诺比性能数字更让我放心——性能可以挑场景，字节一致性没法吹牛。格式覆盖也全：JPEG、PNG、TIFF、WebP、GIF、BMP、ICO、QOI、Netpbm、JPEG 2000、JBIG2，HEIF 单独成包（HEVC 有专利，用之前自己评估）。
当然，要泼点冷水：这些数字是作者自测的，单一机型（Ryzen 7 5800X 单线程），目前没有第三方复现。不过人家也老实——JPEG 2000 单核比 libopenjp2 慢一倍，照样摆在表里，没有选择性披露。
对软后端用户来说，这意味着一个很反直觉的事实：选软后端，解码环节不但不慢，可能比你走 OpenCV/Skia 的原生解码还快。 代价在渲染环节——绘制和 Resize 从原生优化实现换成了托管实现。
ImageFacade 的成本集中在像素进出边界——预乘转换、通道交换、stride 搬运。项目里有一份 planv2.md，记录了四批性能加固，附实测数据：
OpenCV 后端的 RGBA↔BGRA 通道交换，从逐像素标量循环改成按行 Vector128.Shuffle，1080p 从 2.26ms 降到 0.47ms；Skia 的去预乘导出，从"每像素三次整数除法"改成调 Skia 原生 API，从 30.8ms 降到 4.8ms。
优化完之后，1080p 的像素搬运压到了亚毫秒到几毫秒。对照 1080p 解码本身的毫秒到十几毫秒，抽象税大概在个位数百分比。这个税，交得起。
真正要小心的反而是用法层面的坑：每帧重复 FromPixels（BGR24 转 RGBA 标量路径要 3–6ms）、每帧新建张量缓冲（4.9MB 直接进大对象堆）、在 OpenCV 后端上用半透明标签底导致绘制抛异常。这些 README 和 misc.md 里都写了，看得出是踩过的。
读文档的过程中，有几个细节值得单独拎出来。
防解压炸弹。 LoadOptions.MaxPixels 默认 1 亿像素，门面内置了一个头部嗅探器，PNG/JPEG/BMP/GIF/WebP/TIFF 都能在不分配像素内存的情况下读出声明尺寸。一个 20KB 的 PNG 说自己是 30000×30000，直接拒绝，不会先傻乎乎分配 3.6GB 再报错。流式加载还有独立的字节数上限，超限就停读，不会把整个请求体吞进内存。这种输入安全意识，同类库里不多见。
三态半透明检测。 "这张图带不带 alpha 通道"和"这张图里到底有没有半透明像素"是两码事——不透明 PNG 也带 alpha 通道。库用 bool? 区分：加载时顺手扫一遍（1080p 约 0.2–0.4ms，零分配），结论缓存住；已知全不透明的图存 JPEG/BMP 时，直接省掉"建新帧、拷像素、逐像素合成背景"整段工作。JPEG 这种没 alpha 通道的格式，一个字节都不扫。绘制会让缓存失效，但绝不瞎猜。
内置中文字体。 核心包嵌了文泉驿微米黑，容器里没有系统字体也能画中文。用过 SkiaSharp 在 Linux 容器里画中文的都知道这有多痛。
文档里连被否决的方案都留着。 misc.md 里有一节专门记录"为什么不用 Skia 当回退后端""为什么不把 ImgProcSharp 做成 NuGet 依赖"，每条都有理由。还有一句 clean-room 声明：没反编译、没逐行对照过任何第三方实现。这种文档文化，说实话比代码本身更能说明作者的工程素养。
这项目新得发慌。 仓库 2026 年 11 月 9 号创建，我调研的时候是 13 号——满打满算 4 天，10 个提交，1 个 star，NuGet 各包下载量加起来几百次。没有外部用户，没有 issue，没有任何社区反馈。
版本号 0.3.x，API 没冻结。 而且 0.1 到 0.3 之间就干过把整个跨后端回退机制删掉这种大动作，后面再改什么都不奇怪。验收范围也窄：v1 只在 win-x64 上跑测试，Linux/macOS 只保证"能编译"。
AI 生成的痕迹比较明显。 设计文档里有大量"需求方指定""按用户要求改回"这种人机协作的措辞，根目录还残留着 .scratch.txt。作者另一个项目 OnnxSharp 干脆在 NuGet 描述里明说了"代码由 AI 编码代理编写，需求和评审来自维护者"。
我不觉得这算黑点——305 项测试、带实测数据的加固记录、对抗性验证（故意把优化后的代码改成抛异常，确认测试真的会红），这些评审痕迹都是实打实的。但你要清楚：文档里所有"实测"数字都出自作者一个人，没有第二双眼睛看过。 打算用的话，自己的关键路径上跑一遍基准，这是基本操作。
现在就可以玩：学习、原型、内部工具。特别是你有"零原生依赖、NativeAOT、确定性输出"这种硬需求，软后端几乎是这个交集里的唯一解。Apache-2.0 协议，实在不行 fork 了自己维护，软后端渲染层就 47 个文件，读得完。
再等等：要上生产的话，建议等 1.0 冻结 API、Linux/macOS 进了 CI、社区有第一批真实用户反馈之后。现在就想用也行，锁死版本号，跑自己的基准，优先选软后端或 Skia 后端（许可证最干净）。
别用：如果你的场景是核心基础设施，对长期维护保障有硬性要求，单作者、4 天历史、没有治理结构的现状过不了供应链审计。这种情况老老实实用 SkiaSharp 或 ImageSharp。
最后说句题外话。抛开"要不要用"这个问题，这个仓库本身就很值得读——23 万字的设计文档，从命名取舍到每个第三方库的坑（OpenCV 17 条、Skia 9 条、ImageSharp 12 条），全是一线实战才能攒出来的东西。就算你一行代码都不用，光是把 misc.md 读一遍，对 .NET 图像处理这块的理解也能上一个台阶。
仓库地址再贴一次：https://github.com/sevencat/ImageFacade
本文涉及的仓库信息与性能数据均来自项目公开文档与 NuGet/GitHub 官方接口，调研时间为 2026 年 11 月 13 日。