了解 Zipic 如何用 pngoptim 做 Mac PNG 压缩:稳定预设、APNG 处理、ICNS 工作流,以及可预期的批量结果。
pngoptim 是 Zipic 自研的 Mac PNG 压缩引擎。Zipic 之所以单独做它,是因为今天的 PNG 压缩早就不是「把一个 PNG 再压小一点」这么单一了。静态 PNG 要保住透明边缘和小字,APNG 要保住动画播放逻辑,ICNS 要在不破坏 macOS 图标容器的前提下优化内部 PNG 切片。通用 PNG 优化工具只能覆盖其中一部分,Zipic 需要一个能在 Mac 原生批处理流程里稳定处理 PNG/APNG 的引擎。
这是 pngoptim 系列的第三篇。第一篇讲 Mac 上压缩 APNG 和动态 WebP,第二篇讲 ICNS 文件压缩。这一篇讲产品层:Zipic 为什么需要自己的 PNG 引擎、常见工具的边界在哪里,以及为什么这些能力应该变成预设,而不是暴露成底层参数。
PNG 格式本身是无损的,但实际做网页图片优化时,很多 PNG 压缩都会先做一步有损处理:把 24-bit 或 32-bit RGBA 图像量化成 256 色以内的 indexed PNG,再写出更小的像素流。输出文件仍然是标准 PNG,只是颜色空间被简化了。
pngquant 长期是这类工作的参考工具。它的官网说明很直接:这是一个用于有损 PNG 压缩的命令行工具和库,最多能把文件压小约 70%,同时保留完整 alpha 透明。对于静态 PNG,它依然很强。
Zipic 要处理的范围更宽:
iconutil 拆开容器,再压缩其中的 PNG 切片;pngoptim 就是为这个范围做的。它在 Zipic 内部提供稳定的 PNG/APNG 压缩路径,并通过原生预设流程交给用户使用。
这几个工具覆盖范围有交集,但不是同一种东西。把它们混着说,PNG 工作流很容易乱。
| 工具 | 主要任务 | 更适合什么 | APNG 边界 |
|---|---|---|---|
| pngoptim | 有损 PNG/APNG 压缩 | 静态 PNG、APNG、Zipic 集成 | 按动画处理 APNG,而不是把它当成一组静态帧 |
| pngquant | 有损静态 PNG 量化 | 成熟的静态 PNG 减色 | 公开文档主要描述静态 PNG,没有描述动画感知处理流程 |
| OxiPNG | 无损 PNG 重压缩 | refilter、zopfli 类重压缩、元数据清理 | 官方 README 明确说 APNG 优化能力有限 |
| pngcrush | 无损 PNG IDAT 优化 | 尝试不同压缩等级和过滤方法 | 特定条件下可保留 APNG 动画块,但不会重压缩 APNG 动画数据 |
先把边界说清楚:有损减色和无损重压缩不是一回事。pngquant 和 pngoptim 可以先减少颜色数据;OxiPNG 和 pngcrush 保留像素,只是在 PNG 过滤器和 deflate 压缩参数里找更小的写法。静态 PNG 里这两类工具可以前后搭配。APNG 不能照搬这套流程,因为帧矩形、dispose、blend 和全局调色板都会影响最终动画。
对 Zipic 来说,真正重要的不是把底层工具展示给用户,而是这条 PNG 路径足够快、足够稳定,可以放进拖拽批处理流程里。
Zipic 不把 pngoptim 暴露成一排算法开关。大多数用户不需要管理底层压缩决策。他们需要的是选择压缩等级、添加文件,然后知道这一级大致会带来什么取舍。
| Zipic 关心什么 | pngoptim 帮 Zipic 做什么 | 用户看到的结果 |
|---|---|---|
| 视觉稳定 | 处理边缘、透明区域、渐变和小字 | 截图和界面素材仍然清楚 |
| 批量一致 | 用同一个预设处理一组 PNG | 一个文件夹不用逐张调参数 |
| 动画安全 | 把 APNG 当作动画处理 | 帧时序和播放效果保留下来 |
| 容器安全 | 让 Zipic 优化 ICNS 里的 PNG 切片 | App 图标仍是合法的 macOS 图标 |
| 质量保护 | 避免保留明显低于所选质量的结果 | 文件变小,但不该明显变坏 |
换句话说,pngoptim 做的是有损压缩。它不是一个保留所有原始颜色的无损重压缩工具。它会在体积和质量之间做受控取舍,并避免保留明显低于所选质量的结果。
Zipic 因此没有把所有底层参数直接放到界面里。大多数用户要的是稳定预设,不是十几个开关。
在 Zipic 里,pngoptim 通过预设控制:
Zipic 的流程仍然是先选预设,再添加文件。文件一添加就自动压缩,不需要额外操作。
APNG 已经进入 W3C PNG 第三版规范。规范把 acTL、fcTL、fdAT 三类动画块纳入 PNG,并保持向后兼容:不支持动画的 PNG 解码器会忽略这些附加块,只显示静态图。按 Can I use 当前表格,APNG 全球浏览器支持率是 95.46%,Chrome 59+、Safari 8+、Firefox 3+、Edge 79+ 都支持。
但支持率高,不代表优化简单。
直接逐帧压缩看起来最简单:把每一帧解出来,当作静态 PNG 压一遍,再拼回去。但这个方案会遇到几个问题:
pngoptim 是按动画处理 APNG 的。它会让整段动画使用一致的压缩策略,同时保留帧时序和播放行为;结构优化只会在确认动画仍然有效时保留。
这点和传统静态 PNG 优化器不同。OxiPNG 可以 refilter 和 recompress APNG 帧,但它自己的 README 也把这叫有限支持。pngcrush 在特定条件下可以保留 APNG 动画块,但 changelog 里的口径是保存这些块,而不是重压缩动画数据。对 APNG 来说,「不破坏动画」和「真正优化动画」不是一回事。
Day 31 那篇文章里说 Zipic 能压 APNG 且保留动画,原因也在这里:它不是「把很多 PNG 逐个压了一遍」,而是按 APNG 语义处理整段动画。
ICNS 这部分容易被说错。pngoptim 并不原生读写 ICNS,Zipic 负责容器层。
Zipic 的处理过程是:
iconutil 把 .icns 拆成 .iconset;iconutil 把优化后的切片重新打包成合法 .icns。这个区别不能省略。ICNS 是 macOS 图标容器,里面可能有老式表示,不一定全是 PNG。Zipic 通过 pngoptim 优化的是现代 ICNS 里占体积大头的 PNG 切片,尤其是 512×512 和 1024×1024 Retina 切片。说「pngoptim 支持 ICNS」不准确;准确说法是「Zipic 用 pngoptim 优化 ICNS 内部的 PNG 切片」。
完整容器拆解见 Mac 上 ICNS 文件压缩:格式结构与优化方法。
大多数人不需要知道引擎名字。Zipic 的使用流程刻意保持简单:
具体走哪个引擎,Zipic 会在后台处理:
有了这层路由,Zipic 才能一次处理混合文件夹。一个文件夹里有 PNG、GIF、JPEG、WebP、SVG、PDF、ICNS,你只需要选一次预设,Zipic 会按文件类型分配正确的引擎。
pngoptim 在 Zipic 里的价值,不是让用户再去管理一个命令行工具,而是让 PNG 压缩像 Zipic 的其他格式一样:用预设控制、能预览结果、能按文件类型自动路由。
如果任务是视觉检查、重复处理或混合格式,直接用 Zipic 更省事:
引擎留在工作流后面。你只需要选一次预设,Zipic 会判断每种文件该走哪条压缩路径。
如果你的 Mac PNG 压缩已经从一张图变成一整个文件夹,里面还有 APNG 动图和 App 图标,把这件事交给 Zipic 处理。下载 Zipic,设一个等级 3 的 PNG 预设,把文件夹拖进去即可。下载即享 7 天完整 Pro 体验。详见 价格页。

2026 年 Mac 上如何压缩 APNG 与动态 WebP——拆解两种格式的内部结构、何时优于 GIF,以及 Zipic 如何用自研 pngoptim 引擎完成优化。

Zipic 用 Google 的 libwebp 处理 WebP,但在发现 libavif 无法正确保留 iPhone HDR 照片信息后,自研了 avifoptim。两个截然不同的工程决策背后的逻辑。

gifski 是 Mac 上把视频转成 GIF 的好手,但它压不了已有的 GIF、不会批量处理、也不监控目录。本文讲的是 gifski 之外,Mac 上 GIF 工作流该靠谁。