WebP 还是 PNG：图片资源的体积优化怎么做、改完怎么对比（自有应用篇）

先介绍主角。安卓修改大师智改工坊是一款 Windows 桌面工具：拖入安装包，用中文写一句需求，AI 去改 smali 与资源，改完自动回编、对齐、签名、校验，最后一键装到设备上看效果。介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

在"改包"这件事里，图片资源是最受欢迎也最容易出事的一类：受欢迎，是因为换图这件事人人都会判断好坏，改完立刻看得见；容易出事，是因为图片同时被三件事约束着——画质、体积、以及它在系统里的用法。同样是"把 PNG 换成 WebP"，换在开屏大图上叫优化，换在九宫格背景图或自适应图标上就叫灾难。

这篇分四块讲：格式怎么选（WebP 与 PNG 各自的脾气）、有损无损与颜色量化（画质是在哪一步丢掉的）、工具怎么处理这些图（图标密度选择机制 + 打包四步，以及体积变化的三笔账）、改完怎么对比（一份画质清单 + 一份体积清单）。最后配两个自有应用的实例。

一、先划两条线：自有素材，且能不动就不动

第一条线是权限。本文讲的图片优化，前提同样是自有版权或已获授权的应用——不只是代码和包，替换进去的图片素材本身也要是自有或已授权的。从网上随手存一张图替换进包里，画质再好也是另一个问题。这一点在图片类的改动里尤其容易被忽略，因为"换张图"看起来太无害了。

第二条线是克制。图片优化的收益是"包小一点、加载快一点"，而改坏图片的代价是"界面糊了、拉伸错乱、甚至回编失败"。所以本文给出的第一原则不是"能压就压"，而是：能不动就不动，能无损就别上有损，一次只动一类图。 把"哪些图不能碰"记清楚，比记住"哪些格式压得狠"更重要。

请勿把这个能力用到他人的商业应用上：请勿用于破解他人付费应用、绕过安全机制或未获授权的分发，这些都不在本文与工具的目标范围之内。本文所有实例用的都是自家应用与自有素材。

二、格式取舍：WebP 与 PNG 各自的脾气

先把两种格式的性格说清。PNG 是"无损守方"：它不猜你的像素，压缩靠的是逐行预测加通用无损压缩，画质与源文件逐像素一致；它支持完整的透明通道，代价是文件偏大——尤其是照片类内容，无损压缩比不过"允许丢一点"的编码方式。

WebP 有两副面孔，这是理解它的关键：一副是有损（基于帧内预测编码，同时支持透明通道），一副是无损（另有独立的无损编码）。有损 WebP 在照片、渐变、大块色域上的优势最明显；无损 WebP 与 PNG 比也能小一些，但优势没有照片场景那么夸张，而且在小图上偶尔会反过来变大——因为容器本身也有固定开销。

还有一个常被忽略的维度：安卓系统对 WebP 的支持是分阶段加进来的——先能解无损与有损，透明通道的支持更晚一些。所以动手前第一件事不是选格式，而是去看项目 config.ini 里的最低支持版本：最低版本偏低的应用，透明 WebP 要谨慎，有损/无损也建议先在一台老设备上验证一次。工具在建项目时就把最低与目标 SDK 解析出来写进了 config.ini，这个数字就是你的第一条约束。

图片类型	建议	理由
开屏图 / 引导页大图 / 照片	有损 WebP	内容连续、允许微小损失，收益最大的一类
纯色图标 / 线稿 / 小插图	无损 WebP 或沿用 PNG	边缘锐利、颜色少，无损即可；小图上 PNG 未必吃亏
带透明边缘的叠加素材	无损，慎用有损	透明边会在不同底色上暴露压缩痕迹
九宫格图（.9.png 结尾）	不要动	外圈 1 像素定义拉伸区域，换格式就毁了它
启动图标 / 自适应图标各层	按原格式替换	多档密度、前后景分层，格式一变容易漏档或错层
只有几十到几百字节的极小图	不要动	容器开销占比高，转换后可能反而变大

这张表的读法不是"照着格式选"，而是"先判断这张图被系统怎么用"。一张图是被拉伸的（九宫格）、被分层合成的（自适应图标）、被当作精确像素读的（分割线、点阵图案），它就已经不是"一张图"了，而是一段界面逻辑的一部分——这类图不在优化名单里。

还有一个与"用法"密切相关的维度：密度档。同一张图往往按 ldpi、mdpi、hdpi、xhdpi、xxhdpi、xxxhdpi 分别放在不同目录里，系统按设备屏幕密度选一张，再按比例缩放。所以"替换一张图"实际是"替换若干档同名文件"，而"改一张图"和"改一档图"是两件完全不同的事：只换了最高密度那一档，低密度设备用的还是旧图，于是出现"同一台设备上有的地方是新图、有的地方是旧图"的观感——这类问题在实例一里会再具体说一次。做图片优化时，把"各密度档一起处理"当成默认动作，能省掉很多"换完还是旧图"的困惑。

三、有损、无损与颜色量化：画质是在哪一步丢的

很多人把"画质变差"笼统归给"压缩狠了"，其实丢掉画质的动作有三种，特征完全不同。

第一种是有损量化与块效应。 有损编码按块处理，先把细节抹平再编码，所以它最容易在两个地方露馅：一是锐利边缘（文字、细线、图标轮廓）周围出现细碎的噪点；二是平坦区域（大片天空、纯色背景）出现淡淡的块状痕迹。降低质量参数会让这两处先坏，所以调参时别只看整图观感，要专门盯着这两处看。

第二种是无损里的"调色板降色"。 无损压缩本身不丢信息，但如果为了更小把真彩降成调色板（比如 256 色），那一步就是有损的——渐变会出现一圈圈色带，半透明边缘会因为无法表示中间色而出现灰边或硬边。很多人以为"选了无损就万无一失"，其实坑在这里。

第三种是抖动补偿。 为了掩盖色带，工具会加入抖动，用细密噪点模拟中间色。近看是噪点，远看是过渡——这是一笔明码标价的交换：观感回来了，体积和"干净的成分"都付出去了。所以判断一张图能不能量化，其实只要看三件事：颜色数量、有没有大面积渐变、有没有半透明过渡。截图、纯色图标、单色线稿通常可以；照片、渐变插画、带柔和阴影的素材通常不行。

怎么判断一张图"能不能被压"：三个观察点

判断方法不需要任何专业工具，用眼睛加一点耐心就够。第一看颜色数量：把图片放大到能看到像素级别，如果大片区域都是同一个颜色，说明颜色很少，这类图基本可以很安全地压缩；如果放大后到处是细微的色差过渡，那就是渐变，压低质量或降色都会出问题。第二看边缘的锐利程度：有明显描边、细线、小号文字的图，压缩痕迹会集中在这些地方，判断时要把视线放在轮廓线上，而不是放在画面中央那个吸引眼球的主体上。第三看透明与阴影：如果图片带半透明边缘或者柔和阴影，那它多半是要叠在别的背景上用的，这类图不仅要担心压缩，还要换两种底色各看一次——很多问题只在深色背景上出现，浅色背景上完全看不出来。

把这三个观察点连起来，就得到一个很实用的结论：越"脏"的图越耐压，越"干净"的图越怕压。 照片里有大量细碎纹理，丢掉一些几乎无人察觉；纯色图标、单色线稿、规整的渐变背景则恰恰相反，它们的"干净"本身就是观感的一部分，任何一点损失都会写成瑕疵。这也是为什么同一套压缩参数，用在大图上叫优化，用在小图标上叫事故。

两个常见误解：无损不一定更小，改扩展名不等于改格式

第一个误解是"无损就一定更小"。这件事在小图上经常反过来：一张几十字节的纯色小图标，本身已经接近无损压缩的极限，换成另一种容器还要额外背上一段文件头开销，结果就是"换了格式反而大了几十字节"。所以对极小图，最优解通常是"什么都不做"——省下的这点体积不足以抵消任何风险。

第二个误解更危险：把文件后缀改掉，不等于做了格式转换。 把 a.png 直接重命名成 a.webp，文件内容一个字节都没变，体积自然也没变；更麻烦的是，这类"名不副实"的文件在后续环节会误导判断——包括工具在挑选图标时按扩展名识别图片类型，扩展名与实际内容不符会让判断建立在错误信息上。正确做法永远是"用图像工具真正导出目标格式，再替换文件"。

四、工具是怎么处理这些图的：图标机制与打包四步

理解了画质怎么丢，再来看工具侧的两套机制。它们解释了"为什么界面上看到的图标有时会变、有时会消失"，也解释了"体积到底是怎么变化的"。

先说说反编译之后，图片资源长什么样。项目建好、反编译跑完之后，图片都在项目的反编译目录里，分成几类：按密度分目录的位图（常见的 mipmap 与 drawable 目录下，同一张图有几档）、九宫格图（文件名以 .9.png 结尾）、被 xml 描述的图形（矢量与形状定义，本身不是位图）、以及原封不动躺在 assets 里的文件（内置的帮助图、示例图常常在这里）。这四类的处理方式完全不同：第一类是优化对象，第二类与第三类不要碰，第四类要特别注意——assets 里的文件不参与系统的资源匹配，改它不会引起资源表变化，但会被应用按自己的逻辑读取，用错了地方就会"改了没反应"。

把这张"地图"记在心里，再看后面的机制就顺了：图标机制管的是"从包里哪一张图取出来给你看"，打包四步管的是"改完之后怎么把它重新变成一个能装的包"。

图标密度选择：只认 1~640，65534 是哨兵不是最高档

建项目时，工具用工作目录里的 aapt 解析包信息，其中图标一行会带出若干个密度档（形如 application-icon-640 后面跟一个资源路径）。这里有一个很值得说的细节：aapt 输出里存在一个特殊值 65534，它是"任意密度"的哨兵值，不是一个真实的分辨率档位。如果按数值简单排序，它会被当成"最高密度"而胜出——结果挑到的往往是没标密度的那一张小图。工具的做法是只接受 1 到 640 之间的密度档（640 是这里真实存在的最高档），把 65534 直接排除，然后在真实档位里取最高的那一张原图。

如果清单里给的图标路径指向的不是图片（自适应图标的图标入口常常是一个 xml，而不是 png），工具会退一步，在包里按名字与分辨率重新挑一张：优先 ic_launcher 这类命名，对 round、foreground、background 这几个关键词降权（它们是自适应图标的图层，不是完整图标），对 png 比 webp 略有偏爱，并对 mipmap 目录和各密度档加分。这套规则的意图很朴素：尽量取到"最高密度的那张完整原图"，而不是随便拿一张能显示的就交差。

还有一个细节对做图片优化的人特别有用：如果图标本身是 WebP，而这台电脑上没有对应的解码器，界面上会退化成文字头像，并在提示里说明原因——但原图仍然照存。也就是说，项目目录里的那份图标文件一直都在，你可以自己拿去做对比；"界面上看不到图标"只是显示层的事，不影响项目，也不影响打包。

把这两套机制连起来看，会发现一个一致的设计倾向：凡是"显示层"的判断失败，都不影响"数据层"的完整性。 图标解不出来就退回文字头像，反编译失败也只是提示原因并给日志路径——项目本身（配置、图标、原始包副本）早就落地了；等你把原因解决，接着在同一个项目上往下做即可，不需要从头再来一遍。对做图片优化的人来说，这条保证很实在：最坏的情况下你损失的是一轮时间，不是原始素材。

打包四步：体积变化的三笔账

改完之后，主窗口会自动跑固定的四步：回编（apktool b，把整个 apktool 工程重新打成 unsigned.apk）→ 对齐（zipalign -f -p 4，让包里未压缩的条目从固定边界开始摆放，其中 -p 针对未压缩的 .so 做页对齐，-f 允许覆盖已有文件）→ 签名（apksigner + testkey，密钥就在工作目录根目录下，可替换）→ 校验（apksigner verify --print-certs，读出证书信息）。产物统一落在项目目录的 build 子目录里，未签名、已对齐、已签名三个中间件都在，全过程写进项目目录下的 pack.log。

多出来的第四步不是流程洁癖：前三步只看退出码，而"到底签没签上"要 verify 说了算——万一密钥格式不对，只有这一步会明确报出来。也正因为有这一步，"这个包是不是可用的产物"才有了一份直接证据，而不是靠推断。

顺便把"对齐"这一步为什么值得单独占一格说清楚。包里有些条目是不压缩存放的（图片、音频、部分资源都很常见），系统在运行时更希望直接把文件映射进内存，而不是先整块拷出来再解压。要让映射成立，这些未压缩条目就得从固定边界开始摆放——对齐做的就是插入少量填充把它们"摆正"。所以它的体积效果通常是略微增大，换来的是运行时的读写效率。这也解释了一个常见的困惑：为什么"我明明删了几张图，包却没小多少"——中间可能混着对齐填充和重打包压缩差异这两笔账，第五章的体积清单就是为这件事准备的。

体积变化的来源	量级	说明
替换 / 转换后的资源本身	取决于你改了多少张图	唯一"由你决定"的一笔，也是优化收益的来源
重新打包带来的压缩差异	不可预测，可能正也可能负	回编是把整个工程重新打成包，不是"替换文件后重算差值"
对齐填充	KB 级	插入少量填充换取运行时可直接映射，通常略微增大
签名信息	KB 级	签名块是固定开销，与图片优化无关
打包标记	可忽略	每次出包前会往样式资源里写入一个 name="info" 的样式

这张表想说明的是一句话："替换文件省下的 KB"不等于"包小了同样多"。 所以比较体积时要用同一口径：拿项目目录里那份原始包副本（source.apk）的总大小，和改完后 build 目录里 signed.apk 的总大小对比；如果想看"纯资源"的收益，就直接比那几张图在项目目录里的前后大小。两种口径都成立，混着算就会得出"优化了但包变大了"这种自相矛盾的结论。

顺带说一句打包标记：每次出包之前，程序会往资源里的样式文件写入一个 name="info" 的样式（内容是把时间、账号、机器码等编码后的标记），它的写入策略很克制——文件不存在就先造一个空壳，没有这个样式就插在结尾标签前面，已经有就整块替换，写不进去也只记日志、不拦打包。这是这套流程里对"资源"动手的一个缩影：只做最小、可预期、可失败的写入。

五、改完怎么对比：一份画质清单，一份体积清单

图片类改动最怕的不是"改坏"，而是"改坏了没看出来，等用户反馈才发现"。所以对比这一步值得写成固定动作。

顺带说一句设备侧的便利：勾选"打包后自动运行"之后，手机走投屏到电脑、模拟器则把窗口提到最前面——图片这类"必须用眼睛判断"的改动，最理想的状态就是"改完立刻在眼前看到"。如果模拟器装了但没开，程序还会搜出安装路径问你要不要现在打开；设备没授权时会提示你去手机上点允许调试。这些小动作单看都很琐碎，但图片优化的迭代次数往往就是被它们决定的。

还有一个流程上的建议：一次只换一类图。 先把开屏、引导页这类"大而连续"的图换成有损 WebP，装机验证通过；再去动图标与线稿类的小图。如果一次把几十张图一起换掉，出问题时你无法判断是哪一类图、哪一种模式引起的——而图片问题的表现又常常很分散（某个机型糊、某个页面灰边），分批做能省掉大量的来回。

验证的第二步是留档。做法很朴素：改之前把要动的那几个页面各截一张图，改后再截一遍，两张放一起看。图片这类改动的好处是"能自证"——只要留下前后对照，任何人都能复核，而不是靠当时那句"我看着没问题"。如果你用的是分屏工作方式（左边主窗口写需求、右边看 AI 改动，两扇窗口高度相等、并排占屏），截图这一步会非常顺手：左边翻到需求与历史，右边停在改动结果，一次截完。

最后，别忘了历史里的那句话本身就是可复用的资产。这一轮的需求原话（比如"把开屏图与三张引导页大图转成有损 WebP，图标与九宫格不要动"）会被完整记进项目的修改历史，下次要给另一个版本的应用做同类优化，在历史里点一下「选择」把原话填回输入框，改掉文件名就能再跑一轮——这也是为什么图片类改动特别值得把"范围与禁区"写进原话，而不是只写在附件说明里。

六、两个自家应用的改包实例

下面两个例子都是我们自己的包、自己的素材，重点看"以前怎么做、现在一句话怎么做、改完怎么验证"。

实例一：给自家「记账助手」把开屏图与引导页大图换成有损 WebP。

以前的做法是一套手工流水线：先用图像工具把几张 PNG 大图另存为 WebP，然后对着包里的资源目录逐个密度档找同名文件替换（这一步最容易出错——同一张图往往有 mdpi 到 xxxhdpi 好几档，漏掉任一档，在某些机型上就会看到新旧图混用，或者被系统拉伸出锯齿）。替换完回编、签名、装机，再一页一页翻过去看效果；如果某张图糊了，就退回去调质量参数，整条流水线再走一遍。

现在一句话：把自家安装包拖进安卓修改大师智改工坊建项目，在需求框里写"把开屏图与三张引导页大图（清单里的这几个文件名）转成有损 WebP，分辨率与文件名保持不变，各密度档一起处理；图标、九宫格图和所有小图标不要改动"。再把新图作为附件加上，用途写清"这几张是新的开屏与引导页素材，同样是自有素材，请替换对应文件"——附件说明这一栏要求不少于 10 个字，就是为了让这类交代不必靠猜。

改完怎么验证？分三层：第一层看体积，拿项目目录里的原始包副本和 build 目录下的 signed.apk 比总大小，确认这一轮确实赚了；第二层看画质，勾选打包后自动运行，程序用 adb 找到设备、装上并拉起应用（拉起用的是 am start，装完还会复核一次前台应用是不是它，避免"装上了没起来"的误判），你按上面的画质清单翻一遍开屏与引导页，重点盯渐变的天空背景；第三层看"有没有漏档"，把应用切到不同分辨率的设备或镜像上再各看一眼。

实例二：给内部「巡检打卡」工具把 12 张内置插图统一压成无损 WebP。

这个内部工具里有一组 12 张的小插图，是"空状态""错误提示"这类页面用的，尺寸不大、颜色少、边缘锐利、有的还带一小行说明文字。它们不适合有损压缩——文字与细边是会先坏的部分；也不适合降色，因为里面有几处很淡的渐变底纹，一旦降色就会出现色带。

以前的做法是逐张另存、逐张检查，12 张图来回导三四遍，还常常在"这张到底有没有变糊"上纠结。现在一句话："把这 12 张插图（附件里的文件）统一转成无损 WebP，尺寸与文件名不变；不要改动图标、启动图与九宫格图。" 附件一次性加 12 个文件，每个都写清用途，程序会按"序号. 路径 —— 用途说明"拼好一起发出去。改完打包、装机，翻一遍这几个页面，确认细边与小字依旧锐利、底纹没有色带。

这个例子里还顺带验证了一个容易被误判的现象：如果某张图的格式属于这台电脑上没有解码器的类型，界面上的图标位置会退化成文字头像并给出一句说明——但这只是界面显示层的兜底，项目里那份原图照旧存着，不影响改动与打包。看到文字头像先别慌，去项目目录里确认文件在不在，比在界面上猜要快得多。

两个实例的共同点是：优化图片这件事的难点从来不是"转换"，而是"判断哪些能转、转完怎么确认"。 前者靠一张"用法决定格式"的判断表，后者靠两份清单（画质 + 体积）和一条能一键装机的验证链路。把这两件事做成固定动作，图片优化才能从"试试看"变成"可复现"。

七、用户评价：他们是怎么判断"哪些图不能动"的

八、结语：用法决定格式，清单决定质量

把这篇收成两句话：格式由"这张图被系统怎么用"决定——拉伸、分层、按像素读的图，一律不动；质量由"两份清单"决定——画质清单看渐变、透明、小字，体积清单只认一种口径。再叠加一条"一次只换一类图"的节奏，图片优化就从一件靠经验的事，变成一件可以交付给他人的流程。

如果只带走一个习惯，希望是这个：动手之前先把要改的图分一次类，分成"敢压"和"别碰"两堆，再决定格式与模式。分堆这件事花不了几分钟，却决定了后面每一轮迭代是在收敛还是在打转；很多"越优化越糟"的经历，问题都出在分类这一步被跳过了。

工具在这一环做的事，其实都是围绕"减少判断成本"：图标按真实密度档取最高密度原图（把 65534 这种哨兵值挡在门外）、界面显示不了就退回文字头像但原图照存、改完自动走回编对齐签名校验四步、最后一步 verify 打印证书、打包产物落在固定的 build 目录、需要时用 adb 装上并拉起应用让你当场看。你要做的，只剩把需求写清楚和把清单走一遍。

于是回到那句话：打开安卓修改大师智改工坊，拖入自家的包，说清楚"哪几张图、转成什么、哪些不要动"——只需说话，就能让应用变成你想要的样子。产品介绍页与下载入口：https://www.apkeditor.cn/ai-version.aspx（官网 www.apkeditor.cn）。