甲方要源码怎么办：安卓修改大师电脑版的 jadx 还原与可编译修复

改包这件事，多数时候止步于"装上去看着对了"。但只要这一次改动是要交付的，你迟早会遇到一句话："能不能把源码也给我们？"

这句话的杀伤力在于它听起来很合理。对方不是在刁难你——他要维护、要二次开发、要过内部的技术评审、要证明这个东西不是"黑盒"。而你手上只有一个 apk。这时候你有三条路：说"没有"，说"我找人反编译一下"，或者当场打开一个能跑出 Android Studio 工程的工具。

前两条路的代价你都清楚。第三条路的代价，很多人不清楚：反编译出来的东西，和"能编译的工程"之间，隔着一段很长的距离。这段距离才是这篇文章要讲的东西。

一、先纠正一个误解：反编译 ≠ 还原源码

很多人的心理模型是这样的：apk 是编译产物，反编译一下就回到源码，就像解压一个 zip。

这个模型在 java 时代勉强成立，在 Android 上基本不成立。原因有三层：

第一层，编译是有损的。变量名、注释、泛型信息、局部变量名，在编译之后大部分都不在了。反编译能还原出"这段代码在做什么"，但还原不出"作者当时想叫什么名字"。你拿到的是一堆 a、b、f 开头的字段，逻辑对，可读性归零。

第二层，工程结构不在包里。apk 里只有编译后的 class 和资源，没有 build.gradle、没有模块划分、没有 settings.gradle、没有依赖声明。所有第三方库的代码是被打包进 dex 的，反编译出来就是一堆"你自己的源码"，会和真正的项目代码混在一起。

第三层，有一部分代码根本还原不回来。某些优化过的字节码、某些混淆后的控制流、某些加固过的包，反编译工具会直接放弃并抛出错误。这些方法的数量通常不多，但它们会让整个工程编译不过——因为少一个方法，调用它的地方就全红了。

所以"反编译"和"能编译的工程"之间的那段距离，具体就是这三层。而这三层都不是靠"换个更好的反编译器"能跨过去的——它们需要有人一段一段地补。

二、四段流程：它到底做了什么

在这套工具的详情页上，「立刻修改」右边有一个 生成源代码项目 的按钮。它的作用就是把上面那段距离走完，产出是一个能保存下来的 ZIP：里面是 Android Studio 工程。

点下去之后，后台发生四段事情。了解这四段，你才知道它卡住的时候该等还是该停。

阶段	在做什么	要等多久
① 准备 jadx	先找工具目录里有没有现成的；没有就自动下载并解压。窗口里显示进度，随时可以取消	第一次约一分钟级（约 69 MB），之后不再下载
② 导出工程	把 apk 拆成 java 源码 + Gradle 工程，先写到临时目录	看包大小，小工具通常一两分钟
③ AI 修复	补齐工程结构、清掉重复的第三方类、修资源、用 smali 补缺失方法，然后真的跑一次编译	这一段最长，通常是整件事的主要耗时
④ 打包交付	编译通过之后才发完成信号，把工程压成 ZIP，弹另存为	几秒到几十秒

这四段里有一个设计值得单独说：第二段先写临时目录，成功之后才替换正式目录。这意味着如果你中途取消、或者 jadx 崩了，上一次已经修好的那份工程不会被破坏。这个细节在日常使用中几乎感知不到，但它是"敢反复试"的前提——一个会覆盖掉上次成果的工具，你会不敢按第二次。

还有一处需要提前知道：第三段不是"AI 说修好了就算好"，而是"AI 真的跑一次编译，编过了才算好"。这个区别很大。前者是自我评价，后者是有客观标准的验收。如果一个工程只是"看起来补齐了"，但一编译就有两百个错误，那它对交付毫无价值——因为接手的人第一件事就是编译。

这一点也解释了为什么这个功能会比改个名字慢那么多：它做的不只是"生成"，还包括"自己验一遍"。而验一遍这件事，从原理上就没法省——因为要证明"能编译"，唯一的方法就是真的编译一次。

三、AI 到底在修什么：五类问题

"AI 修源码"这个说法太笼统了，容易让人以为它会在几千个文件里做智能改写。实际上它修的东西很具体，就五类。而知道这五类，你就能判断一次生成"修到什么程度"算可以接受。

第一类：补齐工程结构

反编译出来的东西可能有一个残缺的 Gradle 工程，也可能什么都没有。补齐的意思是：让它成为一个 Android Studio 能打开、能识别、能点击构建的项目——包括模块声明、编译版本、依赖块、目录层级。

这一类工作量不大但极关键。没有工程结构的源码，是"一堆 java 文件"；有了工程结构的源码，才是"一个项目"。前者你可以读，后者你才能改。

第二类：把第三方库的代码请出去

这是最脏的一块。apk 里所有第三方库的代码，都是被编译进 dex 的。反编译之后，它们和你的业务代码平铺在一起，看起来像是"这个应用自己写了两万行"。

而实际的工程里，这些东西应该是一行依赖声明：implementation '...'。所以修复要做的是：认出来这些类是哪个库、换成对应的依赖声明、然后把这些类从源码里删掉。

不删会怎样？两个后果。一是工程里凭空多出几万个文件，打开就卡，搜索就慢；二是依赖冲突——你在依赖里引了某个库的 2.0 版，而源码里还留着这个库 1.5 版的类，编译器会告诉你"重复定义"。

第三类：修资源和资源 ID

Android 的资源引用（布局、图片、字符串、样式）在编译后会变成数字 ID。反编译工具会尽量把数字还原成名字，但还原不总是成功——尤其是那些被资源混淆过的包。

一旦有资源 ID 没还原对，编译时就会报"找不到资源"。这类错误的特征是数量多、位置散、但每一条都很简单——不是逻辑问题，是"名字对不上"。修它的方式是逐个核对，把错误的引用指到正确的资源上。

这一类最容易被低估，因为它不出现在"代码"里，而出现在布局和配置里。你打开 MainActivity.java 看着一切正常，但一编译就有四十条资源错误——问题不在你正在看的地方。

第四类：用 smali 补回缺失的方法

还记得第一节说的第三层距离吗——有些方法反编译不出来。这些方法的数量通常很少，可能就三五个，但它们会让整个工程编译不过，因为调用它们的地方全都会报"找不到符号"。

这时候有一个很关键的资源：这个项目本来就是用 apktool 反编译过的，smali 目录里存着完整的字节码。也就是说，那个"缺"的方法，其实一直都在，只是没有 java 形态。

修法就是让 AI 去看 smali，把那个方法的行为读懂，然后用 java 写一个功能等价的实现补进去。这是整个流程里最"像推理"的一步，也是为什么它需要一个能读代码的东西来做，而不是一个固定的脚本。

顺便说一个实际影响：jadx 报错的方法名会被写进给 AI 的提示里，所以 AI 不是"漫无目的地扫一遍工程"，而是"知道该去补哪几个"。这个小设计的差别，在包大的时候非常明显——一个几万方法的包，让它自己找漏掉的那三个，可能永远找不到。

第五类：真的跑一次编译

前四类都是"改"，第五类是"验"。要求是跑 gradlew assembleDebug，编出一个 debug 包。编过了才发完成信号；没编过就继续修。

这一步的价值怎么强调都不过分。因为"看起来补齐了"和"确实能编"之间，通常还差几十个错误——而这些错误只有在编译的时候才会暴露。一个没有经过编译验证的源码工程，严格来说不算交付物，只算草稿。

四、为什么这件事注定要花一会儿

第一次用这个功能的人，最常见的反应是"怎么这么久"。这个反应很合理，因为前面的所有操作都很快——改个名字几十秒，换个图标一分钟。到了生成源码，突然要等十几分钟甚至更久，落差很大。

但这个耗时是有结构的，拆开看就不难接受：

耗时来自	为什么省不掉
反编译本身	这是把机器码翻回高级语言，天然比编译慢，和包大小成正比
第三方类的识别	要一类一类判断"这属于哪个库"，判断错了删掉就会缺东西
编译验证	真要跑 Gradle，这一趟本身就要几分钟，而且还可能来回几轮
错误的逐条修	编译报错可能有几十上百条，有些是同一个原因造成的，得先把原因找出来

换个角度想：如果不做这件事，你要付出的时间是多少？手工反编译、手工建工程、手工筛第三方库、手工修资源、手工补方法、手工调依赖——一整套下来，熟练的人也得以天为单位。而现在这段时间里你什么都不用做，可以去干别的。

真正需要你关注的不是"快不快"，而是"它停下来的时候，有没有告诉你停在哪"。这个功能在设计上有一个好处：窗口里显示的是阶段和进度，不是几千行滚动的日志。你看一眼就知道是卡在下载、卡在反编译、还是在修错误。能判断"要不要继续等"，比"等得短"更重要。

五、三个按钮：继续生成、重新生成、取消

这个功能里最容易被按错的地方，不是流程，是第二次点击。当工程目录已经存在的时候，确认窗口底部会出现三个按钮：继续生成、重新生成、取消。默认键是"继续生成"。

三个按钮的差别很实在，按错了要重花一次前面的时间：

按钮	它做的事	代价
继续生成	保留现有工程，不重新反编译。把上次的原话加上一段"当前进度"重新送进去，让它接着修	不丢任何已完成的修复
重新生成	删掉现有工程，从反编译重新走一遍	上次 AI 做的所有修复都会丢失
取消	什么都不做，现有工程原样保留	无

关键在于"继续生成"到底怎么继续。它不是重新开始，也不是简单地说"继续"两个字。它会先把上次发给 AI 的原话读出来，然后追加一段关于当前状态的事实描述——现在有多少 java 文件、多少 xml、多少资源文件，最近一次修改是什么时候，有没有 Gradle 工程文件，有没有编译产物，反编译日志里有几个错误。

这段追加的信息是整件事的关键。没有它，AI 会从头开始思考；有了它，AI 知道自己站在半山腰。而且它还被明确要求：先检查现状，不要推翻已有的修复，从上次的位置接着做。

这就是为什么"上次失败了，再点一次"这个动作，在这套工具里的语义和别的地方不一样。多数软件里"重试"意味着"从头再来"，这里默认意味着"接着来"。

一个容易被忽略的副产品

每次生成，那段发给 AI 的原话都会被存成一个纯文本文件，放在项目目录里，可读、可手工打开。它在两个地方有用：

一是"继续生成"能原样复用。这样即使你换了电脑、重启了程序，只要项目目录还在，继续生成的效果和当天一样。

二是你能看见它到底说了什么。这一点比看起来重要。很多人对"AI 收到什么"是没有概念的，于是出了问题只能猜。而这个文件把它变成了可读的文本——你可以打开看看它拿到的路径对不对、要求写得清不清楚。可读，是可控的前提。

六、交付的那个 ZIP 里有什么

生成成功之后，程序会把工程压成一个 ZIP 让你另存。这个 ZIP 的内容值得说清楚，因为它决定了对方打开之后的第一印象。

它保留了一个 source 顶层目录。也就是说，对方解压出来会看到一个文件夹，里面才是工程的各个子目录和文件。这个设计的意义是"解压即得一个完整目录"，不会把二十个文件和文件夹撒在他桌面上。交付物的第一印象，一半来自"解压之后看起来整不整齐"。

它排除了构建产物。编译出来的 build 目录、Gradle 的缓存目录、IDE 的配置目录、本机的路径配置文件，这些都不会进 ZIP。原因有三：体积、隐私、以及"这些本来就该由对方自己生成"。

其中"本机路径配置"这一项值得单独提一句。这类文件里通常写着你这台电脑上 SDK 的绝对路径，比如某个盘符下的某个目录。如果它被一起交出去，对方打开工程的第一件事就是看到一条指向不存在的路径的报错。排除它是小事，但不排除会制造一个很大的第一印象问题。

它没有压缩到没有余地：ZIP 还在项目目录里留了一份。如果你在"另存为"的时候点了取消，或者存到了一个后来找不到的地方，回到详情页的状态行，那里有一个可点的路径。这个设计解决的是一个很真实的场景：辛辛苦苦跑了二十分钟，手一抖点了取消。

顺便说一句使用上的建议：这个 ZIP 拿到之后，先自己解压、自己打开、自己编译一次，再发给对方。理由很简单——你打开的那一次，是唯一一次"在对方发现问题之前发现问题"的机会。而这一次的成本，只有几分钟。

这一个动作还能顺带给你两个信息：一是这个工程在你这台电脑上要多久才能编出来，你可以把这个时间告诉对方，他心里就有底了；二是有没有哪个环节需要额外的准备，比如首次构建要下依赖、要联网。这两条都属于"说了对方会轻松一点，不说对方会卡一下"的信息，而它们的成本只是你自己跑一遍。

七、交付源码前必须说清的三条边界

这一节可能是全文最重要的部分，因为它讲的不是"怎么用"，而是"别把话说错"。

把源码交出去的时候，最容易出问题的不是技术，是预期。对方拿到一个"能编译的工程"，会自动认为它就是"原厂的源码"。而这个理解一旦形成，后面每一个不符合他预期的细节，都会变成一次信任损耗。所以最好的做法不是把它修得更像原厂，而是提前把三条边界说白。

边界一：这是还原出来的工程，不是原厂工程

还原出来的工程能编译、能改、能出包，但它和原厂工程在三个地方一定不一样：

命名。类名、方法名、字段名大量是单字母或者 a1、b2 这种。这不是修得不好，是编译本身把名字丢了，任何反编译工具都拿不回来。要改名字可以，但那是一项独立的工作，不是"还原"的一部分。

结构。原来可能有十几个模块、清晰的层次、抽取好的公共层。还原之后通常是一个模块、平铺的结构。因为包里的组织方式是按包名，不按模块。

注释。一条都没有。原来的注释在编译时全部消失，还原不出来。这件事对小项目无所谓，对大项目是致命的——因为一个没有注释的陌生工程，读起来比读文档还累。

边界二：能编译不等于好维护

"能编译"是一个客观标准：跑一次构建，成功。这个标准很清楚，也很好验证。

但"好维护"完全是另一件事。它涉及命名是否达意、结构是否分层、依赖是否干净、有没有重复逻辑、异常处理是否完整。这些东西，还原工程通常都不具备——不是因为修得不够，而是因为信息在编译的时候就丢了，修的人无从还原"作者当时怎么想的"。

这件事的实际影响很具体：如果你交出去的工程，对方团队打算长期维护，那他们迟早要做一次重命名和结构梳理。这是额外的工作量，最好提前说，别等他们接手一个月之后才发现。

反过来说，如果对方的用途只是"改几处文案、换个图标、出个白牌版本"，那这个工程完全够用——因为这些改动不需要理解结构。所以边界二的关键不是"能不能用"，而是"用来干什么"。问清用途，比争论质量有用。

边界三：有些包做不出来，这是正常的

有三种情况，还原会明显吃力甚至做不出来。提前知道，可以省掉很多无效等待。

一是加固过的包。如果原包被加固处理过，dex 本身就不是正常的字节码，反编译出来可能是空的、可能是壳。这种情况不是工具的问题，是包的结构已经改了。

二是重度混淆且优化过的包。混淆本身不影响反编译（名字难看但逻辑还在），但某些代码优化会让控制流变得难以还原，报错的方法数量会明显上升。这时候靠 smali 补的工作量就大了，能不能补全要看具体包的运气。

三是超大的包。不是做不出来，是时间会很长——反编译和编译验证都和体积成正比。如果你的包有两三百兆，做好等很久的准备，或者干脆把它当成一个"过夜任务"。

这三种情况的共同点是：它们都不是"再试一次就好了"的类型。试第二次的收益很低，因为障碍不在流程上，在包本身。认出来、说清楚、换方案，比反复重试更专业。

八、两个自家应用的实例

下面两个都是我们自己有版权、有权修改的应用，需求也都是真实发生过的。

实例一：客户要"能自己改文案"的工程

给一个客户做的白牌应用，交付的时候对方提了一个要求：以后文案要自己改，不想每次都找我们。这个要求很合理，但按原来的交付方式（给一个 apk）做不到。

做法是：在这个项目的详情页点「生成源代码项目」，等它把工程还原出来、编译验证通过，拿到 ZIP。然后我们自己先解压、在 Android Studio 里打开、跑一次构建——确认这一步没问题，才把 ZIP 发过去。

同时发过去的还有一段说明，大意是三句话：这是一个还原工程、能编译能出包；文案在哪个目录下、改完怎么构建；命名是反编译形态，不用在意。

对方后来反馈说，第一次构建花了点时间（Gradle 第一次要下依赖），之后就顺了。而这个客户从此再没为"改一句话"付过费——我们省了沟通，他省了等待，这笔账双方都划算。

实例二：一次没做出来的经历

这个例子说出来可能更有用。有个从外部拿到的包，我们想还原成工程来做二次开发，结果试了两次都没成——反编译阶段产出的 java 文件很少，大量方法报错，补了之后又冒新的。

后来判断是那个包做过处理，dex 不是常规形态。这时候继续试只是在消耗时间，因为障碍不在工具链上。最后换的方案是：不还原工程，直接在包上做界面层的改动——而这恰好是我们真正需要的部分。

这件事的收获不是"这个功能不行"，而是学会了先分清"我要的是源码，还是我要的是能改这个东西"。很多时候是后者，而后者根本不需要源码。源码真正的用武之地是：对方要长期维护、要接进自己的工程、要通过内部代码评审。如果只是"我想自己改几处"，那生成源码可能是绕了远路。

九、源码交付清单：比 ZIP 多五样东西

把 ZIP 发出去，技术上就算交完了。但从"对方能接手"的角度看，一个 ZIP 远远不够——它只回答了"东西在哪"，没回答"这东西是什么、怎么用、有什么坑"。

下面这六项，是我们在实际交付中固定会准备的东西。加起来的成本不超过十分钟，但它把"交付"从一次传文件变成了一次交接。

交付项	一句说明它为什么在
工程 ZIP	主体。你自己先解压、打开、构建一次再发
源 apk	必须一起给。它是所有比对的基准，也是万一工程坏了唯一能回去的地方
一份改动说明	从原始包到这个包，你改了哪几处。不超过十条，按位置写，不按时间写
构建环境要求	JDK 版本、Gradle 版本、编译 SDK 版本。这一项缺失造成的第一次失败最多
签名信息	原包用的是哪一档签名、你自己出包要用哪个。签名不对，装不上，而这是最难自己想到的原因
已知问题清单	你发现但没解决的那几条。写出来不丢人，不写才是埋雷

六项里最容易被省掉、又最不该省的是第五项。签名这件事的特点是"不装不知道"——对方辛苦改了三天，打出一个包却装不上手机，最后发现是签名和原来不一致，要卸载重装、数据全丢。这个场景在真实项目里发生的频率，比想象中高得多。

第四项也值得强调。构建环境这一条，看起来是"技术细节"，实际上是第一次打开工程的成败。对方电脑上的 JDK 是 17 而你用的是 11，Gradle 版本不匹配，编译 SDK 没装——这些都不是工程的问题，但都会表现为"工程跑不起来"。

第六项最反直觉。多数人交付时倾向于只说自己做到的部分，把没解决的藏起来。但源码交付不一样：对方迟早会发现，而发现的时间点决定了他对你专业程度的判断。你现在写出来，叫"考虑周全"；他以后自己发现，叫"隐瞒问题"。同一件事，两种评价。

一个不常被提到的用法：把源码当成"说明书"

除了交付，这个功能还有一个自用价值：当你要改一个完全陌生的包时，先把它生成为工程，读一遍，再动手。

因为改包的多数失误，源头都是"不知道它原来是怎么写的"。你猜某个页面的标题存在哪里，猜错了就改了个不生效的地方；你猜某个按钮点击之后会跳哪儿，猜错了就把流程弄断了。而看一眼代码，这些猜测全部变成事实。

它不需要修到编译通过才有价值——哪怕只是能读的代码，也足够回答"这段逻辑在哪"这种问题。所以如果你手上有一个要反复改、又一直摸不清的包，花十几分钟生成一次，之后每次改都会快很多。这笔投入的回报，比多数人预期的高。

十、五种卡住的情况，怎么判断

生成源码这个流程，卡住的方式和其它功能不太一样：它不怎么报错，多数时候只是"一直在跑"。所以真正需要的是一套判断"现在该等还是该停"的方法。

情况一：停在准备阶段，进度条几乎不动。大概率是在下载反编译工具（第一次用的时候，约 69 MB）。这时候该等——网速慢的话一两分钟也正常。判断依据是进度条有没有在动，哪怕很慢。完全不动超过几分钟，才是真的卡了。

情况二：反编译阶段跑了很久，没有阶段提示。看包多大。几十兆的小工具跑几分钟是正常的，几百兆的包跑半小时也正常。这里没有加速的办法，因为它就是在做一件耗时的事。如果你赶时间，取消掉，换个时间再跑。

情况三：修复阶段反复来回，一直在编译。这是最需要耐心也最需要判断的一种。AI 在修编译错误，修一轮编一轮，每轮都要几分钟。这里的关键指标是"错误数有没有在减少"——如果从两百条降到八十条，是在收敛；如果一直在四十条上下反复，可能撞上了某个结构性的问题。判断不了就让它多跑一会儿，因为重来的成本更高。

情况四：跑完了，但工程打开编译不过。先看两件事：一，你电脑上的 JDK / Gradle / 编译 SDK 版本是不是和工程要求的一致（这是最常见的原因）；二，工程目录里有没有构建产物残留（如果有 build 目录，删掉重试一次）。这两条能解决大部分"我这边编不过"的问题，而且都不需要重新生成。

情况五：直接报失败，说没有产出源码。这种情况通常是包本身的问题（加固、异常结构）。不要反复重试，先确认这个包是不是被处理过。如果确认是，那就换方案——按第八节第二个实例的思路，先问自己"我要的是源码，还是能改这个东西"。

十一、十二个常被问到的问题

问一：这个功能是"反编译"还是"还原源码"？

严格说是"反编译 + 修到能编译"。反编译只负责把字节码翻回 java，修的部分负责让它真的成为一个工程。只反编译不修，你会得到一个能读但不能跑的代码堆。这个区别，就是为什么前面四段流程里有三段是在修。

问二：为什么不能直接给我原始工程？

因为原始工程不在 apk 里。apk 是编译产物，里面只有编译后的代码和资源。原始工程在开发者的电脑上、代码仓库里。任何工具都变不出来——这不是能力问题，是信息已经不存在了。

问三：生成的工程能直接上架吗？

能出包，但上架前有几件事要自己做：确认签名用的是你自己的、检查包名是否要改、看一眼版本号、过一遍隐私合规。还原工程解决的是"有东西可改"，不解决"能不能上架"——后者是一堆合规和配置问题。

问四：我要改的只是几处文案，还需要生成源码吗？

不需要。直接在包上改，一句话的事，几十秒。生成源码是为"要交出去"和"要长期改"准备的，改几处文案用不上。这个判断很重要——它能帮你省掉十几分钟，也能避免"我拿到源码了但不知道怎么用"的尴尬。

问五：生成一次要多久？

小工具通常十几分钟能出结果，大包会更久，主要花在反编译和编译验证上。没有"大概几分钟"的准确答案，因为它和包的大小、需要修的错误数量强相关。建议按"挂着不管"来安排，不要盯着等。

问六：中途取消了，之前的活白干了吗？

没有。反编译用的是临时目录，取消之后不会破坏上一次已经修好的工程。再点一次的时候选「继续生成」，就会从上次的位置接着做。"敢取消"是这套流程的一个隐藏优点——你知道退出来不会损失什么，才敢去试。

问七：为什么"继续生成"和"重新生成"差这么多？

因为"继续"保留了所有已完成的修复，只补剩下的；"重新"把工程删掉，从反编译重新开始。在前者里，你之前等的那些时间是资产；在后者里，它们是沉没成本。所以除了"改坏了"和"换了源包"，其它情况都该选继续。

问八：生成的工程里有第三方库的代码，正常吗？

如果只有极少量的、判断不出归属的类，正常；如果里面有成片的知名开源库代码，说明第二类修复没做干净。判断方法很简单：看包名。正常的业务工程，代码应该集中在自己的域名下面。

问九：我能在这个工程上继续用 AI 改界面吗？

这是两条不同的路。生成源码之后，你要改的是 java 和 xml，那是开发者的事；而"说话改包"改的是包里的资源，不需要碰代码。先想清楚你要哪一种：要交给开发团队维护，走源码；要自己快速改外观，走改包。两个混着做，会乱。

问十：为什么只有 apk 项目有这个按钮？

因为只有 apk 里有 dex 可以反编译。exe、jar、class 这些类型不是 Android 应用，没有"还原成 Android 工程"这回事——它们是直接改原文件的。按钮不显示，不是坏了，是这个类型不适用。

问十一：对方要求"和原厂一样的源码"，怎么办？

直接说明做不到，并给出替代：可编译、可继续开发的还原工程。这个要求本质上是要一个不存在的东西，任何承诺能满足它的说法都不诚实。而"能做到什么、做不到什么"讲清楚，反而更容易被接受——因为对方真正怕的是"你给我一个跑不起来的东西"。

问十二：这件事值不值得做？

看对方要不要"接手"。如果这次交付之后，这个应用就跟你没关系了，那源码是必须的——否则对方拿到一个黑盒，第一个改动就得回来找你。如果只是自己用、自己改，那大概率用不上。判断标准只有一句：这个东西以后是谁在维护。

十二、他们被要过源码之后

十三、写在最后：把黑盒变成可以打开的东西

这篇文章的起点是一句听起来很普通的话：能不能把源码也给我们。但它背后指向的，是一个更普遍的问题——你交出去的东西，别人能不能接手。

只交一个 apk，等于交了一个黑盒。对方能装、能用、能看，但一旦要动它，就必须回来找你。这在短期是"黏性"，在长期是"负债"——因为你会一直被这个包牵着，哪怕这个需求已经很小很小。

而交一份可编译的还原工程，等于把这个盒子打开了。打开之后，它的形状不如原厂工整——名字是乱的、结构是平的、没有一句注释。但这些都不妨碍对方"接着往下做"，而这恰好是交付的全部意义。

我在第七节花了很大篇幅讲三条边界，也是这个原因。因为这件事真正的风险不在技术，而在预期错位：对方以为拿到的是原厂工程，打开一看是反编译形态，于是开始怀疑你藏着什么。而如果你提前说清楚了，"不工整"就变成了"已知条件"，他甚至会觉得你诚实。

同样的道理适用于整个改包的工作。你会发现，越往后走，决定成败的东西越不像技术：是你说清需求的能力、是你验证的习惯、是你交付时把话说白的坦率。技术层面的操作，反而是最早被解决掉的那一部分。

回到那句话——只需说话，就能让应用变成你想要的样子。这句话在改界面的时候最直观，但在"要源码"这种场合，它还有一层意思：你连"把这个包还原成一个能编译的工程"这件事，也只需要按一下按钮、等一会儿。而你要花心思的地方，是按下之前想清楚"我要它干什么"，和拿到之后说清楚"它是什么"。

如果你手上正好有一个要交付的包，而对方提过源码的事，不妨今天试一次：点那个按钮，去干别的，回来解压、打开、编译，然后发出去。整个过程你可能只需要做四件事——点、等、验、说。四件事里，前三件都有明确的完成条件，只有最后一件取决于你怎么表达。

工具在这里：https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。安卓修改大师智改工坊能替你走完反编译、修复、编译验证那条最长的路；而"交给谁、怎么说清楚"这件事，还是得你自己来。

---