五年的会员端：一个应用怎么被改了二十次还没乱

先说一个很现实的处境：你手上有一个自己做的应用，已经用了好几年。——它不是"产品"，是"工具"——一个书店的会员查询端，会员报手机号，店员查积分、查余额、查最近买过什么。——功能五年没怎么变，而它被改过二十几次——换过名字、换过配色、换过启动页、加过一个入口、藏过两个入口。

这种"长期被人反复改的小应用"，是最容易被忽略的一类东西。——因为它不值得立项、不值得排期、也不值得写文档——每次都是"顺手改一下"。——而二十次"顺手"之后，你会发现一件很尴尬的事：没有人能说清它现在为什么是这个样子。

而五年这个时间长度，还会带来两个更麻烦的变化。——一是"人换了"——当初改它的人可能已经离职，接手的人只能看到结果，看不到过程。——二是"机器换了"——五年前的手机还在用，而新的手机屏幕更长、系统更严、权限更细。——于是"这个应用能不能在老机器上跑"这件事，从"不用想"变成了"每次都要想"。

「安卓修改大师智改工坊」在这种长期场景里的价值，和短期场景不太一样。——短期场景里它省的是"做的时间"；长期场景里它省的是"想起来的时间"——因为每个改动都是一个项目、一份配置、一段历史，翻得到。——而"翻得到"这件事，在第五年比在任何时候都重要。

只需说话，就能让应用变成你想要的样子。而在"用了五年"这个场景里，这句话还要加一句：说过的每一句话，最好都留得下来。想先看看它怎么把"一个项目"和"一段历史"绑在一起，可以从 https://www.apkeditor.cn/ai-version.aspx 下载「安卓修改大师智改工坊」，拿一个自己的应用建个项目，改一句话，再回头看那个项目目录里多了什么。

一、二十次改动之后，最缺的不是功能，是"为什么"

一个被反复改过的小应用，最典型的症状不是"不好用"，是"不敢动"。——因为它里面有二十处"不知道为什么要这样"的地方——某个按钮的位置、某段奇怪的空行、某个明明没用却一直留着的入口。——而每次想删掉它们，都会有人跳出来说"那个不能动，当初是有原因的"——而谁也说不清是什么原因。

而这件事的根源，是"改动"和"原因"被分开了。——改动留在包里，原因留在人的脑子里——而人会走、会忘、会记错。——所以"长期维护"这件事真正的功夫，不是"改得好"，是"记得住"。

而"记得住"这件事，工具能帮到一半。——因为每个项目目录里都有一份 history.ini——它记的是"这个项目被说过什么"。——而按设计，它只留用户的原话——不加工、不总结——所以它记下来的，恰好是"当时那个人是怎么想的"。

而"只留原话"这个设计，在长期场景里非常有用。——因为原话里有语气、有背景、有"因为……所以……"——而这些恰恰是总结会丢掉的东西。——比如"把积分那行字放大点，老太太看不清"——这句话里，"老太太"三个字比"放大字号"更有信息量。

但原话有一个短板：它按时间排，不按主题排。——二十次改动之后，history.ini 是一串按顺序的记录——而你想知道"配色一共改过几次"，只能一条条翻。——所以除了 history.ini，还该有一张自己维护的表——一张"改动台帐"。

改动台帐不用复杂，四列就够：日期、改了什么、为什么改、谁提的。——而四列里，"为什么"最重要——它是唯一在第二年还有人看的一列。——而"谁提的"这一列，往往能解释"为什么这件事一直没改"——因为提的人已经不在那个岗位上了。

最后说一句关于"该不该留"的话：长期维护最怕的不是"留了没用的东西"，是"删了有用的东西"。——所以"看不懂的别急着删"——先把它记进台帐，标一个"待确认"，等下次有人问起，再决定。——而这个习惯，能让你的应用在第五年还保持着"敢动"的状态。

二、老机器还在用，这件事会限制你一大半选择

"用了五年的应用"这句话，隐含了一个很容易被忽略的事实：还有五年前的机器在用它。——因为这种东西往往是"店里那台不换的"——能用就继续用，坏了才换。——于是你的用户里，混着最新款和老款——而它们的屏幕、系统版本、性能都不一样。

这件事首先限制了"包能不能装"。——因为安卓的安装包有一个"最低系统版本"的门槛——如果你的包要求一个比较新的系统，那老机器会直接提示"无法安装"。——而这个提示，用户看到的是"装不上"，你能看到的只有"他说装不上"。

所以长期维护的第一条纪律是：别顺手把"最低支持版本"抬上去。——因为"抬上去"这件事，在开发那边只是一个配置项，而在现场是"那三台老机器用不了了"。——而这三台老机器，往往恰好是"最忙的那家店"的。

其次是屏幕。——老机器的屏幕通常更小、分辨率更低、边框更厚——而你在新机器上觉得"刚好"的字号，在老机器上会显得更挤。——而"挤"这件事，在老机器上还会被系统的"字体大小"设置放大——因为用老机器的人，往往把系统字体调到最大。

这一点很值得单独说：系统字体放大，会把你的布局顶坏。——因为文字变大之后，一行能放的字变少——原本一行的标题会变成两行，原本对齐的两列会错位，原本刚好放得下的按钮会被挤出去。——而这种问题，在你自己的机器上永远复现不了——因为你的系统字体是默认的。

所以"长期维护"的验证里，最好固定加入一项：把一台机器的系统字体调到最大，再打开看一遍。——而这一项不需要任何技术，只需要进设置改两下。——而它抓到的问题，往往比"看十遍截图"都多。

第三是性能。——老机器打开一个复杂页面会慢——而这个"慢"，在设计阶段完全看不出来。——所以"少放一点东西"这件事，在长期场景里不只是审美，是可用性。——而这也是一个很实际的判断依据：如果你在犹豫"首页要不要再加一块"，就去老机器上打开一次。

把这一节收成一句：老机器不是"历史包袱"，是"你的一部分用户"。——而照顾他们的成本，其实很低——不抬最低版本、不改字号不加内容、把系统字体调大看一遍。——三件事都不花钱，而它们决定了"那几家店"会不会在某一天突然打来电话说"装不上了"。

三、升级会不会清数据：一句话讲清三条件

长期维护里最容易被问到的一个问题是："装新的会不会把我这儿的数据弄没了？"——而这个问题之所以让人紧张，是因为"数据"在这类小应用里往往就是"这半年攒下来的会员记录"——没有备份、没有云端。

答案可以用一句话讲清：能不能"直接覆盖安装"，取决于三个条件。——包名相同、签名相同、版本号不低于已装的——三条都满足，系统就会把它当成"同一个应用的新版本"，直接替换，数据保留。——任何一条不满足，系统就会拒绝安装，或者要求你先卸载。

三个条件里，"包名"最容易守住——因为你不会无缘无故改它。——而"签名"最容易出事——因为它有个陷阱：签名有两种常见做法，一种是用固定的密钥文件签，一种是"每个包随机生成一份"。——后者的好处是不用管密钥，坏处是每个包的签名都不同——于是新包永远装不上旧包，必须先卸载。

所以在长期维护的应用上，签名只能有一种做法：固定一份密钥，从第一次到第一百次都不换。——而那份密钥文件要单独备份——因为密钥丢了，你就再也打不出"能覆盖旧版"的包了。——而这一条，比任何文档都重要——因为它决定了"以后的每一次升级是覆盖还是重装"。

第三个条件"版本号"最容易犯的错，不是"忘了加"，是"加了但方向反了"。——因为版本号是数字比较——如果新包的版本号比旧包低，系统会认为你在"降级"，于是拒绝覆盖。——而"忘了加"反而是安全的——同号也算"不低于"，能装上，只是分不清哪个是新的。

所以长期维护的第三个纪律是：版本号只往上走，而且每次都要能看出"比上次新"。——而"能看出"这件事，靠的是"末位加一"——因为它简单、不会错、而且永远往上。——至于"哪个版本改了什么"，交给改动台帐，不要塞进版本号里。

而"数据会不会丢"这件事，还有一个更根本的答案：别让数据只存在手机上。——因为即使签名和版本号都守住了，手机也可能坏、可能丢、可能被恢复出厂设置。——所以真正稳的做法是"本地有缓存、服务端有底"——而这件事属于功能，不属于改包。——而如果你现在只有本地数据，那至少要做一件事：让它能被导出。

把这一节压成一句：包名不动、签名固定、版本号往上，三条守住，升级就不会碰数据。——而三条之外，还要给自己留一条后路——密钥备份、数据能导出。——因为"守住"和"保住"是两件事——前者靠流程，后者靠提前准备。

四、两个自家应用的实例：一次改名字，一次搬家

两个例子，都是我们自己内部在用的、年头不短的东西。——一个改的是"名字"，一个改的是"归属"——而两次都因为"用途变了"，不是因为"想好看点"。

例一：自家的会员查询端（改名字）。——这个应用是我们自己做的，最早叫"会员通"，后来改成了"会员查询"，再后来又加了门店简称。——三次改名，每次都只改一行字，而每次都要重新打一次包、重新发一遍所有门店。

以前怎么做：——前两次都是"找开发帮忙"——改一行字，等他有空，编译，导包，发群。——而问题在于"发的那个包"和"上一版"分不清——因为文件名都是"会员通.apk"，门店那边有人装了两个，桌面上一模一样的两个图标。——而更麻烦的是：改了名字之后，有些人的桌面图标没更新——因为覆盖安装之后，桌面缓存的还是旧名字。

现在一句话怎么做：——建项目，项目名带年份和版次，然后发一句："应用名改成『会员查询 · 中山店』，启动页标题也改成这个，图标不变，版本号加一格，其它不动。"——一句话，一分钟，一个包。——而"版本号加一格"这句固定加上，因为它决定了门店那边能不能直接覆盖。

改完怎么验证：——这里的验证有一条特别的：装完之后，把桌面图标删掉再拖回来，看名字是不是新的。——因为覆盖安装之后，桌面有时会沿用旧名字——而这个现象会让门店误以为"没装上"。——所以验证时不只是"打开看"，还要"看桌面"——而"删掉再拖回来"这个动作，能强制桌面刷新。

例二：自家的图书查询端（搬家）。——这个应用也是我们自己做的，最早是给仓库用的，后来门店也要用，于是从"仓库版"变成了"通用版"。——而"通用"这件事，不是改个名字就行——它涉及默认值、涉及权限、涉及"哪些字段该给门店看"。

以前怎么做：——最初的打算是"做一个新应用给门店"——但那意味着两套东西要同时维护。——而试了一个月之后发现：门店要的功能，八成仓库版都有——差的是"默认看到哪一批数据"和"几个字段该不该显示"。——于是改成"一个工程、两个配置"——而这正好是改包能做的事。

现在一句话怎么做：——建两个项目，从同一份工程出发。——门店版："应用名改成『图书查询 · 门店』，启动页写『门店查询』，默认筛选改成『本店』，首页隐藏『入库』和『调拨』两个入口，其它不动。"——仓库版保持原样，只把版本号跟着往上走——这样将来两个版本还能对得上。

改完怎么验证：——这次的重点是"藏掉了但没坏"——因为"隐藏入口"这件事，最怕的是"藏得太多，把要用的也藏了"。——所以验证的方式是：让门店的人按他们一天的流程走一遍，遇到"找不到"就记下来——而记下来的每一条，都是在告诉你"哪一处藏错了"。——而这个方法比任何清单都准，因为它是按"他们怎么干活"排的。

五、换人接手的时候，能留下的只有三样东西

长期维护的应用，一定会经历"换人"——原来改它的人调岗了、离职了、或者单纯不想再管了。——而接手的人打开电脑，看到的是：一个项目列表、一堆安装包、和一段没人说得清的历史。——而他能依赖的东西，其实只有三样。

第一样：能跑起来的环境。——也就是"打一个包需要什么"——工具在哪、密钥在哪、源包在哪。——而这件事最容易断——因为工具可能是随手下的、密钥可能是某人电脑上的一个文件、源包可能在聊天记录里。——所以最该做的一件事：把这三样放进同一个文件夹，写上名字。

第二样：最近的几个包。——也就是"现在线上跑的是哪个"——而这个答案，必须能被指出来。——因为接手的人第一件要确认的事是"我改的这个，和门店在用的是不是同一个起点"——如果不是，他改完发下去，就会把中间那几次改动全部回退。——而这类事故，是"换人"之后最常见的一种。

第三样：一份"为什么"。——也就是那张改动台帐——哪一次改了什么、为什么改、谁提的。——而它是三样里最容易被忽略的，也是三样里最值钱的——因为前两样都能重新搭，只有"为什么"补不回来。

而这三样之外，其实还有一样"半件"东西：一个能问的人。——因为有些事写不下来——比如"那个按钮为什么在那儿""那个空行为什么不能删"——而这些事，只有经历过的人能答。——所以"换人"这个动作，最好安排一次半小时的交接电话——而那半小时里最该问的，不是"怎么改"，是"哪些不能动"。

而"哪些不能动"这个问题，答案往往很具体，也很琐碎。——"那个空行不能删，因为删了之后列表会跳"、"那个入口不能藏，因为老板每天要看"、"那个默认值不能改，因为改了之后老数据会算错"。——而这些话，如果没人问、没人记，就会在交接之后彻底消失——然后在某次"顺手清理"里引发一场事故。

所以更稳的做法是：把"不能动的东西"单独列一张单。——五行十条，都行——而它的作用是"给后来的人划线"。——而这张单最好放在项目目录旁边，和改动台帐放在一起——因为这两样，一个说"改过什么"，一个说"别动什么"，正好互补。

把这一节收成一句：交接的时候，交的不是"技术"，是"上下文"。——而上下文就是三样加半件：环境、最近的包、为什么，以及一个能问的人。——而这四样凑齐，接手的人第一天就能改出第一个包——而这，比任何文档都实在。

六、有四种改动，看着很小，却最伤长期

前面讲的是"该做什么"，这一节讲"最容易做错的四件事"。——而它们的共同点是：做的时候觉得"就一下"，而代价在两年后才显现。

第一种：随手改包名。——包名看起来只是"一个标识"，而它决定了"这个应用是谁"。——改了包名，它在系统里就是一个全新的应用——旧的数据不会跟过来，旧的包也不会被覆盖。——而"改包名"最常见的理由，是"想同时装两个版本"——而这个需求，往往可以用"两个项目、同一个包名、不同外观"来满足。

第二种：换签名。——这是最伤的一种，因为它的后果是"所有机器都要卸载重装"。——而"卸载"会清掉本地数据——而长期使用的小应用，本地数据往往就是"全部家当"。——所以签名这件事，一旦定了，就该当成"不能碰的东西"——写进那张"别动"的单子里。

第三种：抬最低支持版本。——这个动作在开发那边叫"升级配置"，在现场叫"那台机器用不了了"。——而它最阴的地方是：你这边完全感觉不到——你的测试机都是新的，装得很好。——所以长期维护的应用，每次打包之前都该问一句："这次改动，有没有动到最低版本？"

第四种：删"看不懂的东西"。——这是四种里最隐蔽的一种——因为它看起来像"整理"，而实际上可能是"拆掉承重墙"。——那个多余的空行、那个没人点的入口、那段奇怪的判断——它们之所以在那儿，往往是因为"某一次必须这么改"。——而删掉它们，短期看不出问题，等某一天某个场景触发，才会以"莫名其妙"的方式出现。

这四种改动有一个共同的预防办法：把它们写进"需要两个人同意"的清单里。——也就是说，改包名、换签名、抬最低版本、删看不懂的东西——这四件事，动手之前找个人说一声。——而"说一声"这个动作，能让一半的冲动消失——因为你要解释给别人听，而解释的过程就是自我检查。

顺便说清"删看不懂的东西"的正确做法：不是"永远不删"，是"先记再删"。——记一行："这里有一段没用的判断，怀疑是当年为了某某场景加的，先删了，如果出问题回滚到上一版。"——而这一行的作用，不是"留证据"，是"给未来的自己一个提示"——因为出问题时，这句话能让你立刻想到"是不是那次删的"。

最后说一句关于"保守"的话：长期维护这件事，保守不是缺点，是职业素养。——因为你的用户不是"愿意尝鲜的人"，是"每天靠它干活的人"——而对他们来说，"没变化"往往就是最好的消息。——所以"能不动就不动、要动就留记录"，这条原则在一两年的项目里显得啰嗦，在五年的项目里就是救命的。

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

问一：每次都新建项目，还是复用上一次的？——建议"复用目录、单独立项"——把上一次的项目目录拷一份、改目录名、刷新列表。——这样工程和配置都继承下来，而上一次那一版还在它自己的项目里，随时能回去看。——而"独立成项"这件事，在长期场景里的价值，是"每一次改动都能被单独拿出来"。

问二：项目会不会越积越多？怎么清？——会，而且必然。——而清理的规则可以很简单：只留"线上正在跑的"和"上一次的"两个，其余归档或删除。——因为"三个月前那一版"几乎不会被要，而"上一版"是唯一可能需要回滚的。——而删之前，确认包已经归档——包是结果，项目是过程。

问三：history.ini 里的话会不会越积越长？——会，而它本来就该长——因为它记的是"这个项目被说过什么"。——而它的用处不在"从头读一遍"，在"搜一个关键词"——比如你想知道"积分"那行字是什么时候改的，搜一下就定位到了。——所以它不需要整理，它需要"别删"。

问四：老机器到底要照顾到什么时候？——照顾到"它不用了"为止——而这个"不用了"，应该是你确认过的，不是猜的。——所以每隔一段时间，做一件很土的事：数一数还有几台老机器在跑、是哪几家店在用。——而这个数字，会告诉你"能不能抬最低版本"——而这个答案，比任何技术判断都准。

问五：如果当初没留台帐，现在补还来得及吗？——来得及，而从"现在"开始就行。——因为台帐的价值在"往后"，不在"往回"——你补不出三年前的原因，但你可以从今天开始记。——而一个更省事的做法是：第一次补的时候只写三行——"现在是什么样、谁在用、哪些不能动"——这三行本身就已经很有用了。

这五个问题里，问五最常被问，也最容易让人放弃。——因为"补不回来"这件事，会让人觉得"那就算了"。——而实际上，你不需要补回来——你只需要让"从今天开始"有记录。——而这件事的成本，是每次改完之后多写一行。

顺便说一个"记录"的实用技巧：把"改了什么"写成"能反驳的句子"。——比如不要写"优化了首页"，写"首页把积分那行提到第一屏，因为店员说老太太看不清"。——前者无法验证，后者可以——而"可以验证"这件事，是记录有没有用的分水岭。

而这五个问题的共同底色，是同一个判断：长期维护的应用，最贵的东西是"上下文"。——功能可以重做，界面可以重画，只有"当初为什么这么定"补不回来。——所以每一次改动，都顺手留下那半句"因为"——这半句话，是这套东西能活过第五年的原因。

八、每年做一次"体检"，比出事之后救火划算

长期维护的应用，最典型的状态是"一直有事、但一直没坏"。——而"没坏"这件事会让人放松——直到某一天，某一台机器装不上、某一个字段算错、某一个入口点了没反应。——而这些问题，其实都能提前发现——只要每年做一次体检。

第一件：安装。——找一台"最老的机器"和一台"最新的机器"，各装一次。——看能不能装、装完能不能打开、桌面名字显示成什么样。——而这一步最容易被跳过，因为"平时都在用，肯定没问题"——而"平时在用"的那台，往往既不是最老的也不是最新的。

第二件：升级。——在一台"已经装了旧版"的机器上装新版，看能不能直接覆盖、数据还在不在。——而这一步的价值，是提前验证"那三个条件"——包名、签名、版本号。——因为这三个条件只要有一个变了，升级就会变成"卸载重装"，而数据就没了。

第三件：字体。——把系统字体调到最大，再打开一遍。——看标题会不会变成两行、按钮会不会被挤出去、列表会不会错位。——而这件事的成本是"改两下设置"，收益是"发现所有被字体顶坏的地方"。

第四件：密钥。——确认那份签名密钥还在、还能用、还有备份。——因为它是唯一"丢了就补不回来"的东西——密钥一丢，你就再也打不出"能覆盖旧版"的包。——而这件事最容易被忽略，因为"平时用不到"——直到某一天你要发新版。

第五件：台帐。——把这一年改过的事，补成一张表。——如果平时没记，那就靠回忆加项目名——因为项目名里带了日期，翻一遍就能想起大半。——而这张表补完之后，你会有一种很实在的感觉："原来这一年改了这些。"

第六件：清理。——把项目目录从十几个清到三五个，把安装包从一堆清到"当前版 + 上一版"。——而清理的动力，来自一个很朴素的判断：你明年还会再看这些东西吗。——不会的，就该走——因为"留着"的成本不是空间，是每次翻列表时的那几十秒。

六件事，两个小时，一年一次。——而它最实际的价值，不是"发现问题"，是"让你重新认识这个东西一次"——因为平时你只在需要的时候打开它，而体检的时候，你会完整地看它一遍。——而"完整看一遍"这件事，往往比任何检查项都能发现问题。

九、把五年的事写成三页纸，交接的时候才不用靠嘴

很多长期维护的应用，真正的知识不在文档里，在人脑子里。——而人脑子里的东西有两个特点：一是不问就不说，二是一走就带走。——所以"交接"这件事，从来不是"写一份完整的技术文档"，而是"写三页别人看得懂、用得上的东西"。

第一页：这个东西是干什么的，谁在用。——不要写功能列表，要写"谁在什么情况下打开它"。——比如"门店店员在收银台旁边，会员报手机号的时候打开它，查积分和余额，一分钟内要答出来"——这一句话，比十行功能描述都有用。——因为接手的人只要知道"一分钟内要答出来"，他就明白为什么首页只有一个输入框、为什么查询结果只显示三行。

第二页：怎么改，改了怎么发。——这一页写的是操作路径，不是原理。——环境在哪、项目在哪、包在哪、密钥在哪、发布走哪一步、装到哪几台机器上——六句话，加四张截图，足够了。——而这一页最该写的，是"上次是怎么做的"——因为照着上次的做法做一遍，是新人最稳的起点。

第三页：什么不能动，动了会出什么事。——这一页最容易被省略，却最救命。——包名不能动，动了就装不上旧版；签名不能换，换了就得全部门卸载重装；那个看起来没用的白色图片不能删，删了启动页会闪一下黑；那个藏在二级页里的入口不能挪，因为店长的习惯路径就是那样。

"不能动清单"这个词听起来很消极，其实它是长期维护里最有价值的一份资产。——因为它记录的不是"技术限制"，是"二十次改动踩出来的坑"。——而每一个坑背后，都曾经有过一次真实的故障、一次投诉、一次加班。

写这三页纸的时候，有一个小技巧很管用：不要从"我知道什么"开始写，从"他需要知道什么"开始写。——前者会写成一本手册，后者会写成一张便条。——而便条的阅读率，永远高于手册。

三页纸写完，还有一个动作要做：让一个没参与过的人，照着它改一次。——哪怕只是改一个名字、换一张图。——他卡在哪一步，那一页就少写了一句话。——而这一次"照着做"的验证，比你自己读十遍更能发现问题——因为你自己读的时候，脑子里会自动补齐那些没写出来的步骤。

在「安卓修改大师智改工坊」里，这三页纸里的第一页和第三页，其实有一部分是"自动留下"的。——每个项目一个目录，目录里有 config.ini 记着这个包从哪来、图标是哪张、签名用哪份；有 history.ini 记着你当时说过的话；有 apktool.log 记着反编译那一步发生了什么。——你唯一需要手写的，是"为什么改"和"什么不能动"——而这两样，恰好是工具替不了的部分。

十、收到一个改动请求，先在心里问三个问题

长期维护的应用，改动请求来的方式都差不多：一句微信消息，一张别家的截图，一句"能不能也做成这样"。——而这样的请求里，大概有一半不该改，有四分之一不该这么改，只有四分之一是真的需要改。——分辨的办法不是靠经验，是靠三个固定的问题。

第一个问题：这是"看得见的东西"，还是"背后的规则"。——改包能改的，是看得见的东西——字号、颜色、顺序、显隐、文字、图片。——改不了的，是背后的逻辑——一列变两列、列表能不能拖、按什么排序、什么时候弹窗。——所以当有人说"我想把首页做成两列"，正确的回应不是"做不了"，而是"两列这个排法改不了，但我可以把上面那块挪下去、把下面那块提上来，效果接近一点"。

把"做不了"换成"能做的部分是这些"，是这个工作里最需要练的一句话。——因为它既守住了边界，又没有把门关上。——而说这句话的前提，是你真的知道自己能改什么——这也是为什么前面那张"能做与做不到"的对照表，值得贴在显示器旁边。

第二个问题：这个改动，是给所有人，还是给某几个人。——这是长期维护里最容易被忽略的一刀。——因为"某几个人的习惯"和"所有人的需要"，往往会走向完全相反的方向。——比如有个店员说"查询按钮太小了，点不准"——如果只有他一个人说，可能是他的手机贴了厚膜；如果三个人都说，那就是真的小。而如果为了他一个人把按钮放大一倍，另一批人会觉得"页面变丑了、能看的内容变少了"。

所以第二个问题的实际问法，是"还有谁提过"。——一个人提，先记下来；两个人提，考虑改；三个人提，就该改了。——而"记下来"这个动作，就落在前面说的那张改动台帐上——它真正的用处，不是留档，是"帮你数有几个人提过同一件事"。

第三个问题：改完之后，会不会让"原来会用的人"不会用了。——长期应用有一个隐形成本，叫"肌肉记忆"。——用了三年的人，闭着眼都知道"查完积分往左上角点一下回到列表"。——你把那个返回放到右上角，他不会找不到，但他会每次多点错一次，一天点错二十次，一个月之后他会说"这个应用越改越难用"。

而这条规则有一个例外：如果原来的位置本身就是错的，那就该改，但要"一次改到位 + 提前说一声"。——比如那个返回按钮原来藏在二级页里，所有人都找不到，那把它提到一级页是对的——这时候要做的不是"别改"，而是"改完在群里说一句：返回挪到右上角了"。——一句话的成本，能省掉两周的"怎么又变了"。

三个问题问完，大部分请求会自动分成四类：该改的、该换做法的、该记下来等的、该拒绝的。——而"该拒绝的"这一类，往往是最难开口的——因为它通常来自一个很客气的人，提了一个很不合理的要求。——这时候最有效的说法，是把后果说清楚，而不是把理由说清楚：不是"这个不能做"，而是"这么做的话，下次升级所有人都得卸载重装，数据会清掉"——大多数人听到这句，会自己收回这个要求。

十一、一张 A4 的清单：长期维护到底要守哪些东西

前面说了很多原则，落到纸上，其实是一张 A4 就够的表。——这张表不是给新人看的流程，是给自己看的"每次改之前扫一眼"的东西。——因为长期维护出的错，几乎都不是"不会做"，而是"忘了某一件事"。

表的左边写"不能变的东西"，右边写"变了怎么补"。——这样排的原因是：不能变的东西一旦变了，不是"要重做"，而是"要善后"——而善后的代价，往往比改本身大十倍。

不能变的	为什么	真的变了怎么办
包名	它就是"同一个应用"的唯一身份，一改系统就当成新应用	当成"发新版应用"来安排：提前通知、约定同一天换、旧版再留一个月
签名密钥	换签名就等于换身份，覆盖安装一定失败	只能全部卸载重装；所以密钥至少留两份备份，一份离机
versionCode 只往上	比已装的低，系统直接拒绝安装	不往回改；宁可跳号，也不要重号
桌面显示名	太长会被截断，用户看到的是"会员查询…"	控制在六到八个字以内；后缀用两三个字，不要用括号加长句
图标的安全区	不同系统裁的形状不一样，贴边的图案会被切掉	主体留在中间那块，四周留白；换图标时先在三台不同机器上看
最低支持版本	一抬高，老机器就装不上了，而老机器往往在现场	先数一遍现场还有几台老机器，再决定抬不抬

表的下面还有三行"每次都要做"的动作，比上面那六行更容易漏。——第一行：改之前，把当前的安装包复制一份出来，名字带上日期。——这一份是"退路"——改坏了，装回去就行，不用重做。

第二行：改完，在一台"装着旧版"的机器上覆盖安装一次。——不是装到一台干净的机器上——干净的机器永远装得上，它证明不了任何事。——而这一步只花两分钟，却能提前发现"包名是不是被动了、签名是不是换了、版本号是不是没往上走"这三件事。

第三行：发出去之后，在台帐上补一行。——四列就够：日期、改了什么、为什么改、谁提的。——这一行写下去只要三十秒，而它会在两年后的某个下午救你一次——当有人问"这个按钮为什么在这儿"的时候，你能翻出那一天。

这张表最值得注意的地方，是它上面没有"功能"两个字。——因为长期维护里，功能几乎不会出问题——出问题的永远是这些"外围"的东西：名字、签名、版本号、图标边距、老机器。——而它们有一个共同点：改的时候看起来都不重要，坏的时候都很难救。

在「安卓修改大师智改工坊」里，这张表的一半是被工具替你守住的。——签名可以在项目配置里固定下来，不用每次重新选；版本号在打包的时候会提示你往上加；图标上传的时候会提醒你别贴边；包名那一条没人替你守，但反编译的时候它就在配置里，扫一眼就能看见。——工具守住"机械的部分"，你守住"判断的部分"——这大概是长期维护里最省力的一种分工。

十二、用过的人怎么说

五条反馈，讲的是五件很不"高级"的事：翻得到上次怎么改的、密钥别丢、交接要留一句为什么、改前复制一份、拿最老的机器试装。——而长期维护的全部难点，几乎都在这五件里。

那句"如果当初有一句'为什么换'，我能省一整天"，大概是这篇文章最想让人记住的一句。——因为"为什么"这三个字，是所有工具都替不了、只有人能留下的东西。——而它写下来只要三十秒，找回来却可能要一整天——这就是长期维护里性价比最高的一笔投资。

---

只需说话，就能让应用变成你想要的样子。——而在一个用了五年的应用上，"想要的样子"往往不是新功能，是"别乱、别丢、别装不上"——这三件事靠的不是技术，是习惯：改前复制一份、改后覆盖装一次、改完补一行台帐。——剩下的交给安卓修改大师智改工坊，它把"建项目、反编译、打包、签名"这四步压缩成一句话，让你有精力去守那些真正重要的东西。