一、为什么要出多档
移动设备按逻辑单位排版（iOS 的 point、Android 的 dp），实际渲染像素 = 逻辑值 × 倍率。48dp 的图标在 mdpi 上是 48px，在 xxxhdpi 上就是 192px。如果只给 48px，高清屏上系统会把它放大——放大就是糊。反过来只给 192px，低清屏白白多占 16 倍内存。所以要么出多档，要么就别嫌麻烦。
二、对照表（直接抄）
Android：密度桶五档
| 密度桶 | 倍率 | 48dp 图标实际像素 | 目录 |
|---|---|---|---|
| mdpi（基准） | 1.0 | 48 × 48 | drawable-mdpi/ |
| hdpi | 1.5 | 72 × 72 | drawable-hdpi/ |
| xhdpi | 2.0 | 96 × 96 | drawable-xhdpi/ |
| xxhdpi | 3.0 | 144 × 144 | drawable-xxhdpi/ |
| xxxhdpi | 4.0 | 192 × 192 | drawable-xxxhdpi/ |
iOS：三档 + App Store
| 用途 | @1x | @2x | @3x |
|---|---|---|---|
| App 图标（主） | 60 | 120 | 180 |
| 通知 | 20 | 40 | 60 |
| 设置 / Spotlight | 29 | 58 | 87 |
| Spotlight 大 | 40 | 80 | 120 |
| App Store 提交 | — | — | 1024（单独一张） |
Web / PWA / 桌面端
| 用途 | 尺寸 | 说明 |
|---|---|---|
| favicon（ICO） | 16 / 32 / 48 | 一个 .ico 文件里内嵌多个尺寸 |
| apple-touch-icon | 180 | iOS 添加到主屏 |
| PWA 图标 | 192 / 512 | manifest 里声明，512 用于安装屏 |
| OG 分享图 | 1200 × 630 | 社交平台分享卡片 |
小游戏与纹理链
- 小游戏包内资源：常见一档 64 → 512 递增（64/128/256/512），配合分包按需加载。
- mipmap 纹理链：从最大档开始每次除以 2，1024→512→256→128→64→32→16→8→4→2→1，尺寸保持 2 的幂。
三、源图该选多大
如果你要出到 @3x（180）和 xxxhdpi（192），源图就不能小于 192；有 512 更好。放大是凭空造像素，怎么缩都救不回来。能拿矢量（SVG/AI 源文件）就先导出一张足够大的位图再往下缩。
四、逐级减半到底有没有用
老经验说「512 缩到 64 要一级一级减半，别一步到位」，这个说法在现代浏览器里只对一半。我们实测过（源图 512 → 目标 40）：
- 低质量档（low）：逐级减半确实更干净，一步到位的混叠明显。
- 中/高质量档（medium / high）：浏览器自己已经做了多级降采样，逐级减半和一步到位结果都是 0 混叠——白花几倍时间。
所以要逐级减半的只有一种情况：你选了低质量档又要缩很多倍。其余情况直接一步缩就行。另外两个容易忽略的点：像素图放大必须用最近邻（用双线性插补会把 6 色调色板插出几百种颜色，像素味全没），缩小后要检查透明边缘（缩小时半透明像素会被平均，脏边有时反而在缩小后更明显）。
用 getImageData 读过源 canvas 之后，浏览器可能把它换到另一套后端，之后再测画质会拿到假数据。度量之前先克隆一份干净的副本，别拿被读过的那张去测。
五、ICO 打包要注意什么
- ICO 容器里每个尺寸内嵌的是 PNG 数据（不是 BMP），现代浏览器都认。
- 256×256 这一档在 ICO 头里宽高字节要写 0（0 在 ICO 格式里就代表 256），写 256 反而会被当成非法值。
- 一个 ICO 里塞 16/32/48 三档就够了，别把 256 也塞进去让它膨胀。
六、目录与命名
按平台分目录（drawable-xxhdpi/、Assets.xcassets），文件名用小写 + 下划线、只描述内容不描述尺寸（尺寸由目录承担）：icon_potion_red.png 而不是 图标_红色药水_144x144.png。带状态的用后缀：btn_ok_normal / btn_ok_pressed / btn_ok_disabled。
常见问题
只出一档 @3x，让系统自己缩，行不行？
能用，但不建议：低端机上白白占 9 倍内存，而且系统缩放的算法你控制不了，细图标容易糊或丢细节。出全档的成本现在几乎为零（一次批量导出就完事）。
Android 要出圆形图标和自适应图标怎么办？
自适应图标（Adaptive Icon）要分前景层 + 背景层两层各出一套，且前景内容要留出安全区（内容集中在中间 66% 左右，否则会被厂商的遮罩裁掉）。圆形图标只是遮罩形态之一，不用单独出图。
尺寸必须能被 4 整除吗？
不是硬性规定，但是好习惯：纹理压缩（如 ETC / PVRTC 的块对齐）和 mipmap 逐级除 2 时，能被 4 整除的尺寸不会在中途出现小数。九切素材和图标都建议这么做。
导出后要不要全部转 WebP？
看内容：色块多、渐变少的 UI 图转 WebP 常常能省 70%–90%，且 quality=1.0 走的是无损通道，对纯色/规则内容特别友好；照片和复杂渐变收益有限。先批量压一遍看每张的节省比例和差异度，再决定哪些转。