一个界面三套文件：改哪一份才会生效

改界面最让人困惑的一次经历，大概是这样：你把某一行文字改短了，手机上一切正常，装到平板上横着一看——还是老样子。你以为没改成功，回去又改了一遍，还是没变。

原因不在你，在文件。同一个界面，包里可能有三份不同版本的布局文件：竖屏一份、横屏一份、大屏一份。你改的那份，恰好不是平板取的那份。系统在运行时按"当前设备的条件"去挑一份来用，而你改的只是其中一份。

这篇文章讲的就是"挑"这件事：这些文件是怎么分的、系统按什么顺序挑、改的时候怎么知道有几份、以及改完之后怎么验证。它不教你怎么做界面设计，只解决一个很具体的问题——改哪儿才生效。

只需说话，就能让应用变成你想要的样子。而在「安卓修改大师智改工坊」里，你可以直接说"把这个页面在大屏上也是两行显示"，它会去找对应的那几份文件一起改，而不是只改你正在看的那一份。想对照着看自己手上的包有几份布局，可以从 https://www.apkeditor.cn/ai-version.aspx 下载「安卓修改大师智改工坊」，反编译之后打开 res 目录数一数。

一、res/layout 不是一个目录，是一组目录

在 res 下面，你会看到 layout 目录，也可能看到 layout-land、layout-sw600dp、layout-v21 这些名字像后缀的目录。它们装的是"同一个界面的不同版本"，文件名相同，内容不同。

后缀部分就是"限定条件"，写的是"在什么情况下用这一份"。land 指横屏，port 指竖屏，sw600dp 指"最小宽度 600dp 以上的屏幕"（大致是平板），v21 指"系统版本 21 以上"，w820dp 指"当前可用宽度 820dp 以上"。

为什么要分这么多份？因为一份布局很难同时适配所有屏幕。手机上竖着一列一行刚好，平板上横着就会空出一大片；手机上按钮要占满宽度，平板上占满就变成了一个巨大的色块。分开写，才能在各自的场景里都合理。

而这也解释了一个常见现象：一个看起来很简单的应用，res/layout 里却有几十个文件。因为"一个界面"可能对应"三份文件"，十几个界面就是三四十个。这不是冗余，是分工。

反过来说，如果你打开 res 只看到一个 layout 目录、里面文件也不多，那这个应用的界面适配大概很"朴素"——所有屏幕共用一套布局。这种包改起来最简单：改一份就全生效。而文件多的包，才需要"先看清楚有几份"。

判断方法很简单：在 res 里搜你要改的那个布局文件名，看看它出现在几个目录里。出现在三个目录，就说明有三份，要一份份改；只出现在一个目录，改一份就够。这一个动作，能省掉后面所有的"为什么没生效"。

二、系统到底挑哪一份：一条"越具体越优先"的规则

系统挑选的顺序不是随机的，而是一条很朴素的规则：在所有能用（即条件成立）的候选里，挑那个"限定得最具体"的。换句话说，能匹配的条件越多，优先级越高；一个条件都不带的默认那份，优先级最低。

举一个具体例子：一台平板，横着，系统版本较新。那么 layout-land、layout-sw600dp、layout-v21 三份的"条件都成立"。系统会去比谁更匹配——如果你的平板是横屏且宽度够，那 land 和 sw600dp 都命中，具体用哪一份还要看"谁的限定符更多、更贴近当前设备"。

这条规则的实际含义是：你改"默认那份"（layout），只在"没有任何特殊条件成立"的设备上生效。而现场那些平板、那些横屏、那些新系统，往往都命中了某个特殊条件——所以你改的内容被"更具体的那份"盖住了。

这也是为什么"手机上好好的，平板不行"这么常见。手机通常是竖屏、宽度不足 600dp，正好只命中默认那份；平板一到手，条件全变了，用的就是另一份文件。

理解这条规则之后，你就不会再去问"为什么改了没生效"，而会先问"这台设备命中了哪一份"。而要回答这个问题，最直接的办法是把包里所有相关的布局文件都找出来，一份份看它们放在哪个目录里。

有一个常被误解的点：文件名必须完全一样，限定符才起作用。如果横屏那份叫 main_land.xml，而默认那份叫 main.xml，那它就不是"同一界面的两个版本"，而是"两个不同界面"——系统根本不会把它们当成一对。

这条规则还有一个副产品：如果你把两份文件的"限定条件"写得互相重叠，比如同时存在 land 和 sw600dp，那最终用哪一份，连写代码的人都要查文档。而"要查文档才能解释"的设计，通常就是排障时最痛苦的那一类。

所以看到 res 里有一堆 xxx_land.xml、xxx_tablet.xml 这种命名，基本可以判断：这个应用的适配是"在代码里判断设备再加载不同文件"的做法，不是系统自动挑。它的行为由代码决定，改包能改文件内容，但改不了"什么时候用哪个"这个判断。

三、第一个自家实例：横屏列表被裁掉一截

我们自家有一个培训学习端，给新员工看课程、做题、看通知。课程列表页在手机上是"标题一行、下面两行小字、右侧一个进度条"，看着挺紧凑。

以前怎么做：有一次运营说"平板上列表字被切了，右边的进度条也看不见"。我打开工程，找到课程列表的布局，把行高和字号都改小，打包、装上手机看——正常。拿到平板横着看——还是被切。

问题在哪：那个页面有两份布局，一份在 layout，一份在 layout-land。我改的是竖屏那份，而平板横屏取的是 land 那份，里面的行高是写死的。两份文件长得很像，但那份的每一行都多了一个固定的高度值。

现在一句话怎么做：在「安卓修改大师智改工坊」里说"把课程列表在横屏和大屏上也是三行显示，不要把字切掉"。它会去两份文件里都改，而不是只改默认那份。改的时候它还做了一件事：把写死的高度换成"按内容撑开"，这样字号变化时不会再被切。

改完怎么验证：三台设备——手机竖着看一次、手机横过来看一次、平板横着看一次。三种情况都要看"最后一行有没有被切成半个字"，因为被裁的往往就是最后一行，而它在竖屏下看不见。

这一次的教训被我们写成了一条检查项：改任何界面之前，先在 res 里搜这个布局的文件名，看它有几个副本。有副本就先看副本，别急着改默认那份——因为现场的设备，往往正好命中的是副本。

顺便说一句"横屏"的判断标准：不是"手机横过来"，是"当前可用宽度大于高度"。平板横着是横屏，某些折叠屏展开之后也算接近横屏，而手机横过来只是其中一种。所以验证的时候别只用手机横屏代替平板——它们的可用宽度差得多。

四、第二个自家实例：平板上那套"两列"的版本

第二个例子是我们自家的门店点单端，给店员在平板上点单用。手机上是一列商品、点开看详情；平板上是左列分类、右列商品，因为屏幕宽，一列太浪费。

以前怎么做：品牌方要求"平板上商品卡片之间再松一点，别挤在一起"。我改了默认布局的间距，装到平板上——一点变化都没有。因为平板取的是 sw600dp 那一份，里面的间距是另一套值。

现在一句话怎么做：说"把平板上商品卡片之间的间距调大一档，手机上的不动"。它会只在 sw600dp 那份里改，默认那份保持原样。这里"手机上的不动"这半句很重要——否则很容易把两边一起改，手机上一改就变成一屏只放得下三个商品。

改完怎么验证：平板横着看（间距是否松了）、平板竖着看（会不会因为变窄而挤成两列半）、手机上看（有没有被误改）。第三个最容易漏，因为"我只改平板"这句话，如果工具理解成"两个都改"，手机上就出事了。

这个实例想说明的是：限定符不只是"横竖"，还有"宽度"。而"宽度"这个条件比"横竖"更常用在平板上——因为平板竖着也是宽屏，用 sw600dp 判断比用 land 判断更准。所以看到 res 里有 sw600dp 目录，就要意识到"平板不论横竖都会用这一份"。

还有一个相关的坑：同时存在 layout-land 和 layout-sw600dp 时，一台"横着的平板"两份都命中。这时候到底用哪一份，取决于限定符的具体匹配规则，而不是"你觉得哪份更合适"。判断方法只有一个：在真机上看结果，别靠猜。

所以我们的做法是：一个应用里尽量只用一种"分法"。要么按方向分（land/port），要么按宽度分（sw600dp），别混着来。混着来的时候，连你自己都说不清"这台设备会用哪一份"，排障成本会翻倍。

五、别急着新建一个限定符目录

改到这一步，很多人会冒出一个念头："那我干脆自己建一个 layout-sw600dp，把内容复制进去，不就控制了平板上显示什么？"这个念头很自然，但做法有风险，原因有三个。

第一个原因：你新建的那份，可能"抢"掉了原本生效的那份。如果原来没有 sw600dp 目录，你的新文件就是"平板上的唯一答案"——它会盖住默认那份，而不是"补充"。于是平板上出现的可能是你复制的那份半成品。

第二个原因：布局文件之间常有引用。你复制过来的一份，里面可能引用了别的布局、样式、颜色、字符串。少带一个，打开就崩；多带一个，可能和原来的冲突。手工复制的文件，很容易"看起来一样、用起来不一样"。

第三个原因：你复制的是一份"快照"。半年后默认那份改了，sw600dp 那份没人动，两份就分叉了。分叉之后，平板上会出现"某个按钮不见了""某句话还是旧的"这类现象，而你会以为是没生效。

所以更稳的做法是"改，而不是复制"。也就是在已有的那几份里改对应的值。这样两份文件的结构一致，改动是可对齐的，半年后也不会分叉。

如果确实需要一份"只在大屏上用"的布局，那要先想清楚：这份文件的维护责任归谁。如果没人负责，它很快就会变成一个"谁也不敢动的祖传文件"——而它偏偏又是平板上生效的那份。

判断"要不要新建"的标准，其实很简单：这个改动是"同一套排版的不同参数"，还是"完全不同的排版"。前者改值，后者才考虑新文件。而绝大多数"平板上松一点、大一点"的需求，都属于前者。

六、能改的三类动作：挪位置、改显隐、字号间距

能改的东西看起来很多，实际常用的只有三类动作。把这三类做好，日常八成的界面调整就够了，而且都不会破坏结构。

第一类：挪位置。把某个版块往上或往下调、把某个按钮从左挪到右。这类改动最安全，因为它只动"顺序"，不动"容器"。而它在界面上能立刻看到效果，验证成本极低。

第二类：改显隐。把某个不常用的入口收起来、把某段说明隐藏掉、把某一行只在特定条件下显示。这类改动的风险在于"隐藏之后布局会塌"——因为原来占位的东西没了，下面的内容会往上挤，而挤上来的结果可能是两个元素叠在一起。

第三类：改字号与间距。把标题放大、把行距拉开、把卡片间距调松。这类改动最直观，也最容易"改过头"——因为一行文字的宽度是有限的，放大两个字号就可能换行，换行就可能把下面的内容顶出去。

三类动作都有一个共同的验证方法：改完看"最长的那个值"。最长的一行文字、最宽的一个按钮、最高的一个卡片——因为在真实数据里，总有一条内容比你想象的长。而界面出问题，几乎都出在"最长的那一条"上。

还有一个操作层面的建议：一次只做一类。又要挪位置又要改字号，改完发现界面歪了，你不知道是哪一步导致的。分开做，每步验一次，虽然慢一点，但"能定位"这件事本身就值这个时间。

三类动作里，"改显隐"最容易留下隐患，因为它改的是"有没有"，而不是"长什么样"。一个被隐藏的元素，代码里可能还在找它、还在给它设值。它不显示，但它的位置、它的父容器、它的间距，都还在影响布局——这也是"隐藏了却还是空一块"的原因。

最后一条经验：改布局的时候，先改"容器"的边距，再改"内容"的字号。因为容器决定"有多少空间"，内容决定"占多少"。先定空间再定内容，比反过来稳——反过来往往要调两轮。

七、改不了的四件事，和它们的替代方案

同样要说清"改不了"的那一半，否则你会一直在错误的方向上使劲。下面四种，靠改布局文件基本做不到，或者做到了代价太大。

第一种：一列变两列。这不只是"把两个东西并排"，而是要重排整个层级：外层的容器要换成能横向排列的，里面每一项要重新分配宽度，图片要重新算比例。文件里能改的是"参数"，改不了"结构"。

第二种：列表能不能滑动、按什么排序。这两件事由代码决定——数据从哪来、怎么排、滑到底要不要加载更多。你在布局里看不到这些，自然也改不了。

第三种：动态生成的内容。有些界面是"空的"，打开之后由代码往里塞卡片。你在布局文件里看到的只有一个空容器，改它不会影响运行后长什么样。

第四种：自定义控件。有一种控件是自己画的（图表、日历、手写板），它在布局里只占一行，长相完全由代码决定。你在布局里改它的宽高，只能让它变大变小，改不了里面的样子。

这四种有一个共同的替代方案：不做"结构改动"，做"顺序与显隐的调整"。不能变两列，就把最重要的那块挪到最上面；不能改排序，就把最常用的入口提到显眼处。用户感受到的"好用"，很多时候来自"重要的在前面"，而不是"排成两列"。

而判断"这件事属于哪一类"的方法，是看它在布局文件里有没有对应的东西。有对应的标签和属性，就属于可改；只有一行占位，就属于改不了。这个判断只需要三十秒，却能省掉半天的白折腾。

八、五个最常被问到的问题

问题一：我怎么知道这个界面有几份布局？

搜文件名。在 res 目录里搜那个布局的名字（不带 .xml），看它出现在几个目录下。出现在 layout 和 layout-land，就是两份；再加上 layout-sw600dp，就是三份。搜索结果就是"这个界面一共有几个版本"的答案。

问题二：能不能只改一份，让它对所有屏幕都生效？

可以，但要先把其他几份删掉或者对齐。因为"更具体的那份"永远优先。你留着 land 那份不改，横屏就还是旧的。所以要么一起改，要么把多余的那份删掉——而删掉的风险是"原本那份是为某个特殊场景写的"，删了那个场景就变形了。

问题三：改了之后手机上正常、平板上错位，是不是我改错了？

大概率是"你只改了一份，而另一份和它对不上"。典型表现是：同一段文字，一份里是两行，另一份里是一行，于是间距全变了。判断方法：把两份文件里"同一个位置"的值对比一下，看差多少。

问题四：横屏那份我可以直接复制竖屏那份覆盖吗？

不建议。因为横屏那份存在的意义，往往是"横屏时需要不同的排布"（比如左右分栏）。你把它覆盖成竖屏的样子，横屏就会变成"一个被拉宽的竖屏"，两边大片留白，或者内容被拉得很扁。

问题五：改完之后怎么确认真的生效了？

看一个"只有这份文件才有的特征"。比如你在 land 那份里把某个标题改成了两个字，那就横屏看那个标题有没有变成两个字。不要看"整体感觉对不对"——感觉会被你的期待影响，而特征不会。

九、三块屏，缺一块就等于没验

改布局的验证方式，和改文字、改图完全不同。文字和图"看一眼就知道对不对"，而布局要"在不同的屏幕上看"。看一次不算验证，因为在最顺眼的那块屏上，什么都是对的。

第一块屏：手机竖屏。它通常是"默认那份"布局生效的场景，也是最容易通过的。要看的是"有没有因为改字号而换行"——换行会把下面的内容顶下去，而顶下去之后最底部的按钮可能就出屏了。

第二块屏：手机横屏。这一块能验证"横屏那份有没有被一起改"。如果竖屏变了、横屏没变，说明你只改了一份。而横屏最常见的毛病是"留白太多"——因为横向空间一下变宽，内容还是原来那么宽。

第三块屏：平板。不管是横是竖，都要看一次。平板能暴露的问题最多：字太小的看着费劲、间距太紧的挤成一团、本来一列的内容被拉得很宽。而这些在手机上完全看不出来。

三块屏的验证顺序，有一个小技巧：先看平板，再看手机。因为平板上的问题最明显，先看它，你能立刻发现"改漏了一份"；而如果先看手机，看到一切正常，你会以为已经好了，就不太想再去看平板了。

而这三块屏不必都是真机。手机可以用自己的一台、平板可以借一台，实在没有就用模拟器。模拟器的价值在于"能自由改分辨率"，缺点在于"看不出手感"——所以布局类的验证用模拟器可以，涉及触摸、扫码、强光这些场景，还是得真机。

最后还有一条：验证的时候把"最长的内容"造出来。列表里塞一条特别长的名字、备注里填一段长文字、把数量填到四位数。因为这些才是真正会把布局撑坏的东西，而测试数据往往都是"刚刚好"的。

十、四处"改了不报错但会出事"的地方

布局文件里有几处东西，改了不报错、但会悄悄出问题。认识它们，能省掉很多"我知道我改了什么，但不知道为什么会这样"。

第一处：id。布局里每个控件的 id，是代码用来找它的"名字"。你把 id 改名、删掉、或者复制成两个一样的，代码就找不到它——表现是"这一块空白""点按钮没反应"，而不是崩溃。

第二处：include。很多界面会把"头部""底部栏"抽成一个公共文件，用 include 引进来。你只改主文件，公共那块不会变；反过来，你改公共文件，所有引用它的界面都会跟着变——包括你没想到的那几个。

第三处：写死的宽度和高度。有人习惯写 "宽度 320dp、高度 48dp"，在手机看着刚好。换到大屏，它还是 320dp，于是左边一大片空白、右边挤在一起。这类值改起来不明显，但它在"不同屏幕"上差别巨大。

第四处：样式引用。文字颜色、字号、按钮样子，往往不是写在布局里，而是引用了一个样式。你改布局里的字，样式又把颜色改回去了；你改样式，所有用这个样式的界面一起变。

这四处的共同点是：它们是"引用关系"，不是"内容"。改内容，影响的是你看到的那一处；改引用，影响的是"所有指向它的地方"。所以在改之前，值得先搜一下这个名字在包里出现几次。

第四处还有一个变体：颜色和尺寸写在"值资源"里。比如间距统一写成某个 dimens 值，字号统一写成某个 style。你改一处布局的引用，等于改了所有引用它的地方——包括你现在没打开的那几个页面。

而最稳的改法，是"只改值，不改名字"。把字号从 14 改成 16 是安全的；把控件 id 从 title 改成 main_title，就危险得多。前者是调参数，后者是动接口——而动接口，代码那一端是不知道的。

十一、五组对照：现象、原因、下一步

把前面几节压成一张表，判断和验证就都有依据了。表里左边是"你遇到的现象"，中间是"最可能的原因"，右边是"下一步该做什么"。

现象一：手机上变了，平板上没变。原因：平板命中了另一份布局（sw600dp 或 land）。下一步：搜文件名，看它在几个目录里，把其余几份一起改。

现象二：横屏变了，竖屏反而坏了。原因：你改的那份是 land，而它里面的值被默认那份共享（比如同一个尺寸资源）。下一步：对比两份的同一个值，看是不是改了共用资源。

现象三：字变大了，但被切成半行。原因：容器高度是写死的，字撑不开。下一步：把固定高度改成"按内容撑开"，或者把行高一起调。

现象四：某个按钮不见了。原因：挪位置时把它挤出了可视区，或者显隐改错了对象。下一步：看它在布局里的层级，确认它还在、且父容器没被隐藏。

现象五：打开就崩。原因：改动破坏了引用（id 改名、include 缺文件、样式写错）。下一步：回退到上一版，只改一处再试——一次改一处，是排查崩溃最快的办法。

这张表的用法，不是"背下来"，是"遇到时对一眼"。因为布局类问题的特点是：现象和原因之间隔着一层"文件选择"，而那一层不看表是想不起来的。

十二、平板上的三种典型变形，和三种修法

手机上看着正常的界面，搬到平板上会以三种很典型的方式变形。认识这三种，你在改之前就能预判"这里大概要出问题"，而不是等装上去才发现。

第一种变形：被拉宽。原来一行文字在手机上刚好占满，到了平板上，一行能装下两倍的量，于是文字只占左边一半，右边一大片空白。这类问题的根源是"宽度自适应"——容器跟着屏幕变宽，但内容的排布没变。

解决思路不是"把字改大"，而是"给内容一个上限"。也就是让内容在宽屏上居中、或者限定一个最大宽度。这样平板上看到的是"一栏居中的内容，两边留白"，视觉上比"一行字横跨整个屏幕"舒服得多。

第二种变形：被拉扁。图片最典型。手机上是一张竖图，平板上被塞进一个很宽的容器，结果人被压扁、圆变成了椭圆。原因是图片按"填满容器"的方式显示，而容器的比例变了。

解决思路是"锁比例"：让图片按原来的宽高比显示，而不是填满容器。代价是容器边缘会出现留白，但留白不丑，"人变形"很丑。这条经验在任何屏幕上通用。

第三种变形：被挤爆。这一种和前面两种相反——不是因为空间变多，而是因为"平板上字号被放大"（很多系统允许用户调大字体）。字一大，原本一行的标题变成两行，两行变成三行，下面的内容被顶出屏幕。

解决思路是"给文字留余量"：高度不要写死、行数不要卡死、关键按钮不要贴底。而这三条恰恰是最容易被"为了对齐好看"而违反的——设计师喜欢精确对齐，而精确对齐在字体被放大时就变成了灾难。

三种变形里，"被挤爆"最容易被误判成"应用卡了"。因为内容被顶出屏幕时，用户看到的是"下面什么都没有"，第一反应是"没加载出来"。而实际原因是字变大了、把内容挤下去了。判断方法很简单：把系统字体调回默认，看内容是不是又出现了。

三种变形对应三种修法：限宽、锁比例、留余量。它们都不需要改结构，只改参数——所以都属于"改包能做"的范围。而它们的效果，在平板上比在手机上明显得多，也正因为明显，改完之后一眼就能看出对不对。

十三、把一次界面改动，写成一句能执行的话

一整套流程走到最后，会落到一句很具体的话上。而这句话写得好不好，直接决定"改一次就到位"还是"来回改三次"。

好的写法有三个要素：在哪块屏、改哪个位置、改成什么样。缺一个，结果就会跑偏。缺"哪块屏"，可能只改了一份；缺"哪个位置"，可能改错了元素；缺"改成什么样"，就只能靠对方猜。

举一个反例："把界面弄得适合平板一点"。这句话里有"平板"，但没有"哪个位置"和"改成什么样"。工具只能猜，猜出来的结果你多半不满意，然后你会说"不对，再改改"——而"再改改"是最没效率的一种沟通。

改成正例："平板上的商品列表，一行从三个改成四个，间距和手机上保持一致"。这句话里三要素齐了：条件（平板）、位置（商品列表）、结果（一行四个、间距不变）。它有明确的验收标准——数一数一行几个就知道对不对。

再举一个："横屏的时候标题不要换行"。这句话短，但三要素也齐了：条件（横屏）、位置（标题）、结果（不换行）。而它隐含了一个动作：把标题的字号或者容器宽度调一下。这种"短但准确"的写法，是最理想的。

而"一句话说不清"的时候，往往说明这件事本身该拆。比如"把平板上整个首页重新排一下"——这不是一句，这是五句：哪个版块上移、哪个下移、哪个隐藏、哪个放大、哪个缩小。拆成五句，每句都能验；不拆，就只能反复看"感觉对不对"。

还有一个小技巧：把"不要什么"也说进去。"只改平板，手机不动"、"不要改字号，只调间距"、"其他页面别动"。这些否定句能挡住最常见的误伤——因为一次改动波及到别处，往往比"没改到位"更麻烦。

说到底，这句话的训练价值不在于"让工具听懂"，而在于"让自己想清"。你能把一件事说成一句带条件、带位置、带结果的话，说明你已经知道它在哪、会影响到谁、怎么验证。而这三点，才是改界面真正的门槛。

十四、dp、sp、px：改错单位不会报错，只会"看着不对"

布局文件里的数字，后面几乎都跟着一个小单位：dp、sp、px。这三个字决定了"这个值在别的屏幕上会长成什么样"，改了单位等于改了含义，而它不会报错。

dp 是"与密度无关的像素"。它的设计目标是"在不同屏幕上看起来一样大"。同样是 16dp 的间距，在高密度屏和低密度屏上占的物理尺寸接近——所以间距、边距、控件高度，都应该用 dp。

sp 是"与缩放无关的像素"，专门给文字用。它和 dp 类似，但会额外乘上"用户在系统设置里调的字体缩放比例"。所以文字用 sp，用户在系统里把字调大，你的应用里的字也会跟着变大——这是好事，也是麻烦的来源。

px 是"物理像素"，写多少就是多少。用 px 写间距，在高密度屏上会显得极小、在低密度屏上会显得极大。所以现代应用里几乎不该出现 px，除了极其特殊的场景（比如一条一像素的分割线）。

为什么这件事在"改界面"时特别重要？因为很多人改字号时会顺手把单位也改了。本来是 16sp，改成 18px 之后，在某些屏幕上反而变小了；本来是 12dp 的间距，改成 14px 之后，看上去几乎没变。这类改动不报错，只是"效果和预期不一样"。

判断一个值该用什么单位，有一条很简单的规则：凡是"文字"相关的（字号、行距），用 sp；凡是"空间"相关的（宽高、边距、间距），用 dp。而颜色、透明度这些，是另一套写法，不在这个讨论里。

还有一个和 sp 有关的坑：它在"系统字体调到最大"时会把布局顶坏。因为所有文字一起放大，而容器的高度往往是按"正常字号"设计的。表现是文字被切成两行、按钮被挤出屏幕、列表行高不够。

这也是为什么"验证要看系统字体"这一条，值得写进每一次界面改动的检查项。把系统字体调到最大，再打开一遍，看三处：标题有没有变两行、列表有没有错位、底部按钮还在不在。这三处坏掉，说明布局的余量不够。

如果只能记一句话：dp 管空间、sp 管文字、别用 px。而"改完把系统字体调大看一遍"，是这条规则最实际的用法——因为它是唯一能把"单位用错"立刻暴露出来的测试。

还有一个常被忽略的细节：图片的"显示方式"也有一套取值，比如拉伸填满、等比缩放、居中裁剪。同一个容器，换一种显示方式，结果完全不同。而这类改动在代码里只是一行属性，在界面上却是"人变形"和"留白"的区别。

顺便说一个反过来的情况：有些界面在"系统字体调小"时反而更难看。因为字变小了，行与行之间的空隙显得特别大，一整页像被拉散了。这同样说明"高度是写死的"，而不是"按内容撑开"。

十五、三看一数：界面改完的四个验收动作

界面改动做完，最后一步是验收。而验收最怕的是"看着挺好"——因为"看着"这件事，会被你的期待带着走。更可靠的做法是四个固定动作：三看一数。

第一看：看边。四个边都看一遍——标题有没有贴顶、最后一个元素有没有贴底、左边有没有被裁掉半个字、右边有没有出现横向滚动条。贴边是最常见的问题，而它在小屏上往往看不出来。

第二看：看长。把最长的一条内容造出来，看它怎么排。列表里塞一条超长名字、备注里填三行字、数字填到五位数。因为真实数据里总有一条比测试数据长，而布局坏掉往往就坏在那一条上。

第三看：看空。把列表清空、把数据置空，看空状态长什么样。很多界面在"没数据"时只剩一片白，用户以为卡住了。而空状态是不是有提示，取决于那一段有没有被设计过——它也可能就是你这次改动顺手弄丢的。

一数：数个数。数一数一屏能看到几个卡片、一行能放下几个按钮、一列能显示几行。这个数字是可以和设计稿对照的，也是最客观的一个指标。文字好不好看是主观的，一行几个是客观的。

四个动作里，"看长"最容易被跳过，也最值得做。因为它的成本很低——只要在测试数据里塞一条长的就行——而它发现问题的概率最高。很多"上线之后才发现的错位"，都是被一条长内容撑出来的。

还有一个动作不在"三看一数"里，但同样重要：把改动前后的截图并排放。因为人对"变化"的感知很差，改完之后你只记得"我改了这里"，看不出"别的地方也动了"。并排放，差异会自己跳出来。

并排截图还有一个额外的好处：它是给别人的最好说明。发给同事、发给客户、存进交付记录，一张对比图胜过十句解释。而做这张图只需要两个动作：改前截一张、改后截一张。

最后一条：验收的时候不要只看"你改的那一页"。因为布局文件之间常有共用（样式、include、尺寸资源），改一处很可能影响另一处。所以走完你要改的页面之后，再顺手点开两三个"看起来无关"的页面——它们是最容易出意外的地方。

"三看一数"这套动作，最好写进交付单里，而不是记在脑子里。因为验收这件事，最容易在"赶时间"的时候被压缩成"看一眼"。而写成三行字的清单，至少能让"看一眼"变成"看三眼"。

把这四个动作固化成习惯之后，界面改动的返工会少很多。因为绝大部分返工，不是因为改得不对，是因为"没看到还有别的地方也变了"。而"看到"这件事，只能靠固定的动作，不能靠注意力。

十六、用过的人怎么说

五条反馈，讲的是同一个主题的五个面：有几份、别新建、改哪份、别改名字、三块屏都要看。而这五个面之所以都要讲，是因为布局这类问题，"做对一次"不等于"以后都对"——换一个页面、换一台设备，规则重新生效。

而第一条那句"改了四遍"，其实是最值得同情的部分。因为它不是能力问题，是"信息不完整"——你不知道有几份文件，就只能在原地打转。而知道之后，同样一件事只需要一次。

---

只需说话，就能让应用变成你想要的样子。而在"一个界面三套文件"的世界里，这句话还有一层隐含的要求：你得说清"在哪块屏上变成什么样"。说得清，改一次就到位；说不清，就只能在三份文件之间来回试。而"说清"这件事，交给安卓修改大师智改工坊来配合：它替你把该改的那几份一起改掉，你只要把条件和结果讲明白。