改了图却没变：资源索引表在中间做了什么

改包的人几乎都遇到过一次这样的怪事：一张图换好了，打包成功，装到手机上打开，还是原来那张。于是重新换一次，重新打包，还是老样子。折腾到第三次，开始怀疑是不是工具没刷新生效、是不是手机缓存了。

真正的原因往往在另一个文件上：资源索引表。它不在图片目录里，也不在布局目录里，而是躺在包的根目录下，名字叫 resources.arsc。这个文件不像图片那样能打开看，所以大多数人从来没注意过它——直到它开始拦路。

这篇文章讲清三件事：这张表是干什么的、为什么它能让你改了文件却没变化、以及什么时候你必须让它跟着一起更新。理解了它，很多「改了没变」的谜题会一次性解开。

只需说话，就能让应用变成你想要的样子。而在「安卓修改大师智改工坊」里，这张表不需要你亲手对付——换图、改字之后重新编译，索引会跟着一起重建，你只要说清换成哪一张。它把「文件改了、表也要跟着改」这件事放进了流程里。想先看看一个包的资源是怎么组织的，可以从 https://www.apkeditor.cn/ai-version.aspx 下载智改工坊，反编译之后在根目录就能看到它。

一、先把这张表说成一张目录卡片

包里的资源成千上万：几百张图、几十个布局、几套语言文案、几组颜色。程序运行的时候，要知道「我要的那张图在哪儿」，得有东西告诉它。

这个「东西」就是 resources.arsc。你可以把它想成一张目录卡片：左边写着资源的名字和编号，右边写着这个资源的内容放在包里的哪个位置、有多大。程序要什么，先查这张卡片，按卡片上的地址去拿。

为什么不直接按文件名去找？两个原因。第一是快——按名字在成千上万个文件里找，太慢；查表是直接命中。第二是资源可以被「换」：同一个名字，在不同情况下对应不同的内容，程序调用的代码一行都不用改，就能在中文手机上显示中文、在英文手机上显示英文。

这就是这张表存在的意义：它让「程序里写的名字」和「包里实际的那份内容」之间可以脱钩。脱钩带来的好处是多语言、多分辨率、多主题；带来的麻烦就是你改了文件之后，那张卡片上写的位置和摘要可能还是旧的。

所以判断「改了没变」的原因时，只需要问一句：程序拿到的是哪个文件？如果它拿的还是旧的那一份，那就不是你的图有问题，是卡片指错了地方。

二、一张卡片上，其实写着好几行

很多人以为一个资源名对应一个文件。不是。一个名字往往对应好几份内容，卡片上会写成好几行，每行后面标着「这一份适合什么情况」。

标密度的那些行，管的是屏幕清晰度。同一个图标，可能有低清、中清、高清、超清四份，分别放在不同的目录里。系统会按当前屏幕挑最合适的一份。

标语言的那些行，管的是界面语言。同一句提示，可能有一份中文、一份英文、一份繁体，分别放在不同的目录里。系统按当前语言挑。

标其他条件的那些行，管的是屏幕方向、屏幕尺寸、系统版本等等。前面几篇讲过的布局限定符，本质上就是在给这些行打标签。

于是「改了没变」的第一个可能原因就出现了：你改的那一行，不是系统这次挑中的那一行。你换了低清那份图，而手机是高分辨率屏，系统用的是超清那份——它当然没变。

这时候最容易犯的错是「再改一次」，把同一张图又换了一遍，还是换到同一份上。正确的做法是先弄清楚这台设备到底会挑哪一份，然后只改那一份；或者干脆把所有份都换成新的。

三、系统是怎么挑的：一条规则，两个例外

这条规则可以一句话说完：越贴近当前设备的，越优先。设备是高清屏，就优先挑高清那份；设备是中文系统，就优先挑中文那份；设备横屏，就优先挑给横屏准备的那份。没有更贴切的，就退回到通用那份。

这条规则和前面讲布局限定符时的「越具体越优先」是同一条。它们其实是同一个机制的两个用法：布局用目录名做标签，资源用后缀做标签，最后都落到这张表上。

第一个例外：密度是「就近取」，不是「越高越好」。这一点反直觉。设备是中密度屏，而包里只有低清和高清两份，系统会挑哪一份？通常挑高清那份，因为往下降级会糊，往上取一份再缩小，效果更好。所以换图的时候，如果只打算换一份，换最高密度那份是最保险的——它最可能被所有设备挑中。

第二个例外：语言是「精确匹配优先，其次回落」。设备设成某种语言，包里正好有那份，就用它；没有，就回落到通用那份（通常是不带语言后缀的目录）。所以「改了中文那份却没变」还有一个可能：设备当前根本不在中文环境，它用的是通用那份。

这两条例外合起来，解释了一个很常见的困惑：在自己手机上明明改对了，发给同事却还是旧的。因为两台设备的屏幕清晰度或者语言设置不一样，挑中的不是同一行。

四、第一个实例：换了启动图，三天没生效

自家一个门店会员端，要换启动页那张图。需求很明确：把那张带旧 logo 的换成新的。

以前的做法：反编译，进图片目录，找到名字对得上的那张，替换，打包，签名，装机。打开应用，启动页还是旧的。

第二遍：确认文件确实被替换了（看文件大小、看修改时间），重新打包，重新装。还是旧的。到这一步最容易得出的结论是「这张图根本没有被用」，然后开始去翻布局、翻清单，越翻越远。

第三遍才想到去看目录结构。这一看就明白了：同一张启动图，包里一共有四份，分别放在四组不同密度的目录里。我们换的是最低那一组，而测试机是中高密度屏，系统挑的是另一组。

改法是：把四个目录里同名的那张全部换成新的。因为这张图不是九图，也不带透明通道，四份内容完全一样，只是尺寸不同。既然新图是矢量导出的，直接把四份都替换成同一个尺寸也能用，只是低密度那份会略大一点——代价是包大几十 KB，可以接受。

换完之后一次就对了。整个过程真正的操作时间是五分钟，前面折腾的时间大约三天——不是连续三天，是每天试一次，试完没变化就放下了。这类问题的杀伤力就在这里：它不会让你卡住，只会让你反复回到同一个地方。

这件事之后我们加了一个习惯：换图之前先看这个名字下面有几个文件。一个也好，四个也好，先在目录里数清楚，再动手。多数情况下这个动作只要十秒钟，但它决定了你是改一次还是改三次。

五、第二个实例：同一句话，两个页面一新一旧

这次是自家一个设备巡检端。要把「提交成功」这类提示统一改成「已提交，可在记录里查看」。改动本身没难度，难点在于改完之后，两个页面的表现不一样。

提交单条记录的那个页面，提示变了，新的。批量提交那个页面，提示还是旧的。两份提示的字面几乎一样，都是一个短句，唯一的区别是批量那个后面多了个数量。

当时的第一判断是：这是两处不同的文字，得改两遍。于是又改了一遍，结果批量那个还是没变。这时候才开始怀疑：真的是两处吗？

回去看目录，发现包里有两套语文案目录。一套是通用那份，一套是带语言后缀的。我们改的是带后缀的那份，而测试机上系统语言设成了英文——它压根没进那份。

这解释了一件事：为什么单条提交那个变了？因为它那句话不在资源里，是代码里拼的，我们顺便也改了。而批量那个是从资源里取的，取的是英文那份，所以显示的还是英文原文。同一个界面上，两句话的来源不一样，改法也就不一样。

最后的处理是：两份语言目录里对应那一条都改。因为这两份都要用——中文环境用一份，英文环境用另一份。既然需求是「统一改成这个说法」，两份都得一致。

这个例子带出一个小结论：「改一处」这个说法，在资源层是不成立的。你以为的一处文字，在包里可能是三份、四份，甚至几份不同语言、不同密度、不同情况的组合。动手之前数清楚有几个，比改得快更重要。

还有个操作上的细节值得说：改多份的时候，先把它们的内容改成完全一样的一串字符（比如先统一改成一句测试文字），装上看是不是所有地方都变了。确认「这几份确实都被用到了」，再把每一份改成各自该有的正式文案。这个中间步骤多花两分钟，但它能避免「改了三份结果只生效一份」的反复。

六、什么时候这张表必须跟着一起重建

这是整篇文章最实用的一节。不是每次改文件都需要动这张表，但有些改动不动它就一定出问题。分清这两种，可以省掉大量无谓的担心。

只改内容、不改名字和数量的时候，通常不需要你手动管。把一张图换成另一张同名的图，把一句文案改成另一句话，这类改动落在文件本身上；重新编译的时候，工具会顺手把表里对应那一行的位置和大小更新掉。前提是你走的是「反编译→改→重新编译」这条路，而不是「直接把文件塞进压缩包」。

增删文件、改文件名、改目录名的时候，一定需要重建。因为这三种动作改变的是「有几个资源」这件事，表里必须多一行、少一行、或者换一行。这一层关系不是工具能猜出来的，必须重新生成。

直接把文件塞进压缩包，是最危险的一种做法。表面上看包能打开、能装、能运行，实际上表里写的还是旧的地址。结果就是：程序按旧地址去拿，拿到的可能是另一张图，也可能什么都没有。后一种情况就是打开某个页面直接闪退。

为什么有人会选这种做法？因为它快——不用等反编译，不用等编译，几秒钟就完事。而这个「快」的代价，往往在装到手机上之后才显现，而且现象千奇百怪，很难联想到「是塞文件造成的」。

一个简单的判断方法：如果你是用压缩软件打开包、把文件拖进去、保存，那你就是在走这条路。这种方式只适合一种场景：你只是想看看包里的某个文件长什么样，看完就删，不做任何保存。一旦保存，这个包就已经处于「表和内容不一致」的状态了。

反过来说，只要是走「反编译→改→重新编译」这条路，这个问题就不存在。因为编译这个动作本身，就是从目录里的实际文件重新生成一张表。这也是为什么改包这件事，值得多花那几分钟等反编译。

七、为什么不建议直接去改那张表

知道了这张表的作用，很自然会有一个想法：那我直接改它不就行了？比如把某一行指向另一个文件，或者把某一句文案直接写在表里。

技术上可行，实际上不建议，原因有三个。

第一，它是二进制结构，不是文本。里面没有换行、没有缩进，全是按固定位置排的字节。你用一个文本编辑器打开，看到的是乱码；用一个十六进制编辑器打开，看到的是数字。想改对，必须知道每个字节在第几位代表什么。

第二，改一处会牵动全局。表里的地址是按顺序排的，你把某一项的内容改长了，后面所有项的地址都要跟着移。这就不是一个「改字」的动作了，而是一次重新排版。而排错一位，整个表就废了，现象是应用一打开就闪退，连报错都看不到。

第三，有更简单的替代路径。同样的目的，改文件再重新编译就能达到，而且工具会替你处理地址重排。既然有省力的路，就没必要走费力还容易错的那条。

那什么情况下确实需要碰它？一种情况是包里这一项的内容被压缩过、或者被特殊编码过，直接改文件改不动。这种时候确实要落到表这一层，但正确做法也不是手改字节，而是用专门的资源编辑功能，让它按结构去改。

还有一类情况是「只想改一个字符串，不想动其他任何东西」。这时候用资源编辑的方式改表里那一项，确实比改文件更精准。但前提是工具支持按结构编辑，而不是让你自己去数字节。分不清这两者的区别，就别碰。

一句话总结：这张表是「结果」，不是「源头」。你的改动应该发生在源头上（文件、目录），让表跟着重新生成；反过来直接改结果，等于绕过了所有校验，出了问题也没有任何线索可循。

八、五种「改了没变」，对应五个位置

把「改了没变」这件事拆开，其实只有五种可能。每一种都能通过一个小动作确认，不需要反复试。

现象	大概率的原因	先试这个动作
图换了没变，其他都正常	改的那份不是设备挑中的那份	把所有同名文件都换掉
文案改了没变，只在一个页面	那句话不在资源里，是代码拼的	去代码目录搜生僻词
整片文字都变回原文	改的是另一套语言目录	看设备当前语言，两份都改
某个页面一打开就闪退	表和内容对不上（塞文件造成的）	回到反编译路径重新编译
换了图之后图变形或变糊	尺寸或比例与原来那份不一致	按原图尺寸导出

这张表里，第一行和第二行是最常见的两种，也是最容易混淆的。它们的区别在于「范围」：只有某一处没变，是那句文字的来源问题；整片都没变，是那一份文件有没有被挑中的问题。

第四行值得单独说。「表和内容对不上」这件事，不一定表现为画面不对，更常见的表现是崩溃。因为程序按表里的地址去取一张图，取到的可能是完全无关的字节，解码失败就崩了。这类崩溃的特点是：只在某一个页面出现，而且每次都在同一个位置。

第五行是「改对了但改丑了」。换图的时候，如果新图的尺寸和原图差得远，或者比例不同，界面上的表现可能是拉伸、可能是模糊、也可能被裁掉一块。这不是索引表的问题，是图本身的问题。但它常常和前者混在一起，因为两者都表现为「改完之后不对劲」。

把这五行记住，遇到问题时先对号，再动手。比起「再改一次试试」，先分类能省掉大部分重复劳动。

九、删掉一个文件，为什么会让应用崩

这一节讲一个和索引表直接相关、但很少被提到的现象：删资源比换资源危险得多。

换资源是「同一行，内容变了」；删资源是「这一行没了」。看起来只是少了一条记录，实际上牵动的东西多得多。

第一，程序里可能还在引用它。代码里写着「去拿名字叫某某的那张图」，你把这个文件删了，程序去拿的时候拿不到，直接抛异常。这就是最常见的崩溃原因。

第二，资源的编号可能被重新排列。表里的每一项都有一个编号，这些编号是按顺序生成的。删掉中间一项之后，重新生成表时，后面所有项的编号都可能往前移一位。而代码里引用资源用的是编号，不是名字——编号一变，代码就指到了另一个资源上。

第二个原因才是真正麻烦的。因为它不会崩溃，它会「显示成另一个东西」：本该是图标的地方显示成一句文案，本该是一张背景的地方显示成另一张不相干的图。这种现象很像「改串了」，而且极难联想到是删文件造成的。

所以有一条经验值得记住：能不删就不删。如果某个资源确实不想让它显示，优先考虑换成一个空白图、或者改成不引用它，而不是把文件删掉。前者是「内容变了」，后者是「结构变了」，风险完全不同。

如果确实必须删，那就要做一件事：删完之后把主要页面全部走一遍。不是抽查，是全部。因为编号位移的影响是弥散的，你没法预测哪个页面会受影响。这也是为什么改包的人常说：加东西不怕，删东西要小心。

加资源也有类似的坑，只是程度轻一些。新加的文件会多一行，通常不影响已有项的编号；但如果新加的东西和已有的重名，工具可能会覆盖掉原来那一份，现象就变成了「原来那个地方变了」。所以加之前，先确认这个名字没有被用过。

十、七个问题，都是真被问过的

一、这个文件能不能删掉，反正我也看不懂？

绝对不能删。它不是附带文件，它是所有资源的地图。删了之后，包能打开、能装，但一启动就崩——因为没有地图，程序不知道去哪里拿那几千个资源。遇到不认识的根目录文件，默认处理方式是「不动」。

二、为什么我换了图，包反而变小了？

多半是新图比原图小。这张表里记着每一项的大小，重新编译时会更新。包变小本身不是问题，但如果小得离谱（比如小了几兆），要确认是不是把某个目录整个覆盖掉了。判断方法：对比改前改后的文件清单，看有没有少文件。

三、我有四个同名文件，能不能只留最高清那个？

技术上可以，实际上不建议。低密度设备会拿不到匹配的那份，退而求其次去用高清那份再缩小——多数情况下能看，但内存占用会上去，老机器上可能卡。更稳的做法是四个都留，只把内容换成新的。

四、为什么同一个图标，在设置页很清楚，在桌面上却很糊？

两处用的可能不是同一份文件。设置页里那张通常是小尺寸的，桌面图标是另一个名字、另一组密度。桌面图标还有一套自己的机制（自适应图标），它由前景和背景两层组成，只换其中一层，效果往往不对。这个后面单独讲。

五、改了文案，模拟器上变了，真机上没变，为什么？

两台设备的语言或者屏幕参数不一样，挑中的不是同一行。最省事的验证方式：把两份（或多份）都改成同一句话，再装到真机上看。都变了，说明改动覆盖到了；还有没变的，说明还有第三份你没找到。

六、能不能只改表里的文字，不动文件？

如果你的工具支持按结构编辑资源，可以，而且这样更精准——只动那一项，不牵动别的。但如果是让你自己去改二进制字节，那就别做。区别在于：工具知道每一项在第几位，而你不知道。

七、为什么有些包的根目录里没有这个文件？

两种情况。一是这个包用了较新的资源组织方式，资源信息被分散到别的地方去了；二是这个包被加固或者特殊处理过，结构已经不是标准的包。这两种情况都不适合用常规方式改，前者要换工具版本，后者基本改不了。这一篇后面会专门讲加固包的特征。

十一、动手前三看，改完一验

把这一篇的内容压成四个动作，其中三个在动手前，一个在改完之后。

第一看：这个名字下面有几个文件。在目录里搜这个名字，数一下命中数。一个，改它就行；四个，四个都要改；一个都没有，说明它可能在代码里，或者名字被改过。

第二看：这些文件分别标着什么条件。看目录名上的后缀，是密度、是语言、还是屏幕方向。看清了就知道哪一份最可能被当前的测试设备挑中，也就知道该先改哪一份。

第三看：这台测试设备是什么情况。屏幕清晰度、系统语言、横竖屏。这三个参数决定了它会挑哪一份。如果手边有多台设备，最好用参数最「不常见」的那台来验——因为它最容易暴露覆盖不全的问题。

改完一验：在至少两台参数不同的设备上看。一台高密度中文、一台低密度英文，两台的组合不一样，能覆盖到大部分情况。只看一台，等于只验了一半。

还有一件事值得一起做：把这次改动的名字记下来。不用写成文档，一句话就够——改了哪个名字、有几份、分别在哪几个目录。下次同一个应用里再改类似的东西，这一句能让你直接跳过「数一遍」这一步。改包这件事的经验，绝大部分就攒在这些小记录里。

最后补一个反过来的用法：如果你手上要改的应用里有几百张图要换，别一张一张按名字找。先把要换的图按名字整理成一张清单，再回目录里核对每个名字有几份。核对这一步花的时间，比一张一张换了再验要少得多——因为「换了没变」这种返工，一次就够毁掉半天。

这四个动作加起来不到五分钟，但它们决定了你是改一次还是改五次。前面那个「三天没生效」的例子，缺的就是第一看——十秒钟能数清楚的事，花了三天才发现。

十二、五个听着有道理、其实是错的判断

这一节列的是我自己踩过的五个判断。它们都听着很有道理，所以特别容易被当成结论，然后把人带偏很远。

第一个错判：改了没变，一定是工具没生效。这个判断很自然，因为「重新打包」这个动作没有可见的反馈。但工具出错的概率远低于「改错了那一份」。正确的验证方式不是重启工具，而是去看那个文件到底有没有被换掉——看大小、看修改时间、看内容。文件确实换了而界面没变，问题就在「哪一份被用」上。

第二个错判：包里只有一个同名文件。很多人搜到一个就停了，因为搜索工具默认只显示第一个结果。而在资源目录里，同名文件出现四份、八份是常态。改用「查找全部」再看一遍，十次里有三四次会多出几个。

第三个错判：文字改了没变，一定在代码里。这条也很自然——上一篇讲的就是代码里的文字。但资源层自己的问题（改错语言目录、被另一处覆盖）现象一模一样。分辨方法很简单：把资源里那一句改成一段明显不同的测试文字，装上看变不变。变了，说明确实走资源；没变，才去代码里找。

第四个错判：删掉不用的资源能让包变小变快。包变小是真的，变快不一定。删资源会触发编号重排，重排带来的连锁问题前面讲过。而且很多「看起来没用」的资源，实际上被某个很少进入的页面引用着。瘦身是一件收益明确、风险也明确的事，值得单独一轮来做，不要在改别的需求时顺手做。

第五个错判：模拟器上验过就行。模拟器的屏幕参数、语言设置往往是最常见的那一组（高密度、默认语言），恰好是最容易被覆盖到的一组。真正的差异出现在那些参数不常见的设备上。如果手边只有模拟器，就把它的语言改成英文、分辨率调低，再验一遍——这相当于人为制造了一台「不常见」的设备。

这五个判断的共同点是：它们都让你「不再往下查」。而排查这件事最怕的就是提前停下来。判断本身不可怕，可怕的是把它当结论。所以更稳的习惯是：每得出一个判断，都顺手做一个小动作验证它。这些动作加起来不到一分钟，但它们决定了你是继续往下走，还是原地打转。

十三、一次返工的完整账：从「图没变」到「两份都要改」

把前面零散提到的东西串成一次真实的返工，看看时间到底花在哪儿。

需求：自家一个门店点单端，把首页顶部那张横幅换成活动新图，同时把横幅下面那行说明文字改掉。

第一轮，五分钟。换图、改字、打包、装机。图没变，字变了。判断是「图换错了位置」，于是回头找。

第二轮，十分钟。在目录里搜这个名字，发现有四份，分在四个密度目录。于是四份全换、重新打包。装机之后图变了。到这一步应该结束了，但没有——因为在平板上打开，图是糊的。

第三轮，二十分钟。平板的屏幕密度更高，四份里最高那份的尺寸不够。这不是索引的问题，是素材的问题：新图导出的尺寸只有中号那么大，放到高密度设备上就被放大了。重新按最高密度所需尺寸导出一份，四份一起换掉，平板清楚了。

第四轮，十五分钟。回头验文字。中文环境下是对的，把设备切成英文再看，说明文字变回了原文。原因是资源里有两套语文案，只改了一套。两套都改，再验一遍，通过。

整个过程一个多小时。如果一开始就做三件事：数清有几份、确认最高密度那份的尺寸够不够、确认有几套语言，这个活二十分钟就能做完。

这一轮里还有一个没被算进时间的成本：每次打包都要等。一分钟的编译等上四轮就是四分钟，看起来不多，但它会打断思路——等的时候你会去做别的事，回来之后要重新想起「我上次改到哪儿了」。返工的真正代价，往往在这种切换里。而避免返工的办法，就是开头那三分钟。

所以后来我们的做法变成了一条死规矩：凡是换图，先看几份；凡是改字，先看几套。两句话，十个字，但它把「一轮一轮试」这件最耗人的事挡在了门外。

而这三件事加起来不到三分钟。这就是这一篇最想说的东西：「改了没变」这件事的解法，几乎从来不是「改得更好」，而是「先看清楚有几个」。看清了，一次就过；没看清，就是一轮一轮地试。

十四、为什么它是所有改包问题的公共分母

改包遇到的问题看起来很杂：图没变、字没变、打开就崩、显示串了、平板糊了。但如果往下追一层，其中一大半最后都落到这张表上。

原因很简单：这张表是「程序要什么」和「包里有什么」之间唯一的连接点。程序不认文件名，也不认目录结构，它只认表里的那几行。所以只要表和实际内容有一点不一致，现象就一定会在界面上出现——而且出现的方式取决于差在哪儿，于是看起来就像很多种不同的问题。

这也解释了一个常见的困惑：为什么同一个操作，有时候成功有时候失败。比如改一句话，有时候一次就成，有时候怎么改都不生效。差别不在操作，在那句话背后有几行记录、这些行分别被谁引用。操作是一样的，被操作的对象不一样。

理解了这一层，改包的思路会有一个变化：从「我要改这个东西」变成「我要改这个东西的所有份」。前者是内容思维，后者是结构思维。内容思维适合改一张独有的图；结构思维适合改任何可能有多份的东西——名字、文案、图标、颜色、尺寸。

而结构思维的核心动作只有一个：先查一遍「这个名字下面有几个」。这个动作不花钱，也不需要任何工具，就是在目录里搜一下。但它是这一整篇里最值钱的一句话。

也正因为如此，这份「表」出问题的时候，症状往往不像「表的问题」，而像「某个页面的问题」。人会自然地去修那个页面——改布局、改颜色、改文案，全都不起作用，因为问题根本不在那一层。这就是为什么这一篇值得单独拿出来讲：它教的不是某个操作，是一个更容易找到正确方向的位置。

顺带说一句：这也解释了为什么用工具改、比自己改更稳。因为工具在做这件事时，是「按名字改所有份」，而人很容易只改眼前看得见的那一份。这不是能力差别，是注意力分配的区别——人盯着一处，工具盯着一类。

十五、把这件事教给别人，三句话就够

如果要讲给一个刚接触的人听，讲原理听不进去。三句话，他能记住并直接用上。

第一句：包里一个名字常常有好几份。换之前先数一遍，别只换看得见的那一份。

第二句：只改文件内容，不要直接往压缩包里塞文件。塞进去的包，表和内容就对不上了，症状是崩或者显示串。

第三句：宁可加，不要删。删文件会让后面所有东西的编号往前挪，挪完之后哪个页面出问题你根本猜不到。

三句话之后补一句提醒：改完之后至少用两台参数不同的设备看一遍，一台高密度、一台低密度，或者一台中文、一台英文。只看一台，等于只验了一半。

这四句话覆盖了这一篇 90% 的实用内容。剩下的——表的结构、编号怎么排、为什么不能手改字节——属于「知道了更好，不知道也能干活」的部分。真遇到需要动那一层的时候再学，效率高得多。

十六、换成一句话之后，这件事长什么样

如果用一个具体需求来对照，会更清楚这一篇讲的东西在实操里是什么位置。需求：把这个应用里所有地方的旧品牌名换成新品牌名。

手工的做法是这样：先搜资源里的文案，发现有三套语言各有一份；再搜图片，发现带旧 logo 的图有十几张，分散在不同密度目录；再进代码目录，发现有两处提示是拼出来的；最后可能还有一处藏在某个很少进入的页面里，是改了别的才发现。这个过程里，「改」这个动作只占很小一部分，绝大部分时间在「找全」。

而这件事的本质，正好就是这一篇说的：一个名字对应多份内容，你要做的是把这一类的所有份都改掉。人做这件事的难点不在技术，在耐心和记性——找到第三处之后，很容易以为找完了。

在「安卓修改大师智改工坊」里，这个需求是这样表达的：说清「把界面上的某某改成某某」，工具会按名字去资源里找所有份，包括不同语言、不同密度的那些；同时它也会去代码层找一遍拼出来的情况。你不必自己记住「刚才那个名字有四份」，因为查找是按类别走的，不是按你看得见的那一处走的。改完重新编译，索引跟着一起重建，剩下的就是装机验收。

这个差别在单次操作上不明显，但在「批量」这件事上会放大：人改十处要记住十次，工具改十处只需要一次说清。而改包这件事，实际上大部分都是批量——一个应用里同一个品牌名出现在几十个位置，是很常见的。

十七、用过的人怎么说

五条反馈对应五件事：同名多份只改了一份、直接塞文件会让表和内容对不上、删资源的代价是编号位移、动手前先数一遍、多语言要改齐。而这五件事，正好是这一篇的五节。

第二条那句"用压缩软件把图拖进包里"，是这一篇里最值得警惕的一个操作。因为它太快了——快到你不会觉得它是一个「操作」，只会觉得它是一次保存。而它破坏的恰恰是那个看不见的连接点。

---

只需说话，就能让应用变成你想要的样子。而在"改了没变"这件事上，这句话背后还藏着一句提醒：说清"换成哪张"之外，最好再说一句"所有尺寸都换"。剩下的交给安卓修改大师智改工坊——它按名字去找，而不是按你看得见的那一处去找。