改"默认配置"看不到效果：SharedPreferences 的默认值与旧数据

有一类改动特别容易让人怀疑人生：把默认配置改了、包也重新打上了、装机也成功了，打开一看 —— 还是老样子。界面没变、默认开关还是旧值、首次进来的引导又弹了一遍。这时候大部分人会回头怀疑"是不是没改上"，于是再改一遍、再打一遍、再装一遍，还是老样子。真正的原因通常只有一句话：你改的是"代码里的默认值"，而这个键早在很久以前就被写过一次了；读取的时候，已经存下来的值永远优先，默认值只有在"没存过"的时候才轮得到。安卓修改大师智改工坊是一款 Windows 桌面工具：把安装包拖进去，用中文写一句需求，AI 改 smali 与资源，改完自动回编、对齐、签名、校验，再一键装到手机或模拟器上看效果。它的介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

这篇要解决的是同一件事的三个面：默认值到底写在哪一层（代码里、资源里、还是首次运行时写入）、为什么改了默认值旧数据还在（这背后是平台一条非常朴素、也非常硬的规则）、以及想让它生效时该走哪条路（清数据、换键名、写迁移，三条路各自适合什么场景）。最后一章会落回工具本身的边界：它只改包，不动设备上的数据 —— 这不是能力不足，而是一条刻意的设计边界，理解了它，很多"为什么改了没效果"的疑问会自动消失。

一、默认值的三层来源：先搞清楚你要改的是哪一层

"默认值"这个词在安卓应用里不是一个东西，而是一家族东西。它们长得像、名字像，作用范围却完全不同。改错层的代价，就是你改完看不到任何效果。下面这三层，从最常见的说起。

怎么判断你要改的默认值在哪一层

这一步做对了，后面能省掉一整轮返工。判断的依据不用猜，看两件事就够了：这个键名第一次出现在哪里，以及它旁边有没有"写入"的动作。在项目的反编译输出里搜键名 —— 只出现在读取语句里、旁边跟着一个字面值的，是第一层；出现在资源清单里的，是第二层；出现在一段"批量初始化 / 首次运行检查"里、并且紧跟写入动作的，是第三层。三层的改法完全不同：第一层改代码、第二层改资源、第三层等于改数据（要么迁移，要么清数据）。

还有一种更土但更可靠的判断法：在当前设备上清一次数据，重启应用，看这个值会不会变。会变，说明读的是前两层（默认值还有话语权）；清完还是老值，说明它要么被写死在资源里、要么由首次运行的初始化写成了数据、要么你清的不是同一份存储（多进程应用里这种情况并不罕见）。多做这一次对照，比读十遍代码都快。

另外提醒一句：同一个功能常常同时存在两层默认值 —— 界面用资源里的那一份，业务逻辑用代码里的那一份。只改一层，会出现"界面显示新值、实际行为还是旧值"的割裂现象。所以搜键名的时候，建议把两个方向的引用都翻一遍，再动手。

还有一层和"读取"有关、值得单独拎出来说的机制：本地存储是每个应用私有目录下的一批文件 —— 共享偏好（也就是常说的 SharedPreferences）是一组小的配置文本，数据库则是若干个库文件。写入有"异步落盘"和"同步落盘"两种方式，做改包的人不需要记住文件路径，但要知道它们的存在形式是文件 —— 文件就会被保留、被覆盖、被删除，而"保留还是删除"取决于安装动作，不取决于包里的内容。这条认识是下一章的全部基础。

二、为什么改了默认值，旧数据还在

把上面三层连起来看，答案其实只有一句话：读取的顺序是"先看有没有存过，再谈默认值"。默认值不是"当前生效的值"，而是"当这个键还不存在时，临时顶上的那个值"。当这个值存在共享偏好（SharedPreferences）里时，这条规则尤其硬：键一旦被写过一次，默认值就再也不会被读到；数据库里的记录同理 —— 初始化时插进去的那条记录，和用户后来自己建的那条，长得一模一样。换句话说，你要改的是"当前生效的值"，而它躺在设备上的数据里，跟包一点关系都没有。

接下来是这个现象里最容易被忽略、也最需要记住的半句：安装新包这个动作，默认不会清掉旧数据。用常规覆盖安装把新包装上去，系统只替换代码与资源，应用私有目录里的配置与数据库原封不动地留着。这是设计使然 —— 用户升级应用，当然不希望聊天记录、登录状态、草稿被清空。于是你就看到了那个经典的画面：包是新的、逻辑是新的、默认值是新的，唯独那个"已经存过的值"还是旧的，而它恰好优先级最高。

什么时候数据会消失？卸载的时候。卸载会把应用私有目录一并清掉，在下一次安装时从零开始 —— 这也是为什么"删掉重装就好"这个土办法一直管用。理解了这两句话，就能反过来解释两个常见现象：第一，"同事装了就生效，我装了不生效"，多半因为他装之前卸过一次；第二，"模拟器上对、真机上不对"，多半因为模拟器是新开的干净环境。

还有两个稍小但同样常见的因素，顺手记一下。其一是多进程：同一个配置文件如果被两个进程读写过，另一个进程可能还看到旧值，直到它自己被重启 —— 这个坑在讲多进程的那一篇里展开过，结论是"读写的责任要指定唯一"。其二是缓存：有些应用把配置读进内存后就不再回头读文件了，改包后不重启应用，看到的仍是内存里那份旧值；换个页面、退到后台再进来，往往只是让它重新走一遍读取流程，并不代表数据发生了变化。

三、想让它生效：清数据、换键名、写迁移，三条路怎么选

既然问题是"旧数据优先级更高"，那么让新默认值生效的思路就三种：把旧数据清掉、让它读不到旧数据、主动把旧数据改成新值。三种思路对应三条路，代价从轻到重，适用场景也完全不同。

做法	本质	适合	代价
清数据	把本地数据整块清空，回到"从没跑过"	测试机、内部设备、演示环境	登录态、草稿、历史记录一起没
换键名	换一个"从没被写过"的键，旧值自然读不到	想快速验证新默认值、且旧值可丢	旧值被丢弃，用户改过的设置也丢
写迁移	启动时判断旧键在不在，把值搬过去再删旧键	正式发布的自家应用、内部长期在用的工具	要多写一段逻辑，得测"有旧值/无旧值"两条路径

三条路里，清数据最快、最不用动代码，但它是有破坏性的。在自家测试机上，它就是最合理的选择：设备的应用管理里找到自家应用，清除数据之后重新打开，默认值立刻生效，前后不到一分钟。放到真实用户手上就要谨慎了 —— 清数据等于让用户重新登录、重新配置，代价不该由"我想换个默认值"来付。

换键名是"最省事的一次性方案"：把读取用的键名改成一个新的（比如加一个版本后缀），旧值因为名字对不上而读不到，新默认值立刻顶上。它适合"这个配置本来就该重置、旧值没有保留价值"的场景，比如内部工具的服务器地址、上报间隔、调试开关。要注意的是，它丢的不只是旧默认值，也包含用户自己手动改过的值 —— 所以更适合自家内部应用，而不是有真实用户的产品。

写迁移才是"面向长期使用"的做法，思路也非常直白：应用启动时先看旧键在不在；在的话，把它的值读出来、按新规则写进新键、再把旧键删掉；不在的话什么都不做，让新默认值自然生效。这段逻辑只需要写一次，之后每个从旧版本升上来的设备都会自动完成搬家。它比前两条路都麻烦一点，但它是唯一"既改了默认行为，又不伤害用户数据"的路子。数据库那边同理：所谓"迁移"，就是把上面这段动作换成"读到旧的初始记录 → 按新规则更新它"，而不是傻等数据库重新创建。

顺便说一句怎么描述"只改我要改的那个键"。在需求里明确写上"其它设置保持不变"非常重要：一份配置文件里往往躺着好几项（显示类、网络类、开关类），如果不加这句约束，"重置默认值"很容易被理解成"把整份配置重置" —— 那就不只是改默认值，而是把用户调过的东西一起抹了。这句约束加上之后，效果等价于给改动划了一个"只动这一格"的框。

四、把需求写到"数据层"上去：四个可以直接抄的句式

理解了机制之后，"怎么写需求"就变成了一道有标准答案的题。默认值类需求最常见的失败写法是只写一层："把默认间隔改成十分钟" —— 这句话在 AI 那边会被理解成"改代码里的默认值"，改完确实没错，但你装到有旧数据的设备上还是十分钟都看不到。把"改哪一层、旧数据怎么办"一起写进去，才是一条完整的需求。下面四个句式可以直接抄：

• 只对新安装生效："把默认间隔改成十分钟，只对全新安装生效，已有数据不要动。"
• 新旧都要生效（换键名）："把默认间隔改成十分钟；为保证旧设备也生效，改用新的键名，旧值不再使用。"
• 新旧都要生效（写迁移）："把默认间隔改成十分钟；如果本地已经存过旧值，写一段迁移逻辑把它改成十分钟，迁移完成后删除旧值。"
• 数据库初始数据："把内置的默认分类补齐到新的五项；已经建过库的设备，通过升级流程把缺的补上，不要重建数据库。"

这四句里，真正值钱的是每一句的后半段。前半段是"我希望变成什么样"，后半段是"在已经跑过一段时间的设备上，怎么变成那样"。默认值类需求之所以反复返工，十次里有八次是缺了后半段。

需求写长一点之后，就得让工具帮你管住"上下文"。这里有三个现成的抓手：第一，附件。把默认值的清单整理成一个文本文件（一行一项：键名、旧值、新值、是否迁移），用途说明写清"这是本次要修改的默认值清单，请逐条对照处理" —— 说明不能少于 10 个字，这条门槛拦住的就是"甩个文件让 AI 猜"。同一份文件重复选择不会重复添加，同一个路径自动去重，免得一处分出现两条说明；点确定之前还会逐项确认文件能不能用（存在、不是目录、不是空文件、能读出来），四项都过才放行。第二，话术库。里面有专门的"常规修改"类指令，每条都把"要做什么 / 细节要求 / 参数参考 / 范围 / 验收"写全，把它的结构借过来填自己的事实，比从零组织语言稳。第三，修改历史。每次点「立刻修改」，你写的那段原话会连时间一起记进项目历史，完整显示不截断；下次遇到同一件事，在历史里点一下「选择」，原话就回到输入框 —— 附件说明与机器拼出来的那部分不会进历史，历史里永远只有你自己写的话。

五个高频问题，逐条给答案

问：清完数据，默认值怎么还是旧的？ 答：三种可能。一是这个默认值其实写死在资源里，或者由首次运行的初始化写成了数据（回看第一章的三层）；二是你清的不是同一份存储 —— 多进程应用里，另一个进程可能持有自己的一份配置；三是清完之后应用没被真正重启（缓存还在），下一次冷启动再看才是准的。

问：覆盖安装到底会不会清数据？ 答：不会。覆盖安装保留应用私有目录里的配置与数据库（SharedPreferences 文件、库文件都原地不动），这也是为什么"改了默认值但旧数据还在"。只有卸载会清掉数据 —— 所以签名不一致时必须卸载时，程序会特意提醒你一句。

问：我就是只想改默认值，不想动老数据，可以吗？ 答：可以，而且这是最安全的一种改法，唯一的代价是"老设备看不到变化"。写需求时把"只对全新安装生效、已有数据不要动"写清楚，验收时在干净设备上确认即可 —— 别在有旧数据的设备上反复测，那永远测不出结论。

问：数据库里的初始数据改了为什么没变？ 答：因为它只在数据库第一次被创建时插入过一次。想让它对老设备生效，得把这次改动放进升级流程里；顺手抬一下库的版本号，让升级流程有机会跑起来。

问：老用户自己改过的值，要不要跟着我一起改？ 答：这取决于你的业务判断，但无论选哪边，都要在需求里写出来：要改，就写"所有已经存在的值统一改成 X"；不改，就写"只改还没设置过的，用户设置过的一律不动"。含糊留白的结果通常是 AI 按自己的理解选了一种，而那不是你要的。

五、"改包不改数据"：这是边界，也是保护

讲到这里，工具的一条设计边界就可以正面交代了：它改的是包，不碰设备上的数据。你拖进去的是一个安装包，工具做的事是反编译、改代码与资源、回编、对齐、签名、校验、装机；设备上那个应用私有目录里的配置文件与数据库，从始至终不在它的操作范围里。想改数据，只有两个动作能碰到它们：一是应用自己的逻辑（比如你要求写进去的迁移代码），二是"卸载"这个系统行为。

为什么要把这条边界划得这么清楚？因为这两件事的可逆性完全不同。包是可回滚的 —— 每个项目目录在创建时都会留一份导入的原始包副本，配置、图标、源包先落地，反编译是之后另做的一步，就算反编译失败也不影响项目本身（会告诉你原因，并把完整输出写进日志）。改乱了、想对照原样，拿这份原始包随时重开一个项目就行。数据是不可回滚的 —— 用户的登录态、草稿、记录，清掉就没了。把"可回滚的"和"不可回滚的"分开处理，是一条很朴素的工程纪律。

这条边界还有两个可以直接观察到的证据。第一个是签名冲突时的处理：设备上已经装了签名不一样的应用时，新包装不上去，工具会明确提示"要装就得先卸载，而卸载会清掉那个应用的数据"，然后等你确认 —— 它不会替你做这个决定。第二个是打包标记：程序在出包前会往工程里的资源文件写一个固定名字的样式，内容是一串编码过的标记（时间、账号、机器信息、程序版本、应用名与包名）。这个标记写在包里、跟着包走，回编时被一起编进去 —— 它是"包内数据"的典型例子，和"设备上的数据"完全是两码事。同一个项目目录里还留着打包日志与三个中间产物（未签名、已对齐、已签名），任何一环出问题都能对着日志回看。

顺带说一句删除的安全设计：项目列表里删项目时，程序只允许删项目根目录的直接子目录。这个判断看着多余，其实是防呆 —— 项目信息是从配置文件读出来的，万一那行路径被人改坏了，也不会顺着它把项目目录外面（甚至整个盘）删掉。改数据这件事同理：能少碰就少碰，非要碰，就先把"怎么退回去"想清楚。

六、两个自家应用实例：默认值这件事，改法不一样

下面两个例子都来自我们自己：一个是自家产品，一个是内部工具。它们的默认值改动需求几乎一样，但"旧数据怎么办"的答案完全不同 —— 这正是这一篇想说明的核心。

实例一：自家「记账助手」安卓版 —— 把默认币种改成人民币，且老用户也要跟着变。

这是自家的小工具，早期只面向内部试用，默认币种写在一个"建账时用的默认值"里。试用期结束后我们要把它改过来，而且要求很明确：已经装过旧版本的同事，下次打开也要变成新的默认值。以前的做法是：反编译之后翻代码，找到默认值那一行改掉；装机一看，老账号纹丝不动 —— 因为那份配置早就写进本地了。于是再改一轮，这次把读取用的键名也换掉；结果是新值生效了，但同事之前自己调过的显示精度也一起没了。两轮返工，踩的正是本文第一章的第三层与第三章的换键名代价。

现在一句话："把默认币种改成人民币；如果本地已经存过旧的默认值，写一段迁移逻辑改成人民币，迁移完成后删除旧值；已经手工调整过的其它设置不要动。"改完 AI 在项目目录留下标志文件，主窗口读到就自动弹打包窗口，四步跑完（回编、对齐、签名、校验），最后一步会打印签名证书信息，拿这一行确认"确实签上了"。装机的部分交给"打包后自动运行"。

改完怎么验证？分两台设备两条路：一台干净设备（或先清过一次数据的设备）用来验证"新默认值本身对不对"；一台带着旧数据的设备用覆盖安装验证"迁移有没有发生"。两条都过，才算真的改完。这个"两台设备两条路"的做法看起来很笨，但它把"默认值问题"和"迁移问题"彻底分开了 —— 只测一台，你永远不知道是哪一个环节没生效。

实例二：内部「巡检打卡」工具 —— 上报地址从测试环境切到正式环境。

这个工具是给巡检同事用的内部应用，默认上报地址写在配置里。测试阶段的包已经在同事手机上跑了一阵子，那个测试地址早就被写进本地了。要切正式环境，最省事的做法是清数据 —— 但同事手机上还有没传完的巡检记录，清数据等于把它们一起丢掉。所以这条需求只能走迁移，而且要考虑"上报记录不能丢"。

以前这类改动的流程是：改代码 → 回编 → 签名 → 装机 → 挨个让同事清一次数据（或者自己写一小段迁移代码再打一次包）→ 等反馈。因为涉及数据，出错的代价比改界面高得多，所以每次都要先在自己机器上试一遍、再找一位同事试一遍。

现在同样是一句话："把上报地址的默认值改成正式环境地址；已经装过旧版本的设备，通过迁移把地址改成正式环境，本地未上传的记录必须保留。"验证用得也是上面那套链路：先用工具的装机链路确认新包装上、应用按启动页被拉起、并且复核前台确实是它；然后在有旧数据的设备上看地址是否已经切过去、未上传的记录是否还在；最后再用一台干净设备确认全新安装的默认值也是正式环境。同一个功能点，"新装的"和"升上来的"要分别成立 —— 这一条判断标准，比任何技巧都值钱。

两个例子的对比最能说明问题：第一个改默认值，选择了"迁移 + 不动其它设置"；第二个改默认值，选择了"迁移 + 保住本地记录"。它们要改的那一层的写法几乎一样，真正决定成败的是对旧数据的处理策略。而这个策略，只有你（而不是工具、也不是 AI）能定，因为只有你知道那些数据值不值钱。工具能做的，是把"改包"这条链路做成出厂设置：改完自动回编、对齐、签名、校验，产物与日志都留在项目目录里，随时可对照、可回滚。

七、用户评价：他们和"旧数据"的几次交手

八、结语：默认值在包里，生效的值在设备上

把这篇收成三句话。第一，默认值有三个来源：代码里的字面默认、资源里的默认、以及首次运行写进去的初始值 —— 前两层只在"没存过"时生效，第三层本身就是数据。第二，"改了看不到"是因为旧数据优先级更高，而覆盖安装会保留数据、卸载才会清数据。第三，让默认值生效有三条路：清数据最快但有破坏性，换键名最省事但会丢旧值，写迁移最麻烦但最体面 —— 怎么选，取决于那台设备上的数据值不值钱。

于是你打开安卓修改大师智改工坊时看到的，就是那句口号描述的样子：只需说话，就能让应用变成你想要的样子 —— 你要把"改哪一层、旧数据怎么办、怎么算改好"用中文说清楚，把默认值清单、运行记录、目标截图作为附件带上（每个文件配一句不少于 10 个字的用途说明）；改完的回编、对齐、签名、校验、装机、复核，交给同一条流水线。包归包、数据归数据，这条边界守住了，改包这件事就始终是可回滚、可复现的。

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