自适应图标与图标分层：只换一张 PNG，为什么在各个启动器上长得不一样

先说清楚我们在讲什么。安卓修改大师智改工坊是一款 Windows 桌面工具，把"改 APK"这件事压成一句话：拖入安装包，用中文写需求，AI 改 smali 与资源，改完自动回编、对齐、签名、校验，最后一键装到手机或模拟器上看效果。它的介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

在所有改包需求里，"换个图标"是出现频率最高的一项 —— 它听起来也最简单：不就是把那张图换掉吗？可真正动过手的人都会遇到两个怪现象：明明把 PNG 换掉了，桌面上还是老图标；或者图标是换了，但在不同手机上形状完全不一样，一台是圆的，一台是圆角方的，还有一台边缘被啃掉了一块。这两个现象都不是玄学，它们来自同一段机制：Android 8.0（API 26）之后，图标从一个"位图"变成了"两层画布 + 一个由启动器决定的掩码"。

这篇按"先懂结构、再看工具、最后动手"的顺序讲四层：分层结构与掩码（为什么形状不由你决定）、包里的图标地图（四类资源谁在什么时候生效）、工具从包里挑图的机制（它凭什么替你选那一张）、素材准备与验证清单（怎么准备才不返工）。最后配几个自家应用的改包实例，把"以前怎么做 / 现在一句话怎么做 / 改完怎么验证"三步写实。

一、一张方图走天下的时代，在 API 26 结束了

要理解为什么会"换了没生效"，得先知道旧世界长什么样。在老版本 Android 里，启动器图标就是一张位图，尺寸基准是 48dp（对应 mdpi 48px、hdpi 72px、xhdpi 96px、xxhdpi 144px、xxxhdpi 192px 这一串密度档）。启动器拿到这张方图之后，只能整张缩放或裁切，没有别的选择。

于是就出现了一个很难看的问题：如果某个启动器想显示圆形图标，它只能拿刀去裁那张方图 —— 四个角被硬生生切掉，画面里原本贴着边的内容直接消失；如果应用自己提前画好了圆角，启动器再裁一次，就变成"圆角套圆角"的怪样子。同一张图，在每家启动器上出来都不一样，而且谁都没法保证好看。

Android 8.0 给出的解法叫自适应图标（Adaptive Icon）：不再交一张"成品图"，而是交两层画布，让系统去合成。这个设计的几个关键数字必须记住，因为它们直接决定你的素材该怎么切：

看懂了这四个数字，第一件违反直觉的事就成立了：图标的形状不由应用决定，而由启动器决定。启动器给一个圆形的掩码，你的两层画布就被裁成圆；给一个圆角方形，就裁成圆角方；给一个水滴形，就裁成水滴形。厂商还能在这上面叠加自己的视差和阴影。同一套前景/背景，在四台手机上呈现四种形状，这不是 bug，而是这套机制想要的结果。

由此也能推出第二件事：你在前景层里画的任何东西，都只应该画在中心 66dp 那个圆里。画到 72dp 的边缘已经在冒险，画到 108dp 的保留区则是白画 —— 那些像素永远不会出现在桌面上，只会在某些工具里被"看见"，然后让人误以为改错了。

一个反直觉的推论：自适应图标时代，"方形图标"这个说法本身已经不成立了。你交出去的是两层素材，桌面上那个形状是系统合成的结果；所以素材准备的第一原则是"内容收进安全区"，而不是"把角落填满"。

站在系统的角度回看这个设计，它的动机其实很朴素：把"形状"这件事从应用手里收回去，交给系统统管。以前每家应用自己画圆角，桌面上就是十几种圆角半径混在一起；现在大家交两层素材，由启动器按统一的掩码合成，同一台手机上的图标形状天然一致。厂商还可以在同一套掩码上做自己的形状，或者加视差与缩放动效 —— 应用不需要为每一家启动器单独出图。代价只有一个：应用失去了对最终形状的控制权，而这个代价正是本文后面所有"怪现象"的总根源。

顺便把一个常被混淆的单位说清：上面所有数字的单位都是 dp，不是像素。dp 是"密度无关像素"，代表的是物理视觉尺寸，系统会按屏幕密度把它换算成实际像素 —— 所以在 mdpi 上是 1 倍、hdpi 是 1.5 倍、xhdpi 是 2 倍、xxhdpi 是 3 倍、xxxhdpi 是 4 倍。这也解释了为什么同一张图标要准备好几档位图：不是为了"显得大"，而是为了让不同密度的屏幕都能有足够多的像素去呈现同一个视觉尺寸。如果你只提供一张 108×108 的图，在 4 倍密度的屏幕上它就得被放大 4 倍去显示，模糊是必然的。

二、包里的"图标地图"：四类资源，谁在什么时候生效

理解了机制，再回到包里看资源，就会明白为什么"只换一张 PNG"经常无效 —— 因为一个应用的图标在包里其实是一整套四类资源，你换哪一层，决定了哪个系统版本、哪家启动器会看到你的改动。

层	它在哪	谁在用它
声明	AndroidManifest.xml 里的 android:icon 与 android:roundIcon	所有系统与启动器；它只是"指路牌"，指向下面某一层
自适应声明	res/mipmap-anydpi-v26/ 下的 XML，内容形如 <adaptive-icon> 包着 foreground / background 两个引用	Android 8.0 及以上；只要它存在，现代启动器优先走这条路
密度位图	res/mipmap-mdpi … mipmap-xxxhdpi 下的若干张方图	Android 7.1 及以下的老设备；以及任何"不走自适应"的引用位置
图层素材	res/drawable 下的前景图 / 背景图（图片、矢量 XML 或一个纯色引用）	被自适应声明引用；前景要带透明通道，背景要能铺满且不透明

这张表能解释三种最常见的"换了没生效"：

1. 只换了密度位图，但系统走的是自适应声明。Android 8.0 以上的机器上，启动器看到 anydpi-v26 那份 XML 就按分层渲染了，你替换的 xxxhdpi 方图根本没被读取 —— 桌面上当然还是旧的。
2. 只换了一档密度。图标的位图往往是 mdpi 到 xxxhdpi 好几档。只换最高那档，高分屏没问题，低密度设备或某些把图标缩小后复用的场景仍会取到旧图。
3. 换对了但启动器有缓存。桌面图标列表是启动器自己维护的，覆盖安装后经常要等一次刷新（部分启动器要重启、或者把图标从桌面移除再加回）才更新。

两个容易被忽略的入口：roundIcon 与 monochrome

除了上面四类，包里还有两个"旁门"值得单独点出来，它们经常是"我明明换了呀"的真凶。

第一个是清单里的 android:roundIcon。它是给"想要圆形图标"的启动器准备的一个独立入口，指向的资源通常和 android:icon并不相同。只改了 icon 却忘了 roundIcon，结果就是"大多数启动器上是对的，某个启动器上还是旧的圆图标"。这也是为什么工具在按名字打分时，会给含 round 的候选扣 25 分：它是备选，不是首选 —— 但前提是你得知道它存在，才知道要一起处理。

第二个是 monochrome（单色层）。自适应图标的 XML 里除了前景和背景，还可以多一层单色素材，用来参与系统的主题化图标（把图标统一染成壁纸配色）—— 如果你的应用声明了它却不更新，系统在某些主题下就会用旧的单色图形去渲染，看起来"图标颜色莫名其妙不对"。它的规则很好记：单色层只用形状，颜色由系统给，所以别把带彩色细节的图丢进去。

顺带澄清一个共有的误解：桌面图标和通知栏小图标不是同一份资源。通知栏里那个小图标通常是单独声明的另一张图（而且要求是单色剪影，彩色图进去会变成一块白影）。改桌面图标不会连带改掉通知栏图标，反之亦然 —— 如果你的需求其实是"通知栏图标太丑"，要改的是另一个地方，别把桌面的资源反复替换十遍。

反过来说，一个靠谱的改包动作应该是成套的：前景层素材、背景层素材、anydpi-v26 的声明、各档位图，四处一起对齐。这句话人来做很烦，但对 AI 来说只是一条明确的指令 —— 这也是为什么"把图标换成附件里的新 logo"这种一句话需求，配上一份说清用途的附件，比手写十步操作更不容易漏。

三、工具怎么从包里替你挑出那张图：一段可以读懂的启发式

把包拖进安卓修改大师智改工坊的那一刻，程序要干的第一件事是"认包"：读包名、应用名、版本、最低与目标 SDK、启动页，以及从包里挑一张最能代表这个应用的图，显示在项目卡片上当头像。这件事比听起来难 —— 包里的图片有几百上千个，其中还有一大半根本不是图标。

第一手的依据来自工具链里的 aapt：执行 aapt dump badging 之后，输出里会有一串带密度信息的图标行，形如 application-icon-640:'res/mipmap-xxxhdpi/ic_launcher.png'，把每个密度档对应的图标路径都列出来。这里有一个必须点破的坑：

所以工具里的取舍写得很直白：只认 1 到 640 之间的密度值（640 是真实存在的最高档 xxxhdpi），在这个范围内取最大的那个。这样做的结果是"挑到分辨率最高、最清晰的那一档原图"，而不是被 65534 骗到 mdpi 去。

但如果 aapt 给出来的路径不是一张图片呢？自适应图标时代这种情况很常见 —— 它指向的可能是 anydpi-v26 里那份 XML，也可能压根没有可用的图标行（分包包、加密包尤其常见）。这时程序不会放弃，而是切到第二套逻辑：在包里按名字和分辨率打分，挑一个分数最高的。打分规则如下，建议完整读一遍，因为它精确地表达了"什么才像一张图标"：

线索	加减分	为什么
文件名以 ic_launcher 开头	+60	这是 Android 工程模板里图标的标准名字，命中率最高
名字含 app_icon / appicon	+50	自定义命名里最常见的写法
名字里含 icon	+20	弱线索，给个基础分；一条都不沾的直接跳过
名字含 round	−25	圆形变体是"备选"，不是首选
名字含 foreground / background	−30	这两层是自适应图标的"零件"，单独看都不是一个完整图标
扩展名 .png / .webp	+6 / +3	透明通道友好的格式优先
路径里含 /mipmap	+4	放在 mipmap 目录里，说明它就是按图标设计的
密度档（xxxhdpi 6 分…… ldpi 1 分）	× 4	同等条件下取分辨率更高的那一档

把这套规则连起来看，会发现它的性格很清楚：宁可在名字上猜错，也不要在层级上选错。一个"完整的、能当头像看的图"优先于一个"分辨率更高但只有半个图标"的图层 —— 这正是把 round、foreground、background 都扣分的原因。它也在为后面的动作服务：这张图会被原字节、原格式（png 就存 png，webp 就存 webp，扩展名跟着原格式走）存进项目目录，并记进 config.ini。也就是说，你后面在项目详情里看到的图标，就是包里的真图，不是重新画过的示意图。

为什么要有这套兜底：只信 aapt 会踩的三个空

看到这里有人会问：aapt 都已经把图标路径给出来了，为什么还要自己打分重挑一遍？因为实测下来，aapt 给出的那一行有三种情况都接不住：

1. 它指向的不是图片。自适应图标时代，清单里声明的图标可能就落在 anydpi-v26 那份 XML 上。XML 拿来当缩略图显示是没有意义的，这时必须回到包里去找真正的图层素材。
2. 它可能只给了低密度那档。尤其是被人手工裁剪过的包、分包包，图标行的密度信息不完整。如果只有一个 48×48 的 mdpi 图，把它放大当前头像就是一坨马赛克。
3. 它可能一行都没有。分包包、加密包、jar 这类文件本来就没有完整的清单信息，aapt 问不出东西。但用户仍然要建项目、仍然要看到一个能认出来的标识 —— 所以必须有第二套逻辑，而不是直接失败。

还有一个现实考虑：兜底逻辑必须只依赖文件本身。打分只看条目名字、路径、扩展名和密度档这几个字段，不需要解码图片、不需要联网、不需要额外的元数据。这让它足够快（几百上千个条目扫一遍是毫秒级的），也足够稳 —— 遇到再奇怪的包，最差的结果是"挑了一张不够理想的图"，而不是"整个导入流程卡住"。

这份稳健是有意做出来的，因为它要面对的包五花八门：正常的 apk 之外，还有分包包（apks / xapk / apkm）、加密包，甚至根本没有清单信息的 jar。这些文件解析不出包信息时，程序不会把它们拒之门外，而是以文件名继续建项目、并在页面上给一句说明。图标这件事同理：挑得到就显示真图，挑不到就让位给文字头像，但"能建项目、能改"这条底线不能被打破。对使用者来说，判断工具好不好的标准常常就在这些边角上 —— 顺利时不觉得有什么，遇到怪包时不卡住才显出差别。

还有一个诚实的设计值得单独说：如果挑中的是 webp，而当前系统没有对应的解码器，界面不会崩、也不会拿别的图顶替，而是退回一个文字头像，同时给一句说明；图标原文件照样存进项目目录，建项目和后续修改都不受影响。这类"降级但不断链"的处理方式，在一个要跟别人的包打交道、什么格式都可能遇到的工具里，比"追求完美显示"重要得多。

四、素材怎么准备：一张可以照着切的清单

原理讲完，落到最实际的问题上：设计给你的那几张图，哪张能用、要切成什么尺寸？下面这份清单按"先定基准、再算尺寸、最后避坑"的顺序排，照着做基本不会返工。

第一步：把 108dp 换算成像素

自适应图标的画布是 108dp，按密度换算成像素就是下面这张表。它的用法是：前景层与背景层都按"画布"那一列去做，内容压在"安全区"那一列里。

密度档	108dp 画布	四周各留 18dp	可视区 72dp	安全区 66dp
mdpi	108 px	18 px	72 px	66 px
hdpi	162 px	27 px	108 px	99 px
xhdpi	216 px	36 px	144 px	132 px
xxhdpi	324 px	54 px	216 px	198 px
xxxhdpi	432 px	72 px	288 px	264 px

实操上有个省事的做法：只做 432×432 那一档（xxxhdpi），其余档位交给工具按比例缩。因为图标是简单图形，缩放的失真通常看不出来，而人工去九个文件里对齐尺寸反而更容易出错。真正必须手工把控的只有一件事：主体内容有没有落在中心 264 px 的圆里。

第二步：三个不能违反的素材纪律

第三步：老设备要不要管

自适应图标只在 Android 8.0 及以上生效。如果你的应用还要覆盖 7.x 甚至更老的系统，那一套 48dp 体系的密度位图（mdpi 48 / hdpi 72 / xhdpi 96 / xxhdpi 144 / xxxhdpi 192）也必须一起更新，否则会看到"新机器上是新图标、老机器上还是旧图标"的割裂。判断标准很简单：看这个包的最低支持版本。如果最低版本已经不低于 26，理论上可以只维护自适应那一套；但只要低于 26，两套就得同时维护。

还有个细节值得知道：受版权与授权约束，我们只处理自己公司或团队拥有版权的应用与素材。上面这些数字是设计规范，不是可以随便往别人家应用上套的工具 —— 这一点在文章末尾还会再强调一次。

第四步：跟设计提需求时，把这份清单发过去

素材返工十次里有八次，原因不是设计画得不好，而是一开始没说清"要什么形式的东西"。下面这张清单直接抄给设计或外包同学，能省掉大部分来回。

这些要求听起来琐碎，但它们全都是从"最终会被掩码裁一次"这个事实推导出来的。告诉设计"为什么"，比告诉他"要什么"更管用 —— 知道那张图会被裁成圆形，他自然会主动把主体往里收。

五、三个自家改包实例：从"逐档替换"到一句话

下面三个例子都来自我们自己团队的应用，素材是自己设计的，验证是在自己的测试机上做的。重点看"以前怎么做 / 现在一句话怎么做 / 改完怎么验证"这三步的差别。

实例一：给自家「记账助手」换掉用了三年的旧图标

以前的做法是一条不短的流水线：拿到新 logo 后先切成若干密度档，反编译包，把 mipmap 各档的 ic_launcher 逐张替换 —— 这一步最容易翻车，因为漏掉任何一档，在某些机型上就会新旧混用；接着还要找到 anydpi-v26 那份 XML，顺着它去改前景层与背景层引用的素材，两边对不上时桌面上会显示一个"半成品"；然后回编、手动对齐、手动签名，最后 adb 装到测试机上看桌面。整套动作十几分钟，而且是在编辑器、命令行、文件管理器之间来回切的状态下做完的。

现在一句话：把自家安装包拖进安卓修改大师智改工坊，在需求框里写"把应用图标换成附件里的新 logo：前景用 logo.png，背景用品牌色纯色，自适应图标与各密度位图一起替换，低版本回落图也一并更新"，把设计给的前景图作为附件加进去，并把用途写清楚（附件这一栏要求说明不少于 10 个字，就是为了避免"这个文件是干什么用的"只能靠猜）。点「立刻修改」，需求原话会记进项目目录的 history.ini，正文送进右侧被吸附的 AI 窗口执行。

改完怎么验证：AI 在项目目录留下标志文件后，主窗口每 2 秒轮询一次、读到就自动弹出打包窗口，按回编、对齐、签名、校验四步跑完，产物落在项目目录的 build 子目录里（依次是未签名、已对齐、已签名三个中间件），全过程写进 pack.log。随后勾选"打包后自动运行"，程序会用 adb 找手机或模拟器，装上并拉起应用。桌面图标就是最终结果，不存在"资源改了但没生效"的盲区。额外做一步横跨验证：在启动器里把图标形状切成圆形再看一眼 —— 因为这时候你看到的是掩码裁切后的样子，安全区没留够的问题会立刻暴露。

实例二：给内部「巡检打卡」工具换成带"内测"角标的图标

这是公司内部给巡检同事用的工具应用。每次发内测包，同事装在私人手机上分不清哪个是内测版、哪个是正式版，所以这次要在图标上加一个"内测"角标，同时把应用名改成带后缀的版本。

以前的做法：设计出一张新图，人工把角标往右上角一贴就交出去 —— 结果在这台机器上角标完整，在那台机器上角标被切掉一半，因为角标压在画布边缘、正好落在掩码切掉的那一圈里。后来改成"先算安全区再贴角标"，但同一条经验要口头传给每个人，很难保证每次都记住。

现在一句话："在应用图标右上角加一个『内测』角标，角标必须落在自适应图标的安全区内（不要贴到画布边缘），同时把应用名改成『巡检打卡 内测版』。"这句话里最关键的不是"加角标"，而是括号里那句约束 —— 它把上面那条踩过坑的经验变成了需求的一部分。改完的验证方式和实例一一样：自动打包、自动装机、看桌面。

实例三：老包里的图标是 webp，换掉顺手把格式也理顺

第三个例子更小，但很典型：我们自己一个早期版本的应用，图标资源当初为了省体积做成了 webp。这次要顺手更新图标，同时希望格式回归 png —— 原因不是 webp 不好，而是在不同环境下它的解码支持不一致：工具这边缺解码器时会退回文字头像（原图照样存下来、替换不受影响），而某些老旧环境同样会显示异常。

以前的做法是：找到那几个 webp，用设计给的原稿重新导一遍 png，替换、回编、签名、装机，最后还得确认一遍"是不是所有引用都指向了新文件" —— 因为静态引用和自适应声明各指一处，改漏一处就是半新半旧。

现在一句话：把新素材作为附件加进去，需求写"把应用图标替换成附件里的 png 素材，并把图标资源统一替换为 png 格式"，用途说明里写清哪张是前景、哪张是背景。改完同样走自动打包 → 自动装机 → 看桌面。这件事的价值不在于省了多少步，而在于把"哪些引用要一起改"这种容易漏的事交给了执行方去兜。

三个实例做完之后回头看，值得总结的其实是一句话：图标这件事的难点从来不是"换图"，而是"换对那一套"。以前需要一个人记住"四类资源 + 四组数字 + 三个纪律"，现在需要的是把这份理解写进一句话里，让执行的一方去落实。人对人传经验会衰减，对机器说明确的约束则不会。

六、改完怎么确认"真的生效了"：三层确认法

图标改错最气人的地方在于：它看起来总是"好像生效了"。项目详情里的头像变了，你会有一种已经完成的错觉，但那个头像来自工具从包里挑出来的原图，它是不是被换过、换的是哪一层，跟桌面上显示什么并不等价。所以这里给一个三层确认法，从近到远，每一层回答一个不同的问题。

层	看什么	回答的问题
第一层：包里	项目目录下的工程资源、打包日志、最终产物的签名校验信息	"改动真的落进包里了吗？这个包确实签上了吗？"
第二层：桌面	装到设备上之后，桌面上那个图标的实际长相	"掩码裁切之后还好看吗？边缘有没有内容被吃掉？"
第三层：横跨条件	换启动器、换图标形状、换一台低密度设备、重启启动器清缓存	"换个环境会不会露馅？"

第三层是大多数团队会漏掉的一层，也是最容易发现问题的一层。比如"在某台机器上图标变成了一个白方块"，八成是前景层没有透明通道；"圆图标下四个角有脏边"，八成是背景层带了透明；"换了新图标但某一台还是旧的"，八成是启动器缓存或者老系统优先级走到了位图那一层。这些问题在只看一台设备的时候全都不会出现。

现象	最可能的原因	怎么确认
桌面上还是旧图标	改的是位图，系统走的是自适应声明；或启动器缓存	先看包里 anydpi-v26 那份 XML 的引用有没有一起更新；再把图标移出桌面重新添加
图标外面套了一圈白方块	前景层没有透明通道（白底被当成图形一起裁了）	在编辑器里把前景图放到深色底上看一眼，非图形区域应该全透明
圆形图标外圈有脏边	背景层带透明，或画布边缘有渐变	把启动器图标形状切成圆形再看；背景层改成不透明纯色重试
角标 / 文字被切掉一半	内容画到了可视区边缘，超出中心 66dp 安全区	量一下关键内容的包围盒，是否落在中心 264 px 的圆内
老机器上还是旧图标	只更新了自适应那一套，低版本回落位图没动	看这个包的最低支持版本是否低于 8.0；找一台老模拟器装上看
某一家的启动器上还是旧圆图标	清单里的 roundIcon 指向另一份资源，没一起换	搜一遍清单里的图标声明，看看有没有第二处引用

第一层确认之所以值得单独讲，是因为它是唯一能"在装到设备之前"给出确定答案的一层。工具这边的打包是四步：回编、对齐、签名、校验，产物依次落在项目目录的 build 子目录下，全过程写进 pack.log。其中最后一步校验不是摆设：前三步只看退出码，"到底签没签上"要校验说了算 —— 密钥格式不对这类问题，只有这一步会明确报出来。改图标改到一半卡住时，先看 pack.log 里是哪一步红掉的，比反复重装设备快得多。

七、用户评价：他们卡在哪一步，又是怎么绕过去的

八、结语：图标是一次资源替换，不是一次图片替换

把这篇收成一句话：自适应图标把"一张图"拆成了"两层画布 + 一个由启动器决定的掩码"，于是"换图标"这个动作的对象也变了 —— 你要换的是一整套资源：前景层、背景层、自适应声明、各档位图，四处对齐。理解了这一点，前面那些怪现象就都能解释了：换了没生效，是因为动的是不生效的那一层；形状各异，是因为形状本来就不归你管；边缘被裁，是因为内容没收进安全区。

把这份理解压进一句话，剩下的交给工具。这就是安卓修改大师智改工坊想做的事：只需说话，就能让应用变成你想要的样子 —— 左边写中文需求，右边即时改资源，改完自动回编、对齐、签名、校验，再一键装到设备上看桌面上的真实结果。图标该怎么切、密度该挑哪一档、65534 该怎么绕开，这些都不用你记。

产品介绍页与下载入口：https://www.apkeditor.cn/ai-version.aspx（官网 www.apkeditor.cn）。