同一张图在小屏和大屏上为什么不一样：密度桶、DPI 与挑图机制

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

这篇文章处理一个几乎人人都会遇到、但很少有人讲透的问题：同一张图，为什么在不同设备上表现不一样？

典型现场有两个。第一个：把新 logo 做进去，自己的手机看着挺清楚，同事的平板上一放大就发虚，边缘像被磨过一遍。第二个更让人困惑：明明改了图标，装到自己机器上生效了，同事那台旧机器上却还是老样子 —— 于是开始怀疑「是不是没改干净」「是不是装错了包」。

这两个现场的原因都不在「改得对不对」，而在安卓处理图片尺寸的那套规则：图不是以「一张」的形式存在的，它是以「一组按密度分档的图」存在的；设备按自己的规格去取其中的一张，取不到就缩放。规则清楚了，你就能提前把素材准备到「任何设备都好看」，也能一眼看出问题出在哪一档。

一、密度不是「分辨率」：先把三个词分开

讨论图片适配之前，先把三个经常被混着用的词分开。它们说的是三件不同的事：

第三条是关键：安卓的布局单位是 dp（以及给文字用的 sp），它不是像素。换算关系可以记成一句话 —— 1dp 等于「当前密度 ÷ 160」个像素。在密度 160 的设备上，1dp 就是 1 像素；在密度 320 的设备上，1dp 是 2 像素；在密度 640 的设备上，1dp 是 4 像素。

于是「同一个按钮在两台设备上看起来一样大」这件事，是靠占用更多像素换来的。如果按钮上的图标只有一份 160 密度的图，那么在 640 密度的设备上，它就是被放大 4 倍使用的 —— 除非你另外给它准备了一份更密的图。这就是所有问题的源头。

行业里把密度归纳成几个「桶」，也就是常说的密度档。下面这张表以官方设计规范里的常用档位为例：

密度桶	密度值（dpi）	1dp 对应像素	启动图标参考尺寸
ldpi	120	0.75	36×36
mdpi	160	1	48×48
hdpi	240	1.5	72×72
xhdpi	320	2	96×96
xxhdpi	480	3	144×144
xxxhdpi	640	4	192×192

这张表最该记住的不是数字，而是一个比例关系：从 mdpi 到 xxxhdpi，像素数量差 16 倍（4 倍长 × 4 倍宽）。同一张图，在最高档设备上需要的像素，是最低档的十几倍 —— 只准备一份图，必然有一头的设备是在「忍着用」。

再补一层为什么会有「桶」这件事。安卓设备从入门机到旗舰机都有，屏幕尺寸与像素密度相差极大。如果只允许一种尺寸的图，那么所有设备都得缩放：低端设备浪费内存去加载远超自己需要的图，高端设备则被迫放大。于是系统把无限连续的密度归纳成有限的几档 —— 应用只准备几档，系统按设备实际密度就近取用。这是「用一点点缩放误差换取内存与安装包体积」的取舍，代价就是我们必须接受「不同设备取到的是不同的那一张」。

除了 dp，还有一个单位要认一下：文字用的是 sp，它和 dp 的关系是「在此基础上再乘一个用户设置的字号缩放系数」。这一点影响很实际：把界面上某个文字块的位置写死成像素，用户把系统字号调大之后，文字就会溢出、被裁掉或跟旁边的元素重叠。适配做得好的界面，不会因为用户换了字号而破相 —— 这也是「别写死尺寸」这条规矩的由来之一。

二、drawable 目录与密度桶：系统是怎么决定拿哪一张的

在反编译出来的工程里，图片资源是按目录分开放的，目录名就是它的「货架标签」：res/drawable-mdpi、res/drawable-hdpi，一直到 drawable-xxxhdpi；启动图标这一类通常放在 mipmap-* 系列目录里。

运行时，系统按一套「就近匹配」的规则取图，可以概括成三步：

还有两个常被问到的细节，一次说清。第一个：为什么图标建议放在 mipmap 目录而不是 drawable？ 因为启动器取图标的方式比较特殊 —— 它可能按自己的规格去取不同档位的那一张，mipmap 就是为这种「需要按密度取多份」的图标资源准备的目录，放在里面更符合系统的预期。

第二个：「缩放了会怎样」到底差在哪？ 图像放大是「无中生有」地把像素插值出来，天生会糊；缩小则是把像素丢掉，通常看不出糊，但精细的线条会丢细节（比如小字、细描边）。所以同一张低密度图，在小屏上「看起来还行」，往往正是因为它被缩小了、糊被藏起来了；一到高分屏上被放大，问题立刻现形。这就是为什么「我这里看着好好的」从来不是证据。

另外要理解「就近」这两个字的分量：系统并不要求你必须为每一个密度都准备资源，它只是按最近的那一档取。这意味着只做两档的包也能正常跑遍所有设备，只是有一部分设备在用缩放后的结果。工程的现实做法通常就是这样取舍的：给最常出现的几档准备原生尺寸，剩下的交给系统缩放。理解这一点，你就不会把「必须每个档都做」当成硬规则 —— 它是一条质量与体积之间的线，位置由你自己定。

三、工具替你挑图：aapt 的密度档、65534 哨兵与最高密度原图

在包里，图片资源的目录名就是它的用途与密度标签，常见的几类分别是：

目录写法	装什么	换图时的注意点
drawable-mdpi 等	按密度分档的普通界面图	要按档位一起换；只换一档会出现「部分设备没变」
mipmap-xxxhdpi 等	应用图标（启动器会按档位取）	图标建议留在这里；换成别处可能不被启动器取到
drawable-nodpi	不随密度缩放的图（原样使用）	放这里意味着「我就是要这个像素尺寸」，慎用
自适应图标（分层）	前景层 + 背景层，由系统裁剪合成	改图时要一起考虑两层，否则会出现「新图形配旧底色」

关于「版式本身怎么适配」，有三条朴素但有效的原则，可用来检查一次改动会不会在大屏上破相：一是能用相对单位就不用绝对像素（尺寸用 dp、字号用 sp，让它跟着设备的密度与用户的字号走）；二是让容器负责分配空间，而不是让每一块自己抢位置（用权重、比例这类「谁占几分之几」的写法，屏宽变了自动重排）；三是内容多的地方要能滚（小屏上放不下的东西，在大屏上也许刚好，但在更小的设备上必须能滚动看到）。

还有一种专门为「拉伸不变形」设计的图：点九图（nine-patch）。它把一张图切成九宫格，四个角不拉伸、四条边可以只在一个方向拉伸、中间区域双向拉伸 —— 于是同一个按钮背景，无论被拉多宽多高，圆角都不会变形。改包时如果替换的是这类图，必须保持它的可拉伸标记；直接把一张普通 PNG 换上去，圆角与描边就会跟着一起被拉扁。这属于「换图换对了、但换法不对」的典型。

讲清楚设备的取图规则之后，再来看工具这边——它会遇到一个很像但目的完全不同的问题：把包拖进来之后，列表里要显示一张应用图标，这张图该从包里挑哪一张？

注意这和设备的取图不是一回事。设备取图是为了显示；工具的挑图是为了展示 —— 目标是「在你的屏幕上看着清楚、不糊」，所以它要的恰恰是包里那张最清晰的。但「最清晰」并不等于「数字最大的那一个」，这里面有一个真实的坑。

过程是这样的：工具用工作目录里的 aapt 解析包信息，aapt 会把包里的图标按密度一条条报出来，形如 application-icon-640:'res/mipmap-xxxhdpi/ic_launcher.png' —— 一个密度对应一条。程序从这些行里挑密度最高的那条，直接去包里把原图取出来。

关键点在这里：aapt 的密度里有一个 65534 的特殊值，它表示「任意密度」，不是一个「比 640 还高的档位」。如果把 65534 当成最高密度去取，取到的往往是那张不分密度、尺寸很小的兜底图 —— 在界面上放大之后反而更糊。工具只认 1 到 640 之间真实存在的密度档，在真实档位里取最高的一张。 这一点是实测踩过坑之后写死的。

还有一条退路，也值得知道：aapt 报出来的路径并不一定是张图片。 有的包用的是自适应图标，那条路径指向的是一个 XML 描述文件，而不是图片本体。遇到这种情况，「直接取那张图」就走不通了，程序会退回到在包里自己找：按文件名与所在密度综合打分挑一张最像启动图标的 —— 名字以 ic_launcher 开头的最优先，app_icon 一类次之，其他带 icon 字样的再次；圆形版本的（round）会降权，自适应图标的前景层与背景层（foreground / background）扣得更多；格式上 PNG 比 WebP 略优；放在 mipmap 目录里的加分；最后再按所在密度档加权。

把这套打分逻辑翻译成人话就是一条经验：「哪张最像用户桌面上的那个图标，就选哪张」。它宁可绕开一个听起来更「高」的候选，也不给你一张看起来像半截图的图标。

这套做法背后的设计取向值得说一句：界面上的「像不像」，优先于实现上的「简单不简单」。 最省事的实现是「aapt 给的第一条就用第一条」，代码三行就写完了；但那样会在自适应图标、多种密度混排、WebP 兜底这些真实包体上翻车。多写这一段打分与判定的代价，换来的是「拖进来的包，界面上显示的图标就是用户心里那个图标」—— 对一个要反复导入各种包的工具来说，这笔账很划得来。

最后是格式这一层。包里的图标可能是 WebP 格式，而系统（Windows）不一定带对应的解码器。这种情况下的表现是：界面回退成文字头像（用应用名的首字母显示一个圆角色块），但原图照存不误 —— 图标文件仍然按原始格式完整地落在项目目录里。工具会明确给出一句说明，告诉你这是解码回退、不影响使用。理解这一点很重要：界面上的头像是「看」的问题，包里的资源是「改」的问题，两件事互不牵连。

到这里可以把两套「取图」逻辑并排放一次。它们经常被混为一谈，其实目标完全相反 —— 一个要最清晰，一个要最合适：

对比项	工具的挑图（为了展示）	设备的取图（为了显示）
目标	在你的屏幕上看着清楚	按自己的密度取最合适的一张
依据	包内各密度档的信息 + 文件特征打分	设备自身的密度，就近匹配
取哪一张	真实档位里最清晰的那一张（绕开 65534）	自己能取到的那一张，必要时缩放
你该关心什么	列表里那张预览图是否清楚	每一档是否都被换成了新图

看懂这张表，就能理解一个常被问的问题：「工具里明明显示的是新图标，为什么装到设备上还是旧的？」 因为工具显示的是「包里最清晰的那一张」，而设备取的是「它自己那一档」—— 如果那一档没被替换，设备取到的自然还是旧图。工具没有骗你，它只是回答了另一个问题。

四、改完之后为什么在大屏 / 小屏上表现不同：三个典型现场

把机制放到改包这件事上，绝大多数「为什么我这里好好的、你那里不对」都能归到三个现场里。

现场一：只替换了低密度那一档 —— 小屏清楚，大屏发虚

新图被放进了 mdpi（甚至更低）那一档，高分屏设备取不到自己那一档，只能把这张小图放大用。结果就是：小屏设备看着正常，大屏、平板、高分屏上看边缘发毛、细节丢失。症状特征是「图是对的，但不是所有设备上都清楚」。

现场二：只替换了最高密度那一档 —— 大屏焕新，小屏还是旧图

这个现场最让人怀疑人生：明明改了图标、也打包装机了，自己的新手机上是新的，同事那台旧机器上还是老样子。原因很简单：旧设备密度低，取的是低密度货架上的那一张，而那张还是旧的。 你只换了高密度那一格，等于只换了「一部分设备的图标」。

顺带提醒一句：这也解释了为什么「我在自己机器上看过了」不能作为验收依据。你自己那台设备只能证明它自己那一档被换对了。

现场三：图片换了，但版式没跟着变 —— 在大屏上被拉扁

还有一类问题与密度无关，属于「适配」：界面里某些位置写死了像素尺寸，或者图片被要求「填满这块区域」。同一张图在小屏上比例刚好，到大屏上为了填满就得拉伸，于是人看起来被拉扁了、变形了。这类问题的解决方向不是在图上下功夫，而是在版式与需求描述上 —— 要让「按比例显示」这件事被明确写出来。

现场四：自适应图标只换了一半 —— 新图形配着旧底色

还有一类图标问题只在某些系统版本上出现：图标是分层的（前面一层图形、后面一层底色），系统会把两层裁剪合成成最终形状。如果这次只替换了图形那一层，底色还是旧版的那块颜色，结果就是「图形是新的，气质是旧的」—— 甚至因为新图形的留白与旧底色不搭，看起来像两个图标叠在一起。

这也解释了工具在挑预览图时为什么对前景区分得那么细：前景层与背景层单独看都不是「完整的图标」，拿它当预览会让用户以为图标被改坏了。反过来讲，作为改包的人，遇到分层图标时正确的动作是把两层一起处理，或者明确要求「按原来的分层结构替换」。

五、使用技巧：素材怎么备、需求怎么写、改完怎么验

5.1 素材：至少给「最高那一档」，让系统往下缩

如果只能给一张图，就给最大的一张（至少按最高密度档的参考尺寸出图，条件允许就再大一档给余量）。理由是缩放的方向决定了观感：从大往小缩通常看不出问题，从小往大放几乎一定会糊。一张足够大的原图，在任何密度设备上都是「缩小使用」，这是最安全的一侧。

代价也要说清：只给一张大图，意味着低密度设备要花一点额外的缩放成本，包体也会略大。所以更讲究的做法是「一张原图 + 关键档位各出一份」——用原图保证质量上限，再用各档的小图照顾体积与效率。对内部工具类应用来说，把 mdpi 到 xxxhdpi 这几档补齐，已经足够覆盖绝大多数设备。

5.2 需求：把「替换范围」写出来，别只说「换图」

这是最容易被忽略、也最省事的一条。改图标的需求如果只写「把图标换成附件里的新 logo」，执行时就必须替你去猜「换哪几档」。把范围写清楚，结果会稳定得多：

这三条的共同点是：都说清了「换成什么」「换哪些」「要不要保比例」。 另外别忘了附件那一栏的用途说明（不少于 10 个字）——「这张图替换启动页背景，不要压缩」这类说明，正是让执行方不猜的关键。

5.3 验证：用两台不同密度的设备，各装一遍

验证这件事，一台设备是不够的。建议的做法是「一高一低」：一台高密度设备（手机或高分屏），一台低密度设备（旧手机或平板），各装一遍看三处 —— 桌面图标、启动页、以及应用里那块被你改过的区域。

工具这边把这一步做得很省事：打包完成如果勾了「打包后自动运行」，它会用 adb 找手机或模拟器、装上并拉起应用；手机走投屏到电脑（在电脑上看手机屏幕），模拟器则把窗口提到最前面。想看第二台，切到那台设备再跑一次「去打包」即可 —— 同一个项目、同一份产物，两台设备上对照的是同一个包，结论才干净。

如果你手边没有低密度真机，模拟器是最方便的替代：新建或切换一个不同分辨率的模拟器镜像即可（很多模拟器都能改分辨率与 DPI）。同一张图在两台模拟器上并排看一遍，「是不是所有设备都清楚」这个问题就有了答案。

5.4 素材本身的准备：命名、格式与「同一批只换一套」

素材进包之前，先在电脑上把它们整理成一批。三件事值得养成习惯：第一，按档位命名（例如一套图放在同一个文件夹里，文件名保持一致、只按目录区分档位），避免「同一个图标在大屏小屏上文件名不同」这种自找的麻烦；第二，格式统一（PNG 是无损的，适合图标与线条；JPEG 适合照片类的大背景；WebP 体积更小，但要确认工具与设备链路都能正常处理它）；第三，一次改一套 —— 图标换了，就顺手把启动页上的同一个 logo 也对齐，避免出现「桌面图标是新的、启动页还是旧的」这种半新半旧的状态。

至于「要不要压缩」：判断标准是它最终会被怎么用。会被放大使用的图（大屏上的全屏背景、高分屏上的图标）尽量不要过度压缩，宁可让安装包大一点；只在很小尺寸上显示的图，压一压反而更划算。拿不准的时候，一句「不要压缩原图」是最稳的需求写法。

5.5 别忘了「别人把字号调大了」这条分支

还有一个经常在验收里被漏掉的场景：用户在系统里把字体调大（很多长辈机、企业统一配置的机器都会这么做）。字号放大之后，固定高度的行、写死宽度的按钮、紧挨着的两块文本，都可能互相挤压甚至被裁掉。这不是密度问题，但它和密度问题常常一起出现，而且症状很像 —— 「在我这儿好好的」。

如果你的改动碰过文字相关的区域，验证时顺手把设备字号调大一档再看一眼，成本很低，却能挡掉一批上线后才发现的问题。

六、两个自家应用的实例：以前怎么做、现在一句话怎么做、改完怎么验证

下面两个例子都来自我们自己和同事的日常场景，用的是自家应用、自家素材。

实例一：自家「设备维保」应用的图标，只在部分设备上清楚。

这个内部工具的图标来自一次「赶时间」的替换：当时只把设计给的一张低分辨率图塞进了其中一档。结果就是常见的分叉 —— 我们几个的新手机上看着还行（因为被缩小了），一线同事那台老机器和一台平板上一放大就发虚。以前遇到这种情况，处理流程是：先怀疑包没打对，重新打一遍再装；再怀疑设备缓存，把应用卸了重装；折腾几轮之后才想起来去看看图标到底被放进了哪几个密度目录 —— 到这一步才发现，另外几档里躺着的还是三年前的老图。

现在一句话：把自家安装包拖进安卓修改大师智改工坊，需求框里写「把应用图标换成附件里的新 logo，mdpi 到 xxxhdpi 各密度档都要替换，保持原图清晰度」，把设计给的 512×512 原图作为附件加进去，用途说明写清「这张图是新的应用图标，需要铺到各密度档」。

改完怎么验证？ 用「打包后自动运行」先在高密度设备上装一遍看桌面图标；然后切一台低密度设备（旧手机或改过分辨率的模拟器）再装一遍，看同一处是不是也换新了。两处都换新，说明各密度档都被覆盖到；这时再看一眼图标边缘是否清晰 —— 因为这次给的是大图，任何一档都是缩小使用，发虚的情况不会再出现。

这个例子里有一个反直觉但很值的经验：「图标问题」优先怀疑范围，而不是怀疑图像质量。 大多数人第一反应是「图给得不够好」，于是回去让设计重出一版；实际上十次里有八次是范围问题 —— 该换的档没换全，或者换的档不是这台设备取的那一档。把范围补齐，往往一次就过。

实例二：自家「库房盘点」应用的启动页背景，在平板上被拉扁。

这是给库房同事用的内部应用，启动页背景要换成新版仓库照片。以前的做法是：找到背景图所在目录，把新图按「原尺寸」覆盖上去，回编、签名、装机看效果。问题出在最后一步 —— 手机上看着挺好，到了那台盘点用的平板上，图被拉扁了。原因是版式上这块区域是「填满」的，而新图和旧图的长宽比不一样，平板的大屏把差异放大了。当时的处理是重新导一版新图，一遍遍试着改尺寸，两三次之后才碰对。

现在一句话：「把启动页背景图换成附件里的新图，保持显示比例（不要拉伸填满），其余不动」。把新版照片作为附件加上去，说明写清「这张图替换启动页背景，需要按比例显示」。改完自动打包、装机、拉起。

改完怎么验证？ 关键就是那台平板 —— 大屏是这种问题的放大镜。在平板上点开一次看有没有变形；再回到手机上确认比例也正常。同一份产物、两台设备对照，才能确认「保比例」这一条真的生效了。要看第二台设备不用重新改包，切到那台再点一次「去打包」就行：包没变，只是换了验证的设备。

这里还有一个可以顺手养成的习惯：把「用哪台设备验证」也写进验收标准。 「高密度设备上桌面图标正确、低密度设备上桌面图标正确、启动页在两台设备上都没有变形」——这三句话写清楚，谁来验收都不会漏。反过来，如果验收标准只写「图标已替换」，那它其实什么也没约束住，因为「替换」是一个动作，不是一个结果。

两个例子的共同点：问题都不在「改没改」，而在「改的范围与比例有没有被说清」。 把范围（哪几档）与约束（保不保比例）写进需求，是这两个坑最省事的解法。

七、用户评价：他们在适配这件事上踩过什么

八、结语：把「看着挺好」换成「每一档都好」

最后回到开头那两个现场。第一个（大屏发虚）的解法是「把大的那张补齐」，第二个（别人机器上没变）的解法是「把范围写全」，第三个（被拉扁）的解法是「把比例写清」。三句话都落在同一个动作上：把不确定的部分变成需求里明确的约束。 这也正是「一句话改包」能不能一次成功的关键 —— 机器不怕需求长，只怕需求含糊。

把这篇收成一句话：图不是一张，是一组；设备按自己的密度就近取一张，取不到就缩放；放大发虚、缩小藏糊，所以「我这里看着挺好」永远不算结论。 工具这边的挑图逻辑，是把包里最清晰的那张原图取出来给你看；而改包时的正解，是把范围（哪几档）和约束（保不保比例）都写进需求。

这也是安卓修改大师智改工坊在适配这件事上的价值：只需说话，就能让应用变成你想要的样子 —— 你把「哪几档、保不保比例」说清，剩下的改资源、回编、对齐、签名、校验、装机都在同一条流水线上跑完，验证时换一台设备再点一次就行。

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