手动精修的技术底座：经典版 smali、资源与工程导出

先把这个版本的定位说清楚。同一个团队同时提供 AI 路线和手动路线，并不是左右互搏，而是承认改包这件事有两种典型处境：一种是你只想尽快看到效果，另一种是你必须解释清楚效果是怎么来的。前者适合交给安卓修改大师智改工坊的 AI 能力，后者适合打开安卓修改大师经典版，把工程树展开，一层一层往下看。

AI 版的主张是“只需说话，就能让应用变成你想要的样子”，它把反编译、修改、回编、对齐、签名串成一条自动流水线。经典版不反对这条流水线，它只是把流水线上的每个工位保留成可以暂停、可以检查、可以重做的样子。对喜欢自己掌控每一步的人来说，这种“慢”不是缺点，而是安全边际：你知道输入是什么，知道中间产物在哪，知道失败时该回退到哪一层。

一、手动精修的价值：不是拒绝自动化，而是保留解释权

很多人对手动工具的想象还停留在“界面老旧、步骤繁琐”。这只说对了一半。步骤确实多，但每一步都有明确的目的：反编译是为了得到可读的工程，修改是为了让工程表达你的意图，回编是为了把工程还原成安装包，签名是为了让系统认这个包。步骤多带来的不是麻烦，而是可插入检查点的机会。你可以在任何一步停下来，做一次 diff、看一次日志、跑一次安装，确认无误再往下走。

可复现是手动路线最被低估的收益。所谓可复现，不是“再做一次大概也能成”，而是同一份输入、同一套工具链、同一组改动，能够得到同一份结果，并且这份结果可以被别人复核。要做到这一点，需要三个条件同时成立：输入不被污染，工具链版本固定，改动有文字记录。经典版把工程目录、反编译产物和日志都留在本地，正好为这三个条件提供了落脚点。

把 AI 路线和手动路线放在一张表里，差别会更直观。注意，这不是功能优劣表，而是适用场景表。

这张表也解释了一个常见误解：手动工具并不“更专业”，它只是把责任和权限一起交给你。你获得了改任何一行的能力，也承担了改错一行的后果。所以真正的手动精修，不是上来就改，而是先建立一套自己的工作纪律：原包只读、工程可重建、改动有清单、每次只验证一个变量。后面的章节，都会围绕这套纪律展开。

“可控”不是一句口号，它意味着你知道改动的位置、原因和回退路径。三者缺一，手动就只是更慢的碰运气。

经典版与电脑版可以同机安装，项目互不冲突。这一点对团队很有用：同一个人可以用 AI 版快速出效果图，再用经典版把关键改动落到工程里；也可以反过来，先用经典版定位问题，再把明确的需求交给 AI 版批量执行。工具是两条腿，走路的人还是你。

二、手动反编译的输入与输出：一次拆包到底得到了什么

手动路线的起点只有一个：一个 APK 文件。但在把它拖进工具之前，先做三件事，能省掉后面很多麻烦。第一，记录原包的 SHA-256、文件大小、包名、versionCode、versionName 和签名证书指纹；第二，把原包复制一份到只读位置，后续所有操作都不碰它；第三，确认工程目录所在磁盘有足够空间，路径尽量短，避免中文和空格。JDK 与 aapt 这类工具对长路径和特殊字符的容忍度，远不如现代 IDE。

第三点不是洁癖。反编译会在项目目录下生成大量深层嵌套的文件，Windows 的路径长度限制、杀毒软件的实时扫描、网盘的同步锁，都可能让一个本来正常的构建在中途失败。把工程放在一个普通的本地目录，例如 D:\ApkWork\项目名，比放在桌面、下载目录或同步盘里稳得多。项目名用英文、数字和短横线，版本号写进目录名，时间久了你会感谢当初的自己。

输入准备好之后，反编译的输出大致是下面这棵树。不同 apktool 版本的细节会略有差异，但主干稳定。

项目目录/
├─ source.apk                 原始输入，保持只读
├─ apktool/                   反编译工程
│  ├─ AndroidManifest.xml     可读的清单
│  ├─ apktool.yml             版本、SDK、压缩规则等元数据
│  ├─ res/                    资源：values、layout、drawable、xml
│  ├─ smali/                  主 dex 的反汇编
│  ├─ smali_classes2/         其余 dex（存在多 dex 时）
│  ├─ lib/                    各 ABI 的 so 库
│  ├─ assets/                 原样资源
│  ├─ original/               原始签名与清单副本
│  ├─ unknown/                未识别的文件
│  └─ build/apk/              部分版本保留的原始清单
└─ build/                     回编、对齐、签名产物

这棵树里，最容易被忽略的是 apktool.yml。它记录了反编译时读到的 SDK 版本、apktool 版本、是否保留调试信息、哪些后缀不压缩等信息。回编时这些信息会影响产物：版本号写错，装上去会显示旧版本；压缩规则改错，某些资源在运行时读不出来；SDK 信息不对，清单合并或资源编译可能报错。它看起来像配置文件，实际上是这次工程的“出生证明”，改动前先备份。

清单文件是另一个关键入口。反编译后的 AndroidManifest.xml 已经从二进制 XML 还原成可读文本，包名、版本、权限、Activity、Service、meta-data 都在里面。你能直接看到启动 Activity 是哪一个，能确认应用需要哪些权限，也能顺着 meta-data 找到渠道号、推送配置、第三方 SDK 的初始化参数。很多“改了没效果”的问题，最后都追到清单：改的是资源里的名字，启动的却是另一个 Activity；加了一个开关，清单里对应的组件根本没启用。

资源目录 res/ 是手动修改的主战场之一。按 Android 的约定，values/ 放字符串、颜色、尺寸、布尔值、数组；layout/ 放界面结构；drawable/ 放图片与形状；xml/ 放网络配置、文件路径、备份规则等。带语言或分辨率后缀的目录，例如 values-zh-rCN、drawable-xxhdpi，代表同一资源在不同配置下的变体。理解这一点，后面讲资源 ID 时就不会迷路。

反编译失败时，先别急着换工具。最常见的三类原因可以按顺序排查：第一类是路径与权限，工程目录太深、含特殊字符、被杀毒软件锁定；第二类是输入包本身，加固、伪加密、资源表过新，都会让 apktool 在解析阶段停下；第三类是工具链，JDK 版本不匹配、内存不足、框架文件不对。经典版把反编译日志留在工程目录里，错误通常出现在最后几十行，顺着 Exception 或 Could not 往前找，比盲目重试有效得多。

输入输出的纪律建立起来之后，才轮到“改”。而改之前还要回答一个更基本的问题：这次改动到底属于外观，还是属于行为？答案决定了你该打开资源 XML，还是该打开 smali。

三、smali 与资源 XML 的分工：一个管“长什么样”，一个管“怎么动”

把反编译后的工程想成两层：资源层负责“长什么样、说什么话”，代码层负责“发生什么、按什么顺序发生”。资源层的主体是 res/ 下的 XML 与图片，代码层的主体是 smali/ 下的反汇编。两者通过资源 ID 和清单连在一起。分不清这两层，就会出现“文案改了但按钮还是旧行为”“开关打开了但界面没变化”这类看起来诡异、其实很合理的问题。

资源层再细分，也无非三类。第一类是值：字符串、颜色、尺寸、布尔、整数、数组，放在 res/values/ 里，文件名通常按用途拆成多个 XML。第二类是结构：布局文件描述界面由哪些控件组成、怎么排列、初始属性是什么。第三类是素材：图片、形状、选择器、字体、原始 XML 配置。它们共同的特点是“声明式”——你写的是结果，不是过程。系统在运行时按当前配置挑一份最合适的资源，再把界面画出来。

举个最小的例子。应用名在清单里通常写成 android:label="@string/app_name"，而 app_name 的值在值资源里。你改值资源，桌面图标下面的名字就变了；你改清单里的引用，应用名可能变成另一个字符串，甚至因为找不到资源而编译失败。这条链子有三个环节：清单引用、资源名、资源值。手动精修要做的，是先确认链子在哪一环断的，再改那一环，而不是三处一起改。

代码层就是 smali。它不是 Java，而是 Dalvik 字节码的文本表示。阅读 smali 不需要背指令表，但需要建立三个基本概念：类描述符、方法签名、寄存器。类描述符用 L包名/类名; 表示，方法签名把参数和返回值编码成一串字符，例如 (Ljava/lang/String;)Z 表示“接收一个字符串，返回布尔”。看懂签名，才能确认自己改的方法是不是想改的那个。

.method public isInternal()Z
    .locals 1

    const/4 v0, 0x0

    return v0
.end method

这段 smali 很好读：方法返回布尔，声明了 1 个局部寄存器，把 v0 置为 0，然后返回。实例方法还会隐式带一个 p0，代表 this；参数从 p1 开始。把 const/4 v0, 0x0 改成 0x1，这个方法就从“否”变成“是”。这类改动的优点是极小、可读、可回退；缺点是它只改结果，不解释原因，所以必须配合验证，确认调用方没有别的兜底逻辑。

改 smali 的第一原则是“只动值，不动结构”。常量、分支条件、返回值、字符串，都是低风险改动；新增方法、增加局部变量、改变异常处理，属于高风险改动。原因在于寄存器分配：.locals 声明的数量决定了方法栈帧里有多少个局部寄存器，你在代码里多用了一个 v 寄存器，就必须同步增加声明，否则会覆盖参数或越界。更稳妥的做法是复用已有寄存器，或者把新逻辑放进一个独立的小方法里，再从原方法调用。

定位改动点有一套很实用的“反向追踪法”。如果问题出在界面文案，先在资源里搜文案原文，找到资源名，再搜资源名被哪些布局引用；如果问题出在点击行为，先在布局里找到控件的 id，再在 smali 里搜这个 id 的数值或绑定方法；如果问题只在某个日志之后出现，先用日志里的 tag 搜 smali 中的字符串常量，通常能直接落到打日志的那个类。手动精修的效率，很大程度取决于这套追踪是否熟练。

还有一条容易被忽略：改完要留下 diff。经典版的项目目录是你的工作区，不是版本库，所以更需要自己建立记录。最简单的办法是每次改动前复制一份工程目录，改完用文件比较工具生成差异；或者在项目里维护一个改动清单，写清楚文件、行号、原值、新值、原因。等到一周后需要回退，或者在另一台机器上复现，这份清单比记忆可靠得多。可复现不是工具自动给你的，它是工作方法攒出来的。

四、resources.arsc 与资源 ID：看不见的索引，决定改完能不能跑

资源 XML 改得再漂亮，最终都要经过一次编译，变成二进制 XML 和一张资源索引表。这张表就是 resources.arsc。它不存图片本身，也不存布局内容，它存的是“哪个 ID 对应哪个资源、在不同配置下分别取哪一份值”。应用运行时拿到一个 ID，先查这张表，再按当前语言、屏幕密度、夜间模式挑出合适的值。理解这张表，才能理解为什么有些改动“看起来对，装上就崩”。

资源 ID 是一个 32 位整数，习惯写成十六进制，结构可以粗略分成三段：包段、类型段、条目段。包段标识资源属于哪个包，普通应用的资源通常以 0x7f 开头；类型段区分字符串、布局、图片、颜色等大类；条目段是这一类里的序号。不同构建工具对类型段的分配不完全一样，所以不要背“字符串一定是 0x04”这种结论，更不要拿别的应用的 ID 往自己的工程里套。正确的做法是打开自己工程的资源映射，按名字查 ID。

0x7f 03 0001
  │  │  └── 条目段：这一类资源里的序号
  │  └───── 类型段：字符串、布局、图片等大类
  └──────── 包段：普通应用通常为 0x7f

反编译工具会生成一份资源映射，把每个资源名和 ID 固定下来。它的作用不是“方便看”，而是“防止重排”。原因很关键：smali 里引用资源时，常常直接写死了 ID 常量，而不是在运行时按名字查找。比如某个字符串被代码用来设置标题，反汇编里可能只有一句 const v0, 0x7f0f0021。回编时如果资源表重新编号，这个常量就指到了别的字符串，轻则文案错乱，重则类型不匹配直接崩溃。固定映射，就是为了让“名字到数字”的对应关系在改动前后保持一致。

那新增资源怎么办？答案是“按正规方式新增，让编译工具分配 ID”。在值资源里加一个新名字，在布局里用 @string/新名字 引用，回编时工具会给它一个新的条目号。只要原有映射被保留，老 ID 不会移动，新 ID 也不和老的冲突。真正危险的是手工去改映射文件里的数字，或者删掉映射条目让工具“重新排一遍”。前者会让 ID 与 smali 常量对不上，后者会让所有硬编码 ID 一起漂移。

配置限定符是另一个高频误区。资源目录后面的后缀不是装饰，它决定了这份资源在什么条件下生效。values 是默认，values-zh-rCN 是中文简体，values-night 是深色模式，drawable-xxhdpi 是高密度素材。系统会按当前设备状态挑最匹配的一份；一份都匹配不上时，才回退到默认。所以做汉化时，只往中文目录里加字符串、不补默认值，在中文设备上看起来完美，换一台英文设备就可能显示空白或直接崩。正确做法是默认值先补齐，再做语言覆盖。

验证资源改动，不能只看当前这台设备。至少要做三组切换：语言切到目标语言与默认语言，屏幕密度切到低密与高密，主题切到浅色与深色。如果应用支持平板或横屏，再加一组方向切换。每组都走一遍改动涉及的页面，观察文字是否截断、图片是否拉伸、占位符顺序是否正确。这些检查很枯燥，但它们正是手动精修相对“点一下看效果”的价值所在：你不是在赌它没问题，而是在证明它没问题。

五、导出 Android Studio 工程：从“改一个包”到“长期维护”

手动改包解决的是“这一版怎么改”。如果这个应用还要继续迭代，问题就会变成“下一版怎么维护”。经典版支持把工程导出为 Android Studio 可打开的工程，意义就在这里：你不再只能对着一棵反编译树做局部修补，而是可以把清单、资源、assets、native 库和代码整理进一个标准的 Gradle 工程，用 IDE 的搜索、重构、调试和版本管理继续往下做。

导出不是“一键还原源码”。反编译得到的代码经过混淆和优化，变量名、控制流、注解都可能与原始工程不同；资源也可能被压缩或重命名。所以导出后的第一件事不是改业务，而是让工程能稳定构建。这个过程有点像接手一个没有文档的老项目：先跑通，再理解，最后才动手。对于自有应用或已获授权的应用，这一步通常不难；对于来路不明的包，即使技术上能打开，也不建议投入维护，因为合规风险远大于收益。

签名是导出工程时最需要“想清楚”的一环。Android 用签名来确认“这个包确实来自同一个开发者”。用调试签名出的包，可以安装、可以测试，但不能作为正式交付；换了签名，老版本就无法覆盖升级，用户必须先卸载，数据也可能丢失。所以从第一天起就应该用一把固定的、备份好的自有密钥，并且把密钥口令与工程分开存放。经典版在回编签名环节支持多种密钥形式，导出到 Android Studio 后则回到 Gradle 的标准签名配置，两边的密钥可以保持一致。

工程能编译之后，先做一次“行为对齐”验证：安装导出的调试包，把原包也装到另一台设备或另一个用户空间，按同一份用例走一遍主要页面，记录差异。差异分三类：资源差异（图标、文案、颜色）、行为差异（跳转、开关、提示）、性能差异（启动时间、列表滚动）。只有确认差异都在预期内，才说明导出是成功的。这一步听起来繁琐，却能挡住后面大量“到底是我改坏的还是导出丢的”的争论。

导出的意义不是“从此不用再改包”，而是把一次性的修补变成可积累的工程。能进版本库的改动，才容易被团队接住。

六、多渠道打包：一份工程，多条可核对的交付路径

当一个应用要同时投放到官网、自有分发页、合作方页面和内部测试群时，最省事的做法是“打一个包到处发”，最坏的做法是“每个渠道改一套代码”。前者无法区分来源，后者会把回归测试的规模乘以渠道数。多渠道打包要解决的是中间那条路：同一份功能代码，只在一处注入渠道身份，产出多个可独立安装、可独立统计、可独立核对的包。

渠道身份可以放在三个位置，各自的可控性不同。选择哪一个，取决于你的读取方式和维护习惯，而不是哪个更“高级”。

不管放在哪里，有一条原则要守住：渠道只影响“身份”，不影响“行为”。渠道号可以用来做来源统计、更新提示、客服分流，但不应该成为打开或关闭付费功能、绕过权限、改变核心流程的开关。一旦渠道进入业务分支，测试就要为每个渠道单独设计用例，问题定位也会从“哪个版本”变成“哪个版本加哪个渠道”。更麻烦的是，这类分支很容易在后续版本里被遗忘，变成只有某个渠道才会出现的隐性缺陷。

打包流程建议固定成六步，每一步都有可检查的产出：

1. 固定基线。先产出一个不带渠道的基线包，记录版本号、构建时间、原包哈希。后续所有渠道包都以它为母本，避免“每个渠道各编一次”带来差异。
2. 维护渠道清单。用一行一个渠道名的文本文件管理，放进版本库。清单是唯一事实来源，不靠记忆，也不靠某个人的本地脚本。
3. 批量注入。用经典版的多渠道打包能力，按清单逐个生成；每次只改变渠道字段，其余内容保持一致。
4. 统一命名。采用“应用名-版本名-渠道名.apk”的格式，渠道名只用小写字母、数字和短横线，避免空格与中文，方便脚本处理和跨平台传输。
5. 逐个校验。验签名、验包名、验版本、验渠道值，四项全过才算产出成功。校验记录与包一起归档，不要只留在聊天记录里。
6. 归档可追溯。每个包记录 SHA-256、签名证书指纹、构建时间、对应的基线版本。以后出现“某个渠道包有问题”，能立刻定位到它和基线的差异。

关于“可复现”，这里要说一句实话：APK 构建受时间戳、签名填充、压缩实现等因素影响，很难做到字节级完全一致。手动路线追求的可复现，是“功能结果一致、差异可解释、过程可重放”。只要渠道清单、基线包、构建记录和校验结果都在，任何人拿到这套材料都能做出等价的一批包，并证明它们只差在渠道字段上。这比一句“我这边打过了”可靠得多。

渠道包最容易出的问题不是“打不出来”，而是“打出来了但没人能证明它和别的包只差一个字段”。校验记录的价值，就在这里。

七、自动脱壳修复、在线封装与小工具：边缘工序也要可控

一次完整的交付，除了“反编译、修改、回编、签名”这条主链路，还会遇到三类边缘工序：输入本身不可读，输出形态不是标准 APK，日常协作需要日志、装机与文件管理。经典版把这三类能力也放在同一个桌面工具里，好处是上下文不丢——你不用为了看一条日志切到另一个工具，也不用为了装一次包重新配一遍环境。

7.1 自动脱壳修复：先把“能读”解决掉

有些自有应用在上线前会做加固处理，反编译后只能看到壳的清单、少量 dex 和被加密的资源。这时候直接改 smali 没有意义，因为真正的业务代码不在你看到的这一层。自动脱壳修复要解决的，是把这类包恢复成一个可读、可编辑的工程，让后续的资源修改、文案替换、内测标识调整有落脚点。它的定位是“恢复工作区”，不是“破解保护”——这两者的边界必须分清。

使用顺序建议是“先修复、再检查、后修改”。导入原始包，执行修复，然后逐项确认：清单里的包名与启动组件是否正确，资源目录是否能正常展开，字符串与布局是否可读，native 库与 assets 是否完整。确认无误后，再进入手动精修。修复结果不理想时，不要急着在残缺工程上硬改，先回到输入侧确认包的完整性，或者换一个更接近原始构建的版本。

修复后的验证要覆盖四层：第一层是身份，包名、版本号、签名信息与原包一致；第二层是入口，启动 Activity 能正常拉起，权限声明没有缺失；第三层是资源，图标、字符串、布局在主要页面显示正常；第四层是行为，登录、列表、详情等关键路径没有因为修复而改变。四层都过，才适合继续做手动修改。任何一层异常，都说明修复还不完整。

7.2 在线封装 APP：把自家网页装进一个可控的壳

在线封装 APP 面向的是另一类需求：已有自己的网站或 H5 页面，希望有一个能安装、能分享、能出现在桌面上的入口。它的本质是一个受控的 WebView 壳，技术难度不高，但可控点很多。参数设得清楚，后续维护就轻松；参数随手一填，用户第一次打开就可能遇到白屏、返回键退出、文件无法下载等问题。

封装完成后，至少做五次打开：正常网络首启、断网首启、从后台恢复、点击返回键、触发一次文件下载。再补两组权限场景：允许与拒绝。每次打开都看一眼日志，确认没有证书错误、域名拦截或资源 404。这些检查不复杂，却能把“装上去能用”和“长期可维护”区分开。

7.3 日志、装机与文件管理：把手工活的摩擦降下来

手动路线最耗时的往往不是改代码，而是“找证据”和“搬文件”。日志工具负责前者：按标签过滤、看崩溃堆栈、把一段时间的输出保存下来，和改动记录放在一起。装机工具负责后者的一部分：识别设备、覆盖安装、拉起应用，省去在命令行里反复输入包名和组件名。文件管理则把工程目录、构建产物、原始包放在一个视图里，方便比对与归档。

经典版在 Windows 桌面运行，安装包约 13.74 MB，环境要求 ASP.Net 4.5+ 与 JDK 1.8+。体积不大，意味着它可以和你的 IDE、抓包工具、模拟器同时开着，不必为了改一个包关掉半个桌面。它也可以与安卓修改大师电脑版同机安装，项目互不冲突：一个负责自动流水线，一个负责手动精修，按任务性质切换即可。

八、两个自家应用实例：以前怎么做、现在怎么做、改完怎么验证

技术讲到这里，需要落到具体场景。下面两个实例都来自自有或已获授权的应用：一个是教学类 App 的中文本地化，一个是内部效率 App 的功能开关与内测标识。每个实例都按“以前怎么做、现在怎么做、改完怎么验证”三段写，方便你对照自己的项目。

8.1 自家教学 App：把英文界面做成中文，并补齐默认资源

以前怎么做。最原始的办法是把界面截图发给翻译，拿回一张对照表，再逐个打开布局文件替换文本。问题是文案不只在布局里：值资源里有，代码里有硬编码，WebView 加载的本地页面里也有。翻译表按截图编号，开发按文件改，两边对不上是常态。更麻烦的是占位符，例如“第 %1$d 课，共 %2$d 课”，翻译时顺序一换，运行时要么显示错位，要么直接抛格式异常。每次打包都要重新走一遍命令行，改一处、等一轮，验证成本很高。

现在怎么做。用经典版反编译教学 App，先在文件管理里确认资源结构：默认值资源有哪些、是否已经有中文目录、布局里哪些文本是写死的。然后按三步走：第一步补齐默认值，保证任何语言环境下都有回退；第二步新增中文资源目录，把词条按模块分组写入，保留占位符的编号与顺序；第三步处理“资源之外”的文本——在 smali 里搜字符串常量，替换代码中的硬编码提示；在 assets 里替换本地页面的文案。布局中固定宽度的文本控件，改成自适应或调整内边距，避免中文变长后被截断。全部改完再回编、签名、装机。

改完怎么验证。准备两台设备或两个用户空间，一台保持英文，一台切到中文。按同一份页面清单逐页对照：首页、课程列表、课程详情、练习、结果页、个人中心、设置、通知。重点看四类位置：带占位符的句子、带单位的数字、按钮与标签、弹窗与提示。再检查长文案是否截断、换行是否合理、中文标点是否统一。最后看日志，确认没有资源找不到的异常，并把词条对照表、改动清单、验证截图一起归档。这样下一次加课程模块，直接复用这套词条与检查表。

8.2 自家内部 App：用 smali 打开一个功能开关，并加内测标识

以前怎么做。内部效率 App 的源码在另一个团队手里，CI 只产出正式包。内测群需要一个隐藏的调试入口，还想在标题旁显示“内测”两个字，方便大家确认装的是哪一版。过去的做法是提需求、等排期、重新构建安装包，快则一天，慢则一周；如果自己装调试包，签名又和正式包不同，无法覆盖安装，聊天记录和本地缓存都得重来。

现在怎么做。用经典版反编译正式包，先定位开关方法。通常是一个返回布尔值的小方法，名字可能被混淆成短字母，但调用关系还在：从设置页的点击事件往上追，能找到判断入口是否显示的那处分支。把返回常量从 0 改成 1，或者在调用处把条件分支反过来，效果都是“入口出现”。接着处理内测标识：在标题对应的值资源后追加“内测”，或者在设置页的版本信息旁加一段固定文案。改完回编，用与正式包相同的密钥签名，覆盖安装。

# 改动前：开关默认关闭
.method public isDebugEntryEnabled()Z
    .locals 1
    const/4 v0, 0x0
    return v0
.end method

# 改动后：只改常量，不动寄存器数量
.method public isDebugEntryEnabled()Z
    .locals 1
    const/4 v0, 0x1
    return v0
.end method

改完怎么验证。第一步，覆盖安装是否成功，确认签名与原包一致；第二步，冷启动进入设置页，确认入口出现且可点击；第三步，进入入口执行一次真实操作，确认不是“只有按钮没有功能”；第四步，强制停止再启动，确认状态仍然存在——因为改的是代码而不是运行时缓存，重启后应该保持一致；第五步，检查关于页的版本信息与内测标识，确认没有影响正式版本号；第六步，看日志里有没有因为分支改变而新增的异常。最后把这处改动写进补丁清单，下次版本升级时按清单重新核对方法是否还在。

8.3 把本地化成果导出为 Android Studio 工程，继续维护

以前怎么做。本地化验证包通过后，下一步是把这个能力并回主线。如果只保留反编译目录，后续每加一个页面都要重新在 smali 与资源之间来回找，维护成本会越来越高。过去的做法是把词条表交给源码团队，等他们合并；排期不确定，验证也要重来一遍。

现在怎么做。用经典版把工程导出为 Android Studio 可打开的结构，先在 IDE 里跑通构建：对齐 SDK 与 Gradle 版本，补上缺失依赖，配置自有签名，保留原有 applicationId 与版本号。然后把本地化资源并入工程，确认资源名没有冲突，最后用 IDE 的搜索与重构能力做后续维护。导出不是替代源码，而是把“已验证的改动”变成一个团队能接手的工程形态。

改完怎么验证。先构建调试包并安装，按 8.1 的页面清单再走一遍；再构建一个与线上同签名的包，确认能覆盖升级；最后对比导出前后的资源映射，确认老资源的 ID 没有漂移。三步都过，才算真正完成“从改包到维护”的过渡。