写死在代码里的那句话：什么时候才该动 smali

改包改到一定程度，一定会遇到一种情况：这句话明明在界面上，但你把 strings.xml 翻遍了、把 layout 翻遍了、把所有语种的 values 都翻遍了，就是找不到它。于是你开始怀疑自己是不是漏了哪个目录，是不是工具没刷新生效。

而真相往往是：这句话根本没写在资源里，它是代码里拼出来的。而代码在包里是编译过的（dex），要改它，就得进到 smali 那一层。

这篇文章讲清三件事：什么情况下必须动 smali、smali 里能改什么不能改什么、以及为什么大多数时候你其实不该进去。最后一条最重要——因为进去之后的成本，和改资源完全不是一个量级。

只需说话，就能让应用变成你想要的样子。而在「安卓修改大师智改工坊」里，像"把所有提示语里的某某改成某某"这类需求，可以直接说清，工具会去资源里找、也会去代码里找——你不需要自己判断"它在哪一层"。想先看看一个包的代码层长什么样，可以从 https://www.apkeditor.cn/ai-version.aspx 下载「安卓修改大师智改工坊」，反编译之后打开 smali 目录看一眼。

一、三种"怎么也找不到"，说明这句话在代码里

先给一个判断标准：什么现象说明"它在代码里"。下面三种情况，基本可以直接跳到 smali，不用再在资源里翻了。

第一种：这句话是"拼出来的"。比如"当前版本 3.2.1""还剩 5 次机会""已为您找到 12 条记录"。这类文字里带着会变的数字，资源里只能存"模板"或者干脆没有，最终显示的是代码拼出来的结果。

第二种：这句话只在"某个条件成立时"才出现。比如"网络不太好，请稍后再试""您的账号已被停用""该商品暂不支持配送"。它们藏在判断分支里，平时看不到，所以你在界面上翻不到、在资源里也搜不到。

第三种：这句话是"第三方组件"提示的。比如某个登录、支付、地图的组件，它自己带着文案，不走你的资源。这类情况改 smali 也不一定有效，因为它可能在另一个包里（原生库或者远程加载）。

三种情况里，第一种和第二种可以尝试动 smali，第三种通常不该动。而判断"是哪种"，有一个很快的办法：把这句话里的数字或条件去掉，只搜那部分固定的文字。搜得到，是模板；搜不到，是拼的。

还有一类特殊的：这句话在资源里确实有一份，但界面显示的不是它。这种情况最常见于"改了资源没生效"——因为代码里另有一份覆盖了它。这时候你先要确认"哪一份在生效"，而不是急着改第二份。

判断"哪一份在生效"的方法很土但有效：把资源里那份改成一个明显假的文字（比如"测试测试"），打包装上，看界面显示的是不是它。是，说明资源生效；不是，说明代码里那份覆盖了。这个动作五分钟，能省掉一整轮猜。

而"测试测试"这个做法还有一个好处：它让你确认"这条链路是通的"。因为如果连"测试测试"都显示不出来，那说明你改的位置从一开始就错了，后面所有努力都是白费。

把这一节压成一句：找不到的时候，先判断"它是模板、是分支、还是第三方"。前两种可以往下走，第三种就该停手——因为那不是"改包"能解决的问题。

二、smali 里，你只需要认三样东西

smali 长什么样？第一次打开的人通常会愣一下：一行一个指令，满屏的寄存器名。它不像 java 那样有 if、for、return 的关键词，而是用 invoke、move、const 这些词加编号来表达同样的意思。

但你不必读懂全部。你只需要认得出三样东西：字符串、方法调用、判断跳转。字符串是 const-string 后面跟一段引号里的文字；方法调用是 invoke- 开头的一行；判断跳转是 if- 开头的一行，后面跟着一个标签。

这三样东西就够你定位"那句话在哪"了。因为你要改的九成是字符串——搜到它，看它在哪个方法里，改掉引号里的内容，就完成了。而那两样（调用、跳转）你只需要"别碰"，不需要"读懂"。

举一个具体的例子。假设你在某个文件里搜到了这样一行：const-string v1, "\u7f51\u7edc\u4e0d\u597d"。这里的 \u 是转义写法，代表中文。你要做的就是把引号里换成新的文字（同样用转义写法），保存，打包。

为什么中文要写成转义？因为 smali 文件对非 ASCII 字符的处理不如资源文件宽松。直接写中文有时能过、有时会在打包时报错。用转义最稳，虽然看起来不直观，但它在任何环境下都一样。

还有一点要知道：一个字符串可能在很多个文件里出现。比如"确定""取消""请稍候"这种通用词，几十个文件里都有。你要改的往往只是"某一句"，所以要结合上下文判断——看它附近调用了什么方法、出现了什么别的文字。

而"结合上下文"这件事，是 smali 里最花时间的一步。因为你得在一个几百行的文件里，判断"这一处字符串是不是我要改的那一处"。而这正是"动 smali 贵"的原因——不是难，是慢。

所以有一个很实用的策略：先在资源里找"最接近的那句话"，用它的措辞去反推代码里可能怎么写。因为同一个应用的文案风格是一致的，你找到资源里那句"请检查网络后重试"，就更容易在代码里认出"网络连接失败，请重试"是同一处逻辑。

把这一节压成一句：smali 只需要认三样——字符串、调用、跳转；你只改第一样，另两样别碰。而这个"只改一样"的克制，是动 smali 最重要的纪律。

三、改字符串可以，改判断要三思，改调用基本不要做

在 smali 里，有两类改动：改值，和改逻辑。它们看起来只差一点，实际后果差一个量级。而分清这两类，是进 smali 之前必须做的事。

改值：把一条字符串常量换成另一条、把一个数字换成另一个。这类改动不动程序结构，只换内容。它可能出错（比如转义写错导致打包失败），但错了会立刻发现，不会装上了才崩。

改逻辑：改一个判断条件、加一个分支、跳过一个调用、把不通过就退出改成不通过也继续。这类改动会改变程序的行为路径，而路径一变，很多原本不会被执行到的代码会被执行到——包括那些早就写好但一直没被触发过的分支。

举个具体的：有人想把试用到期就弹窗改成不弹。看起来只是把一个判断反了一下，但那个判断后面可能还跟着清理缓存、跳转到购买页、记录一条统计。你把它反了，这些动作全都不发生了；而如果它们之中有一个是初始化的一部分，应用就会在别处出问题。

所以一条很硬的界线是：改字符串可以，改判断要三思，改调用基本不要做。因为字符串改了，最坏结果是文字不对；判断改了，最坏结果是某个功能静默失效；调用删了，最坏结果是崩在很远的地方。

而现实里，很多人要求改逻辑的时候，真正想要的其实是改文案。比如别让他看到这个提示——可能只是把提示词改成一句更友好的话就够了，而不需要去掉整个判断。理解需求背后的意图，往往能让你避开最危险的那条路。

还有一类看起来像值、其实是逻辑的：资源引用。比如把某个地方引用的图片名换一个——这不是改字符串内容，是改它指向哪个资源。改错了不会崩，但会显示成一张空白或者一个错图，而这类问题在界面上很难一眼看出来。

判断这次算不算改逻辑，有一个简单的自问：改完之后，程序会不会走到原本走不到的地方。会，就是改逻辑；不会，就是改值。这一问能挡住九成的风险动作。

把这一节压成一句：动手之前先问我是在改字，还是在改路。改字可以试，改路要想清；而绝大多数看起来必须改路的需求，换个说法就能变成改字。

四、第一个实例：那句提示改了四十分钟

第一个实例，是我们自家门店端里的一句提示。那句提示是当前门店未开通此项服务，请联系店长，出现在会员查询的一个二级页里，出现频率很低。

以前怎么做：运营要求把它改成该门店暂未开通，可致电客服。我先在资源里搜未开通，没有；再把各语种翻遍，也没有。最后在 smali 里搜这三个字，搜到了三个文件。

接下来的十分钟，全花在判断是哪一处上。三个文件里，一个在权限校验的类里、一个在会员卡的类里、一个在通用提示的类里。结合那个页面的功能，我把目标锁定在第二个，改完打包，装上，进到那个页面——文字变了。

现在一句话怎么做：说清会员查询里那句未开通的提示要改成什么，写清新的电话。「安卓修改大师智改工坊」会在资源与代码层一起找，找到之后替换那一处字面量，其余不动。

改完怎么验证：不是只看那一个页面，而是确认别的地方没被改。因为未开通这三个字在别的页面里也可能出现，而它们分别属于不同的逻辑。所以我走了三处：会员查询（应该变）、权限设置页（不该变）、开通记录的列表（不该变）。

这次之后我们记下了一条：改代码里的文案，验证要看两处以上。一处是应该变的，一处是不该变的。只看前者，你无法确认自己改的是那一句还是所有句。

而这件事真正的成本，其实不在改，在找。三个文件、每个几百行、要在里面判断哪一处是，这一步花了大部分时间。而找之所以慢，是因为代码里没有注释、没有界面上下文，只有一行行指令。

这也是为什么改代码里的文案应该被当成一件要排期的事，而不是顺手改一下。顺手改的预期是五分钟，而实际可能四十分钟；预期和现实的差，就是焦虑的来源。

把这次压成一句：改一句写在代码里的提示，值十分钟的改动、三十分钟的寻找、五分钟的验证。知道这个比例，你就能在别人问这个快吧的时候，给一个诚实的回答。

五、第二个实例：那行版本信息是拼出来的

第二个实例更典型：一个看起来是文字、其实是拼接的版本行。那个应用是内部的学习端，设置页底部有一行版本信息，前半段是版本号，后半段是内部试用。

以前怎么做：要求把后半段改成华东。我先改了清单里的版本名，那行字没变；又在资源里搜内部试用，搜到了，改掉，还是没变。最后才发现，那行字是代码里拼的：前半段取版本号、后半段取一个渠道标识，中间用括号拼起来。

这意味着改资源没用——因为资源里那句是另一处的文案，不是这一处。而真正要改的，是那个渠道标识的字符串，或者干脆把整个拼接逻辑换成一个固定的字面量。前者是改值，后者接近改逻辑。

我们最后选的是改值：改那个渠道标识的字符串。这样拼接逻辑不动，只是后半段变成华东；版本号那半段跟着清单走，以后发版自动变。这个做法最稳，因为它没有改变任何路径。

现在一句话怎么做：说清要把那行版本信息里的内部试用改成华东，版本号继续跟着清单走。工具会去代码里改那个标识字符串，而不动拼接方式。

改完怎么验证：两件事。第一，看设置页那行字是不是变成了版本号加华东；第二，改一次清单里的版本名，再打一次包，看那行字的前半段有没有跟着变——第二件事是在验证拼接逻辑还在，而不是被我们顺手改死了。

第二件事听起来多余，但它是改值和改逻辑的分界线。如果你把那行字改成了一个固定字符串，第一次验证会通过，第二次就不会变——而那意味着以后每次发版，这行字都要手动改一次。

这个实例还带出一个经验：改代码里的文字，优先改最小的那个字符串，而不是整句。因为最小的那个（渠道标识、状态词、单位）往往只在一处使用，而整句可能被多处复用。改小的，影响面可控。

把这次压成一句：看到带变量的文字，先找那个变量，别改整句。因为整句是结果，变量是来源；改来源，逻辑还在；改结果，逻辑就死了。

六、动 smali 的三条纪律

如果确定要动 smali，有三条纪律值得守。它们不是最佳实践，是踩过坑之后总结出来的最低要求。

纪律一：一次只改一处，改完立刻打包验证。因为 smali 的错不会在保存时报出来，只会在运行时崩。而一次改三处，崩了你就不知道是哪一处。改一处、验一处，虽然慢，但每一步都是确定的。

纪律二：只改引号里的内容，不动引号外的一个字符。包括空格、逗号、寄存器编号。因为 smali 对格式敏感，多一个空格可能没问题，少一个逗号一定打包失败。而打包失败还是好的，最怕的是打包成功、运行崩。

纪律三：改完把主要路径全走一遍，不只是你改的那一处。因为代码是一张网，你改了 A 处的字符串，可能 B 处的判断依赖它（比如按文案做匹配）。这类依赖在源码里看得见，在 smali 里几乎看不出来。

三条纪律之外，还有一个操作习惯：改之前把那个 smali 文件复制一份出来。因为 smali 文件不像资源那样改错了肉眼可见，你很难凭记忆恢复原文。留一份副本，出问题直接覆盖回去，比逐字回退快得多。

而留副本这件事，还有一个更省事的版本：改之前把整个工程目录复制一份。目录几十兆，复制十秒钟，但它能让你在任何时候回到改之前的状态——包括那些你已经忘了自己改过的地方。

还有一条不写在纪律里但同样重要的：改完在项目里记一句改了哪个文件、哪一行、为什么。因为半年后你再打开这个工程，看到的是一堆你完全不认识的 smali 文件；而那一行记录，是唯一能告诉你这里被动过的东西。

把这一节压成一句：动 smali 的正确姿势是小步、留底、全路径回归。三步都做到，风险可控；少一步，就是在赌。

写到这里，前面讲的多半是原理和两个具体的例子。下面这几个问题，是真正动过 smali 的人最常回头问的，顺序按被问到的次数排。

七、七个最常被问到的问题

一、我完全不懂 Java，能不能动 smali？

能，但要有分寸。smali 是给机器看的语言，语法比 Java 简单得多——一条指令一行，参数用逗号隔开，寄存器用 v0、p1 这样的名字。你不需要会写程序，只需要会认三样东西：哪一行是字符串、哪一行是调用、哪一行是跳转。前面第二章已经把这三样讲清了，剩下的就是耐心。
但有分寸的意思是：只做替换，不做设计。你能把一句话换成另一句话，不该去想让程序多一个功能、多一个入口、少一次校验。前者是改字，后者是改逻辑，改逻辑需要的知识量和改字完全不是一个量级。

二、改完打包装不上，是不是改坏了？

多数情况下不是。装不上最常见的原因有三个，且都在打包签名环节，不在 smali：签名和原来那份不一致（覆盖安装要求同签名）、versionCode 比已装的那份低（系统拒绝降级）、包名被改过（系统当成另一个应用，而旧的那份还占着）。
真正的判断方法：先卸载手机上的旧版，再装新包。能装上，说明包本身是好的，问题出在覆盖安装的三条件上；还是装不上，再回头查 smali。这个动作能把排查范围一下砍掉一大半。

三、中文要不要转成那种斜杠加字母的写法？

要。smali 文件里不能直接写中文，中文会以统一码转义的形式出现，形如反斜杠加 u 再跟四位十六进制数字。你去搜一句中文，搜不到，就是因为文件里存的是转义后的样子。
实用做法有两个：一是先在资源里搜中文原文，如果资源里有，就别进 smali；二是确实要在 smali 里改中文时，先把要写的那句话转成转义形式，再整段替换，别手打。手打十六进制极容易错一位，错了不会报错，只会在界面上显示成方块或者乱码。

四、同一句话在几十个文件里都有，改哪个？

先看目录，再看上下文，最后看页面。三步。
看目录：smali 目录下面通常按包名分层，比如有个目录叫会员、有个目录叫订单，页面上的提示大概率在跟它功能同名的目录里。看上下文：打开文件，往上看二十行，看这个字符串被传给了哪个方法——传给设置文本的方法，说明是显示用的；传给日志方法，说明是打日志用的，改了没用。看页面：如果还是分不出来，就一个一个改、一个一个打包试，虽然笨，但两个来回内基本能锁定。
最不该做的，是把几十处一起批量替换。里面很可能有一处是给日志或者后台接口用的，改了之后界面看着对了，别的地方悄悄出了问题。

五、能不能只改文案，完全不动行为？

能，而且这正是应该守住的那条线。只改字符串常量，不动判断、不动调用，程序的分支结构、执行顺序、调用关系全部保持原样，它能出的问题就只有一种：文字显示得不对。这种问题的后果是看得见的、可以立刻发现、可以立刻改回去的。
一旦动了判断，问题就变成了「某些情况下会走到原本走不到的地方」，而「某些情况」你可能一次都测不到。它可能在交付两周后、在某个特定机型上、在某个特定操作顺序下才出现。这类问题最难查，因为现象和改动之间隔得太远。

六、改完之后界面上多了几个方块，是怎么回事？

九成是字符编码的问题。可能是你写入的转义少了位数、可能是文件保存时被改成了别的编码、也可能是这个字体不包含你写进去的那个字。前两种要改文件，第三种要把字换成常用字。
判断方法很简单：把同一句话改成一个纯汉字、常用字的短句，重新打包。如果显示正常，说明是字体缺字，换成别的表述就行；如果还是方块，说明是转义或编码写错了，回到文件里逐字符核对，特别注意反斜杠和 u 之间不能有空格。

七、源文件我还留着，为什么要先备份一份改过的？

因为你备份源文件，是为了「能回去」；备份改过的，是为了「能比对」。这两个用途不一样。
改坏的时候，你需要的往往不是整个退回原点，而是知道「我到底改动了哪几行」。把每次改动前的那个 smali 文件另存一份，命名里带上日期或者序号，出问题时拿两份文件做对比，差异一眼就能看出来。没有这份对照，你只能靠记忆回想改过什么，而人在着急的时候记忆是最不可靠的。

八、改完就崩：三类最常见的崩法，和它们的共同点

前面说的都是「改了不该改的会出问题」，但没说具体会出什么问题。实际遇到的崩溃，八成落在下面三类里，而它们的共同点惊人地一致：都会在崩溃的那一刻指向你改过的那一行。

第一类，转义写错。这是最高频的。中文没转成统一码就直接写进了 smali，或者转的时候少了一位十六进制数字，或者反斜杠和 u 之间多了一个空格。这类错误的特点是不报错——打包能过、签名能过、安装也能过，一直到你打开那个页面才崩。因为它是运行时才去解析那个字符串，解析不出来就抛异常。

判断方法：如果崩溃只在打开某一个页面时发生，而且那个页面正是你改的那句话所在的位置，八成就是它。回到文件，把那一行整句换成一句纯英文的短句重新打包，如果不崩了，就锁定是转义问题。

第二类，寄存器编号被动了。smali 里每条指令都会引用寄存器，形如 v0、v3、p1。你在替换字符串的时候，如果顺手把整段复制粘贴过去而没注意末尾的寄存器参数，就等于让一条指令去读一个不存在的寄存器。这类崩溃来得更直接——应用一启动就退出，连页面都进不去。

这类问题是最好防的：改的时候只看引号内的内容，引号外的每一个字符都当它是活的。真要动那一行的其他部分，说明你要做的已经不是「改字」了，该停下来想想这件事是不是该由别人来做。

第三类，跳转标签丢了。smali 里的条件跳转靠标签定位，形如冒号加一串名字。标签本身没有内容，很容易被认为是「空的、可以删的」。一旦删了，跳转就失去了目标，打包时直接报错，或者打包能过但运行时跳到一个不存在的位置。

这类反而是三种里最「友好」的：多数情况下打包阶段就会拒绝，不用等到装到手机上。所以如果你打包就失败了，先别怀疑自己是不是把整个工程弄坏了，很可能只是删了一行看着没用、实际上很重要的东西。

三类的共同点，是都能定位。崩溃日志里会写明是哪个类的哪个方法出的问题，拿这个名字回到 smali 目录里搜，几秒钟就能找到对应的文件。所以真正让人难受的从来不是「崩了」，而是「崩了但不知道该看哪儿」。只要你知道崩溃点和你的改动点是同一处，剩下的事就是逐字符比对。

九、为什么改 smali 的返工，总比改资源贵

做过几次之后你会发现一个规律：改资源出错，返工十分钟；改 smali 出错，返工常常要一小时以上。不是因为 smali 更难，而是因为两者的验证成本完全不同。

改资源时，改动和现象是一对一的。你改了一张图，界面上那张图变了；你改了一个颜色，那个控件变色了。出问题时，你只需要看那一处，看一眼就知道对不对。

改字符串时，改动和现象是多对一的。那句话可能出现在三个页面、两个弹窗、一条通知里，你只测了其中一个。等你交付之后，用户在另一个地方看到了一句不对劲的话，回头找你，你才发现原来那句话被引用了五次。这就是为什么前面反复强调：改之前要搜全，改之后要走完整路径。

还有一个隐性成本：改 smali 会让你对这份工程的心理负担变重。改过资源的人，下次还敢改；改过 smali 又崩过一次的人，下次会绕着走。这种心态上的变化，其实才是最贵的部分——它让你在该改的时候也不敢改了。

十、一张对照表：什么该在资源里改，什么只能在代码里改

很多人进 smali，是因为在资源里没找到。但「没找到」有两种：一种是它本来就不在资源里，另一种是它在资源里但你搜的方式不对。这两种的处理方式完全不同，值得花一分钟分辨清楚。

下面这张表是按「你手上拿到的是什么」来分的。左边是你想要的改动，中间是它通常待的地方，右边是搜不到时该去哪儿。

你要改的东西	通常待在哪	资源里搜不到时
界面上的固定标题、按钮文字	资源里的字符串文件	检查是不是被别处引用覆盖了
带数字、带单位的提示语	多半在代码里拼接	改代码里那一小段固定文字
只在出错时才出现的提示	代码里，且被条件包着	先想办法让那个条件成立
某个开关、某个入口的名字	可能来自后台下发	先确认断网后它还显不显示
第三方组件自带的文字	在对方的包里	可改，但升级依赖后会丢
应用名、图标	清单文件 + 资源	不必进代码，清单里就能改
版本号那一行	清单文件，或代码里拼接	先改清单试，没变再进代码
页面的跳转顺序	代码里的判断	属于改行为，不建议做
某个功能开不开	代码里的判断 + 后台配置	属于改行为，不建议做

这张表里，前七行是「可以做」的，后两行是「最好别做」的。分界线就是前面说的那句：改字和改行为。表里最值得多看一眼的是第四行——那个开关名字看起来像本地文字，实际上可能是后台下发的。断网试一下，如果断网之后它还显示，那就是本地写死的，可以改；如果断网之后变成了空白或者默认文案，那它来自服务器，改包没有意义。

还有一个容易被忽略的格子：第三行。只在出错时才出现的提示，你在正常操作下永远看不到，于是会怀疑自己是不是改错了。正确的做法是先制造那个错误——关掉网络、输一个错的验证码、故意让接口超时。看到那句提示出现了，再去改它，改完再用同样的方式制造一次错误，看它有没有变。听起来麻烦，但这比在代码里瞎猜要快得多。

十一、一次完整的记录：从一句别扭的话，到能交付的包

前两个实例讲的是「判断」，这一段讲的是「流程」。用的是自家内部一个库存盘点端，改动很小：清点页底部的合计提示，原本写的是「共 N 个品项，其中 N 个待复核」，读起来像两份报表拼在一起，改成「合计 N 项，待复核 N 项」。

第一步，先在资源里搜。搜「共」「品项」「待复核」三个词，一个都没有。到这一步可以确认它不是写死的整句，是拼出来的——因为它里面带了两个数字。

第二步，进 smali 目录，搜「品项」这个较生僻的词。生僻词比常用词好搜，因为不容易被别的文案干扰。结果在三个文件里命中，分别落在盘点、调拨、报表三个子目录。

第三步，判断改哪一个。按照前面说的看上下文法，打开盘点那个文件，往上看二十行，发现这个字符串是被一个格式化方法接收的，参数里带着两个整数位。再打开调拨那个，同样结构，但所在的类名里带着调拨的字样。到这一步，改盘点这一个就够了。

第四步，写替换。原文要拆成三段保留：前面的「共」、中间的数字占位、后面的「个品项，其中」、再一个占位、最后「个待复核」。这次只动两处固定文字：「共」改成「合计」，「个品项，其中」改成「项，待复核」，末尾的「个待复核」改成「项」。数字占位一律不动。

第五步，打包、签名、装机。打开清点页，做了三组数据：零项、单项、三十七项。三种情况下数字都对，文字也都是新的。

第六步，走完整路径。这一步最容易被省，但它决定了这次改动是一小时的活还是一下午的活。除了清点页，还把盘点单详情、盘点历史、导出记录三个页面各点开了一遍，确认没有别的地方引用那几段文字。三个页面都正常，交付。

整个过程从开始到交付，四十分钟左右。真正用在改文件上的时间不到五分钟，其余都花在找和验上。这个比例很典型，几乎是所有 smali 改动的常态。所以如果有人问「改一句话要多久」，正确的回答不是「五分钟」，而是「大概半小时到一小时，看它藏得深不深」。

为什么这个流程里，第二步和第六步不能省

第二步搜生僻词，省不得。很多人在资源里没搜到，就直接去代码里搜「共」这种极常用的字，结果命中几百处，翻到第十页就放弃了，得出「这个应用改不了」的结论。其实只是搜索词选错了。挑一个句子里最不常见的词——通常是名词，像「品项」「复核」「台账」这种——命中数会一下从几百降到个位数。

第六步走完整路径，也省不得。前面那三个页面，如果只测了清点页就交付，万一导出记录里也用了同一段文字，用户在导出的时候会看到一半新一半旧的表述，那种感觉比原来的别扭更糟。

这两步合起来大概占二十分钟，但它们把「返工」的概率从可能降到接近零。而返工一次的成本，前面算过，是一小时起。

这份记录里，有三个地方值得单独记住

只改固定文字，不碰数字占位。这是让拼接类的句子变安全的关键。你改的是句子的骨架，数字还是程序自己填。这样无论数据是多少条，显示都正确。反过来，如果你图省事把整句连数字一起写死，那这个页面从此只会显示一个数字。

改完立刻打包，不攒着。有人习惯一次改五六个地方，然后打一个包一起验。听起来省时间，实际上出了问题你就得在五六个改动里挨个排除。一次改一处，看起来慢，但每一步都是确定的。

把改了什么写下来。不用写得多正式，一个记事本，每行一句：哪个文件、第几行、原句、新句、为什么改。这份记录在你三个月后再改这个包的时候，价值远超你当时的想象——那时候你已经完全忘了当初为什么这么改。

十二、为什么大多数时候，你其实不该进代码里

这一节可能会让前面几节的立场显得矛盾：花了这么长篇幅讲怎么改代码里的文字，最后却要劝你别改。但这恰恰是这个话题最该说清的一句。

原因是成本结构完全不同。同样是改一句话，如果它在资源里，动作是「打开文件→改→保存→打包」，两分钟，不需要理解任何逻辑，出错概率接近零。如果它在代码里，动作是「搜→判断是哪个→看上下文→改→打包→验主要路径」，四十分钟起，还需要懂一点汇编的读法。

四十分钟换两分钟，值不值，取决于这件事是不是非做不可。而实际遇到的情况里，一大半是「本来可以在资源里改，只是没找对地方」。

最常见的三种「误判成必须在代码里改」：一是资源文件有多语言版本，中文那份改了没生效，因为当前语言命中的是另一份；二是资源里的字符串被样式或者其他资源覆盖了，改了原文但显示的是覆盖后的；三是改的是另一个同名资源，这个应用里存在两个名字一样、内容不同的字符串，分别放在不同的目录里。

这三种情况有个共同点：它们都是「资源层的问题」，只是表现为「改了没变」。而很多人的第一反应是「资源里改不了，看来得进代码」，于是从一个两分钟的活，跳进了一个四十分钟的活，最后还是没改对。

所以进代码之前，先问自己一个问题：我确定资源里真的没有吗？确定的方法不是搜一次，而是搜三次：搜整句、搜句子里的一个生僻词、搜这句话里最独特的那个标点或符号。三次都空，再去代码里找。这三次搜索总共不到两分钟，但它能帮你避免后面那四十分钟。

那什么时候，确实只能在代码里改

有三种情形是绕不过去的。

第一种，句子里含可变部分。只要那句话里的数字、日期、姓名是程序运行时才确定的，它一定是拼出来的，资源里不可能存整句。这类改动其实不难，难的是你要认清哪些字是骨架、哪些位置是占位。

第二种，那句话根本不走资源。有些开发习惯把提示直接写在代码里，尤其在早期赶工的项目里很常见。这类文字在资源里搜不到，但在代码里往往能一次命中，反而好改。

第三种，同一个应用里几处文字需要区分开。比如两个页面用了同一句提示，你只想改其中一个。资源是共享的，改一处就两处一起变；只有在代码里改那一处的引用，才能做到只改一个。这种情况少见，但一旦遇到，就只能进代码。

把这三条和前面那条「先确认资源里没有」放在一起，你就有了一个很清楚的判断顺序：先确认资源没有，再看是不是拼出来的，最后看要不要区分同句。三步走完还没结论的，基本就不用改了。

一段可以直接照着做的判断流程

把上面这些压缩成一个可以照着走的流程，一共五步，每步都有明确的「否则」。

第一步，搜资源。搜到，就在资源里改，结束。搜不到，进第二步。

第二步，看句子结构。如果句子里有明显会变的部分（数字、日期、人称），基本可以确定是拼接的，进第三步；如果是一句完全固定的短句，也可以进第三步，但要先怀疑一下是不是在别的语言目录里。

第三步，进代码目录，用生僻词搜。命中一处，直接改；命中多处，进第四步。

第四步，看上下文排除。往上看二十行，看这个字符串被传给了什么方法。传给显示相关的方法留着，传给日志或者网络相关的方法排除。排除完还剩两处以上，进第五步。

第五步，一个一个试。改一处、打一个包、看一眼。虽然笨，但每一轮都在缩小范围，通常两轮之内就锁定了。

这五步里，最容易被跳过的是第一步和第二步。而跳过它们的代价，往往是后面多花半个小时。

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

如果要把这一整套东西讲给一个完全没碰过的人听，讲原理他是听不进去的。有效的办法是给三句可以直接背下来的话，让他遇到事的时候能想起来。

第一句：能不在代码里改，就别在代码里改。先搜资源，搜不到再说。这一句能挡掉一半本来不该发生的操作。

第二句：代码里只改引号内的字。引号外面哪怕一个空格，都是活的，不是排版。这一句能挡掉八成崩溃。

第三句：改完先打一个包，只测这一件事。别攒着改五处再一起验，也别顺手把别的需求捎上。这一句能让你在出问题时知道是哪一处的问题。

三句话之后可以补一句提醒：如果改完发现界面上出现了方块，先换一句纯汉字的话重新打一次包，这样能立刻分出是字体缺字还是写错了转义。

这四句话加起来不到一百个字，但它们覆盖了这个话题 90% 的实际风险。剩下的 10%——同一个字符串被引用多次、拼接逻辑的判断、打包签名的三条件——属于做过三五次之后自然会碰到的东西，那时候再讲一遍，比一开始就全塞给他有用得多。

最后，回到那句被写死的话

回过头看，这件事最反直觉的地方在于：在界面上看到的一句话，可能来自四个完全不同的地方——资源文件、代码里拼出来的字符串、后台下发的配置、以及第三方组件自带的内容。它们看起来一模一样，改起来的方法却完全不同。

分辨它们的方法，其实不需要多少技术，只需要一个固定的顺序：先看它会不会随数据变化，再看它断网后还在不在，然后搜资源，最后才进代码。这个顺序不花钱，但能省掉大部分白干的时间。

而当你真的走到最后一步、进了代码目录之后，要守的那条线也很简单：改字，不改逻辑。这句话听着保守，但它是一条被反复验证过的经验——能改字解决的问题，几乎都能安全地解决；一旦开始改逻辑，问题就从「显示得对不对」变成了「会不会走到不该去的地方」，而后者往往要等到交付之后才发作。

说到底，一个应用里最难改的从来不是代码，是那些你根本不知道它藏在哪儿的东西。而想让它变得好改，办法不是把每一处都翻一遍，是先把「它在哪儿」这件事分清楚——分清楚了，剩下的就是耐心。

十四、用过的人怎么说

五条反馈，讲的是五件事：拼出来的句子只能进代码改、引号外的字符一个都不能动、判断顺序能省掉大半时间、看不见的提示要先让它出现、改动记录在几个月后才有价值。而这五件事，恰好对应前面五节的内容——来源、边界、流程、验证、留痕。

第一条里那句"以为是自己搜错了"，大概是这个话题里最有代表性的一句。因为当你在资源里搜不到的时候，第一反应总是怀疑自己的搜索方式，而不是怀疑"它本来就不在资源里"。而这个区别，决定了你接下来是再搜十分钟，还是直接进代码目录省下那十分钟。

---

只需说话，就能让应用变成你想要的样子。而在"代码里那句话"这件事上，这句话背后还藏着一句提醒：说清"换成哪句"之外，最好再说一句"只改这句话，别动别的"。剩下的交给安卓修改大师智改工坊——它把检索、改动、打包、签名这几步串成一条线，你只需要把要求说清楚，改哪儿、怎么验，交给流程。