方法数 65536 与 multidex：分包从哪来，大包改造怎么控节奏

先把本文的主角介绍清楚。安卓修改大师智改工坊是一款 Windows 桌面工具：把自家或已获授权的安装包拖进去，用中文写下要改什么，AI 在反编译出来的工程里改 smali 与资源，改完自动回编、对齐、签名、校验，最后一键装到手机或模拟器上看效果。它的介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

改包这件事有一个躲不开的"物理常数"：65536。它不是某一款工具的限制，也不是某一版系统的限制，而是 dex 文件格式自己带的额度。你平时感觉不到它，直到某一天，你在一个已经很饱满的包里加了几行代码，回编突然就失败了 —— 报错里出现的正是这个数字。更让人困惑的是：同样"加了几句代码"，上周明明顺利出包，这周却直接失败。差别到底在哪里？

这篇分四层讲：65536 从哪来（dex 的表结构）、超了会怎样（三个不同阶段的不同表现）、multidex 与 smali_classesN 的对应关系（为什么"搬目录"能解决、搬的时候为什么不用改一行调用）、大包改造的节奏控制（结合等待机制与打包链路，把一轮改动拆成可验证的几步）。最后配两个自家应用的改包实例，每一步都写清"以前怎么做、现在一句话怎么做、改完怎么验证"。

一、65536 从哪来、超了会怎样：dex 的 16 位表与三种翻车表现

APK 里的可执行代码存放在 dex 文件里。dex 不是把 Java 字节码原样搬过来，而是重新排布成一套自己的结构，其中有两张表是最关键的：方法引用表（method_ids）和字段引用表（field_ids）。代码里的每一次方法调用、每一次读写字段，都对应表里的一条条目。

问题出在这两张表的寻址方式上：dex 指令里引用它们用的是 16 位下标。16 位能表示的范围是 0 到 65535，一共 65536 个位置 —— 这就是那个数字的全部来历。它不是谁拍脑袋定的，而是格式本身的宽度决定的：65536 这个界限，数学上就是"下标装不下了"的位置。

还有一个细节值得知道：字段引用表撞线的门槛和它一样宽。有些包不是"方法太多"超的，而是"字段太多"超的，报错里的数字仍然是同一个量级。你不需要在动手前算这些数，但你需要认识这种失败 —— 因为它的处理方式和"写错了代码"完全不同：不是逻辑问题，是容量问题。

超了会怎样：三个阶段，三种表现

同一个"装不下"，发生在不同的阶段，表现完全不一样。搞清楚这一点，能帮你在一分钟内判断"这是容量问题还是我改错了"。

阶段	典型表现	你该做什么
构建阶段（有源码）	编译器直接报"方法/字段引用超出单个 dex 容量"之类的错误，明确指向 65536	开多 dex 或者精简依赖；这一步报错反而是好事，信息最明确
改包阶段（只有 APK）	回编失败：把 smali 汇编成 dex 的那一步装不下，整个回编中断	把一部分类挪到第二个 dex 目录，再回编（下面第三章讲）
安装/运行阶段（老系统）	包里已经有多个 dex，但系统版本低、应用没做准备，装不上或启动就崩	先看这个包的最低支持版本，再决定要不要拆、拆给谁

在智改工坊里，第二行这种情况的表现非常具体：点「立刻修改」后等 AI 改完，自动弹出的打包窗口会在回编那一步失败。它会给你一句人话（哪一步、退出码多少），带上日志文件的路径，还会把日志的最后几行直接截出来贴在提示里 —— 你不用自己去翻文件，就能看到"装不下"这条报错。整个过程写在项目目录下的打包日志里，回编、对齐、签名、校验四步一行行都留着。

这条流水线长这样（也就是打包窗口背后真正跑的四条命令）：

第 4 步看起来重复，其实不是：前三步只能看"命令有没有跑完"，而"签名到底有没有生效"必须由 verify 说了算 —— 万一密钥格式不对（私钥不是 DER、证书不是 X.509），只有这一步会明确报出来。对齐这一步的作用也值得一句话说清：它把包里未压缩的数据按固定边界摆放，系统读取时可以直接映射，不必整包解压；带原生库的包尤其受益。

判断口诀：回编报"容量"相关错误 → 是分包问题；回编报"语法/符号"相关错误 → 是这次改动本身有问题。 两者都不需要重头再来：项目、历史、需求原文都还在，改一句话再跑一轮就行。

这里还藏着"等待机制"的一个设计前提：改包这件事的失败点分布得很开 —— 有的失败在 AI 改代码时（改不出来），有的失败在回编时（装不下、语法错），有的失败在对齐签名时，有的失败在装机后（装上了但行为不对）。工具把这几段分别交给不同的组件去负责，就是为了让每一段的失败都能被单独看见。

二、multidex 与 smali_classesN：目录与 dex 是一一对应的

在一个多 dex 的 APK 里，dex 文件的名字不是随便起的，而是固定约定：第一个叫 classes.dex，第二个叫 classes2.dex，第三个 classes3.dex，依此类推。系统按编号顺序加载它们，名字和顺序都是有意义的。

反编译之后，这套编号就变成了目录：apktool 把第一个 dex 的内容展开到 smali 目录，第二个展开到 smali_classes2，第三个展开到 smali_classes3，一路对应下去。回编时反过来走：每个 smali 目录各自被打成一个 dex，目录编号就是最终 dex 文件的编号。

工程里的目录	回编后包里的文件	加载顺序
smali/	classes.dex	第 1 个，最先被加载
smali_classes2/	classes2.dex	第 2 个
smali_classes3/	classes3.dex	第 3 个

关键洞察：类放在哪个 dex，不影响它怎么被调用

这是全部技巧里最重要的一条，也是"搬目录"为什么能解决问题的根本原因。在 dex 里，一个类是被它的完整描述符指认的 —— 长这样：Lcom/example/app/MainActivity;。它是一串字符，不是"第几个 dex 里的第几条"。运行时由类加载器拿着这串字符，在应用的全部 dex 里去找这个类。也就是说，引用关系是按名字建立的，跟文件放在哪无关。

于是结论顺理成章：把一批类从 smali/ 挪到 smali_classes2/，理论上不需要修改任何一条调用指令 —— 调用方写的还是那个描述符，它照样能找到目标类。这就是"分包"可行的原理：它不是"重新组织代码"，只是"把同一批代码换了个文件装"。

需要说明的是：回编工具本身不会替你判断"这个 dex 装不下了，我帮你拆一个"。 它只做一件事 —— 按目录打包。你给它一个 smali 目录，它就认认真真把里面的东西汇编成一个 dex；装不下就报错退出。所以"分包"这个动作，必须有人来做：谁来搬、搬哪些 —— 这是改包流程里少数几个结构性决定之一，也是典型的"你要说清楚、AI 能执行"的活儿。

搬目录的三条经验：搬哪一支、哪些不能搬

第一，优先搬"自成一支"的包，而不是按文件散搬。 工程里的 smali 文件是按包名一路排下来的（smali/com/xx/yy/SomeClass.smali），一个完整的功能模块通常就对应一棵完整的子树。整棵子树搬到第二个 dex，结构清楚、事后也好回看；把几十个零散文件凑在一起搬，出了事你连"搬过哪些"都说不清。

第二，启动路径上的类不要动。 这一条在"最低支持版本低于 5.0"的包上是硬要求：老系统启动应用时只会自动加载主 dex，其余 dex 要靠应用自己在最早期加载进来 —— 所以凡是启动阶段就会被用到的类（应用入口、主界面，以及它们直接依赖的工具类），都应该留在主 dex。把这类类搬走，表现就是"新机器一切正常、老机器打开就崩"，而这类问题排查起来非常费时间。

第三，一次搬走一整支通常就够，不必急着建第三个 dex。 工程里已经有 smali_classes2 的包，优先往它里面继续放；只有当它自己也快满的时候，才考虑再建一个。判断"够不够"的标准不是估算，而是回编 —— 搬完立刻打包一次，通过就说明这一轮的量是合适的。

别忽略"最低支持版本"这一项

多 dex 在老系统上不是天然成立的。Android 5.0（API 21）之后，系统原生支持一个应用带多个 dex；而在 5.0 之前，需要应用自己通过多 dex 支持机制，在启动的最早期把其余 dex 装进来 —— 这是原包本身就该带的能力，不是你拆目录能补上的。

所以动手前先看一眼这个包的最低支持版本（导入解析时会读出来，也写在项目的配置里）。三种情况：最低版本 ≥ 21 —— 放心拆，新系统本来就支持；最低版本 < 21，且原包本来就是多 dex —— 说明它的多 dex 机制是齐的，你只是把类在已有 dex 之间挪一挪，风险很小；最低版本 < 21 且原包是单 dex —— 这一档要谨慎：拆出来的第二个 dex 在老机器上可能根本不会被加载，表现是"新机器好好的、老机器打开就崩或装不上"。遇到第三种，合理的做法不是硬拆，而是重新想需求（能不能不加这么多东西、能不能把功能做成资源层的改动）。

三、为什么"加了几句代码"有时会触发分包，多数时候却不会

这是新手最容易被吓到的一点：明明只是加了一个按钮、改了一段判断，怎么就"分包"了？反过来，改了一个大功能，怎么又什么都没发生？答案分成两半。

多数时候不会，因为余量本来就很大

一个已经在生产环境跑的包，通常离单 dex 上限有几万条引用的余量，而且不少包本来就是多 dex 结构（主 dex 装启动路径，其余装别的）。你在这种包里加一个按钮、加一段导出逻辑，增加的引用量是几十到几百条这个量级 —— 相对于 65536 的额度，是零头。不改结构、只改内容的改动，绝大多数都属于这一类：你看到的只是"改完、打包、装机"，中间什么额外的事都没发生。

会触发，通常是踩中了这四种情况之一

1. 原包是单 dex，且已经贴着上限。 历史上不少包在接近满额的状态下发布，后续每次小改都是在悬崖边上走。这种包的特点是：改动小、报错硬 —— 第一轮就撞线。
2. 你加的代码全落进了"最满的那个 dex"。 编号小的 dex 不一定最空：主 dex 里常驻着启动路径上的一整套类，反而可能是最挤的一个。AI 按你的需求在某个类里加代码，那个类属于哪个 dex，你的新增引用就记在哪个 dex 的账上。
3. "几句代码"其实是一大段逻辑。 一段几十行的功能，如果里面反复调用系统 API、构造对象、拼接字符串，很容易折算成几百条方法引用。再叠上字符串与字段引用，一次就能把余量吃掉一截。
4. 不是越界，而是"看起来像越界"。 回编失败的原因有好几种，报错文本会告诉你到底是哪一种。别一看到打包失败就往"方法数"上想 —— 先看日志里那句关键的话。

一个实用的判断顺序：先看是不是这次改动的语法/符号问题 → 再看是不是容量问题 → 最后才考虑是不是环境问题（工具链缺件）。 智改工坊的失败提示里带着"是哪一步 + 退出码 + 日志尾部 + 日志路径"，按这个顺序读，通常一眼就能定性。

顺手学会估算：一次改动大概会消耗多少"容量"

不用精算，但建立一点数量感很有用，它能让你预判"这个需求会不会碰容量"。可以按下面这个粗口径来估：

代码里的动作	大致消耗	说明
调用一个方法（含系统 API）	1 条方法引用	同一个方法调用一百次也只算一条（表是按"不同的方法"去重的）
读写一个字段	1 条字段引用	同上，按字段去重；字段表也有自己的额度
新增对象、类型判断、异常捕获	1 条类型引用 + 构造调用	字符串拼接、集合操作、JSON 解析是常见的"引用大户"
改文案、换图片、删一个弹窗	接近 0	资源层的改动几乎不碰方法引用表，所以很少跟容量扯上关系

两条推论：新增一段完整逻辑（读文件、解析、写进界面）产生几百条引用是很正常的，它在本来就饱满的包里就可能推过线；而纯资源与文案的改动基本不吃容量。这就是为什么"我明明只改了几个字"和"我就加了一个按钮"会有完全不同的结果 —— 前者动的是资源，后者动的是代码。

还有一点值得提前知道：就算真的触发了分包，它也不是"改坏了"。分包是 Android 官方支持的正常结构，多 dex 的包在 5.0 以后的系统上运行与单 dex 没有区别。真正需要警惕的不是"包里有几个 dex"，而是"这个包在老系统上能不能被正确加载" —— 也就是上一章那个"最低支持版本"的判断。

四、等待机制：一个标志文件、2 秒一次、1 小时上限

改一个饱满的大包，最耗时间的不是"改"，而是"等"。工具在这件事上的设计很朴素，但每一条规则都直接影响你怎么用。

它是怎么知道"AI 改完了"的

右侧那个 AI 改包程序是一个独立的聊天窗口，主窗口没法直接从它那里拿到"完成"的回调。于是两边用了一个最古老、也最可靠的办法：约定一个文件。发出去的需求末尾会带上一条固定说明，要求 AI 在确认全部改完之后，在项目工作目录下生成一个名为 ai_done.flag 的标志文件；主窗口这边每 2 秒看一眼它在不在（改代码动辄几分钟，2 秒一次完全够用）。

四条由此推出的使用纪律

第一，一轮需求只做一件事（或一组强相关的改动）。 因为标志文件代表的是"整轮完成"，AI 被明确要求"只能在整个修改真正结束之后再生成，中途不要生成"。这意味着：一轮里塞五件事，中间没有任何反馈；如果第四件卡住了，你没有任何办法知道前三件已经改好了。而在大包上，一轮拖到一小时上限，前功尽弃的代价是实实在在的。

第二，不要自己去项目目录里手工造那个标志文件。 它是"整轮完成"的信号，不是"现在可以打包"的开关 —— 手工造一个，等于告诉程序"AI 已经改完了"，它会立刻开始打包一个半成品。想跳过等待直接打包，用详情页上的「去打包」：它本来就是为了"不等 AI、直接打当前工程"准备的入口。

第三，等待是可以收起来的。 等候窗口上除了「取消修改」，还有一个「后台等待」：把窗口收起来，继续等标志文件；顶栏会留一个「AI 修改中」的入口，随时把窗口叫回来。而「取消修改」不只是关窗口 —— 它会同时去点掉右侧 AI 里的停止按钮，这次自动修改就此结束。忙别的事的时候，这个区别很重要。

第四，超时不等于失败。 一小时到了，停止的只是"自动等待 + 自动弹打包窗口"这一步。AI 大概率还在继续跑，工程也还在那儿。你完全可以过一会儿用「去打包」手动把这一轮收尾。大包的一小时，最好留给你确信"一次能跑完"的改动量。

顺带说一个"边界感"的细节：需求发出去的时候，附带的固定环境说明里还有两句约定 —— 让 AI 把工作目录切到当前项目下面去改，以及不要在右侧那个应用里打包。原因是打包这件事由主窗口负责：回编、对齐、签名、校验四步是一条固定的流水线（apktool b → zipalign → apksigner sign → apksigner verify），最后一步 verify 还会打印出签名证书信息，用来确认"真的签上了" —— 前三步只看退出码是不够的。这条流水线只在主窗口这边跑，你才会在固定的位置拿到固定的产物。

发出去的那段话，其实是三层拼起来的

理解"你写的"和"真正发出去的"之间的差别，能解释两个常见疑问：为什么历史记录里看不到那些环境说明？为什么重跑上一轮时要重新附一次附件？答案是这句话由三段拼成：

三个由此而来的操作习惯：① 想"照上一轮再改一遍"，从历史里点「选择」把原话填回输入框，但附件要重新附一次（历史里没有它们）；② 需要复现某轮改动时，先在输入框里补上那句你自己写的原话，再补附件 —— 不要依赖"程序会记得我上次附了什么"；③ 换项目时附件会被自动清掉，这是有意的：免得把 A 项目的素材发到 B 项目的工程里去。

五、大包改造的节奏把控：一轮改动的五步与时间预期

把前面讲的机制合起来，就能得出一套"大包怎么改才不慌"的节奏。核心思路只有一句：把不可控的大改动，切成若干个"一轮能验证完"的小改动。

步骤	发生了什么	时间预期与提醒
1. 导入与反编译	拖入安装包，解析图标/应用名/包名/版本/最低与目标 SDK，后台反编译出工程	实测 12MB 的包约 3 秒；大包更久，超过 10 分钟会中断并给出原因。反编译跑在后台，界面不卡
2. 写需求（含附件）	一句话说清要改什么；要替换素材就带上附件与用途说明	这一轮只做一件事 —— 步骤 3 的等待期间没有中间反馈
3. 等 AI 改完	需求送进右侧窗口执行，主窗口每 2 秒看一次标志文件	上限 1 小时。可以「后台等待」；等不下去用「取消修改」连 AI 的生成一起停掉
4. 自动打包	回编 → 对齐 → 签名 → 校验，产物在项目目录的 build 子目录里	回编是四步里最慢的一步（给足了 10 分钟）；对齐/签名/校验只是搬字节，各自 3 分钟上限就够
5. 装机验证	打包后可自动找设备、装包、拉起应用，并复核前台应用是不是它	装机后走一遍"改动点相关的最短路径"，别只看"能启动"

大包专属的三条经验

经验一：先用一个小改动把链路跑通。 拿到一个大包，别一上来就做最复杂的那个需求。先改一句文案、换一张图 —— 目的不是这个改动本身，而是用一个几分钟能跑完的循环，确认"导入、发送、等待、打包、装机"这五步在你的机器和这台设备上都是通的。链路通一次，后面就只剩内容问题。

经验二：改动按"能不能独立验证"来切，而不是按"功能大小"来切。 一个"加导出功能"的需求，如果拆成"加按钮但先只弹提示"和"接上导出逻辑"两轮，第二轮失败时你能确定问题在逻辑里；如果合成一轮，失败了你不知道是按钮没加上还是逻辑写错了。

经验三：善用历史记录做"重跑"。 每一次点「立刻修改」，需求原话都会记进项目历史（附件说明不进历史，历史里留的是你自己写的那句话）。详情页上每条历史右侧都有一个「选择」，把那条需求填回输入框 —— 想"照上次那条再改一遍"或者"在上一轮的基础上再加一句话"，比重新组织语言快得多。对动辄几十分钟的大包循环，这一点省下的不只是打字时间。

大包很吃磁盘，也很吃"环境完整性"

两个容易被忽略、但一旦踩到就会白等一轮的因素，正好都跟"大"有关。

一是磁盘空间。 一个项目目录里同时躺着：导入时的原始包副本、反编译出来的整个工程、以及 build 子目录里的三个中间产物（未签名、已对齐、已签名）。大包改造时，这几份加起来可能是原始包体积的好几倍。程序在启动时会自动挑盘：依次尝试 D、E、F、G，取第一个能读写且剩余空间不少于 1GB 的盘，都不行才退回 C 盘 —— 系统盘往往权限限制多，所以放在最后。想确认占用情况，可以在用户中心里看项目统计（项目数量、修改总次数、占用空间、所在磁盘剩余）；也可以把工作目录改到空间更充裕的盘上。

二是工具链完整性。 打包用的 java、apktool、对齐用的 zipalign、签名与校验用的 apksigner，任何一个缺失或损坏，表现都是"改完了却打不出包"。所以「参数设置」页里做了一次工具链体检：把这些组件逐个检查一遍，报出"是否就绪"和完整路径；不齐的时候点「立刻更新」，程序会自动下载并解压工具包，装完重新检测。养成习惯：换电脑、换工作目录之后，先看一眼这一页再开工 —— 这比在回编失败之后去翻日志快得多。

还有一个设计细节值得知道：打包进行中的窗口是不给关的。 这不是不信任你，恰恰相反 —— 它是为了防止"等了几十分钟，以为没在跑，顺手关掉重来"。四步流水线跑完，窗口上会给你「保存 APK」（默认文件名是"应用名_版本号_signed.apk"这种一眼能认出来的形式）和「打开所在文件夹」两个出口，产物从哪来、到哪去，都是明确的。

六、两个自家改包实例：从撞线到验证

下面两个例子都来自我们和身边团队的日常改包场景，用的都是自家应用、自家素材。重点看"以前怎么做、现在一句话怎么做、改完怎么验证"这三步。

实例一：给自家「仓储扫码」加一个导出按钮，结果回编撞了容量上限

以前的做法。 这个包的代码量不小，光 smali 就几万个文件。手工流程是：用反编译工具解开，在目标界面里找到那个位置，手写一段 smali 插进去，然后回编 —— 而回编这一步经常会以"装不下"告终。此时要做的判断是：是这次写错了，还是真的满了？只能一行行翻日志。确认是容量问题之后，还得手工找一个"可以被搬走"的包，在磁盘上建目录、一个文件一个文件地搬，搬完再回编、再签名、再装机。整套动作里，"搬目录"这一步纯体力，而且第一次做的人很容易搬错地方，比如把主界面相关的类顺手挪进第二个 dex，结果新机器正常、老机器打开就崩。

现在一句话怎么做。 把自家的安装包拖进安卓修改大师智改工坊，在需求框里写清楚要加的这个按钮和它的行为；AI 在工程目录里改完之后，主窗口检测到标志文件，自动弹打包窗口。如果回编这一步报出了容量相关的错误，就把这个现象连同处理方式写成第二轮的需求发出去："工程里单个 smali 目录已经装不下，请把 XX 相关的类整体挪进新建的 smali_classes2，保持包名路径不变，然后重新回编。"

改完怎么验证。 三件事：① 打包四步必须全绿 —— 尤其是最后一步签名校验，它会打印出证书信息，确认"真的签上了"；② 装机之后先走一遍"点新按钮 → 导出 → 结果正确"的最短路径，这一步验证的是这次改动本身；③ 再抽查两个与改动无关的老功能（例如首页加载、扫码）。第三件事看着多余，但它验的是"分包有没有把别的类带坏" —— 如果拆分过程中动到了不该动的类，这里会立刻露出来。如果这个包的最低支持版本低于 5.0，还要额外在一台低版本设备或用例上确认它能正常安装与启动。

实例二：内部「门店盘点」换应用名与启动页文案，重点在"确认没动结构"

以前的做法。 这个内部工具每次发内测版都要在应用名后面标一个"内测"字样，还要把启动页上那行版本提示改掉。按老流程，改应用名要去翻资源文件里的字符串，改启动页文案要确认那行字是写在布局里还是被写死在代码里 —— 两种情况处理方式不同。改完之后回编、签名、装机，最后人工确认"桌面上的名字变了、启动页那行字变了"。全程最让人不放心的不是改，而是"这个包本来就是多 dex 的，我这轮改动有没有动到分包结构" —— 以前这个问题只能靠"装上去看起来没事"来回答。

现在一句话怎么做。 一句话把两件事说清楚："把应用名改成『门店盘点 内测版』，并把启动页上那行版本提示改成新的文案，其他不要动。"改完照旧自动打包。因为是纯资源与文案层面的改动，这类需求通常一轮就过，中间不会碰到容量问题。

改完怎么验证。 除了"桌面名字对不对、启动页文案对不对"这种直接观察，还可以多做一步结构性确认：把刚打出来的包再拖进工具建一个新项目，看它的目录结构 —— 原来有几个 smali 目录，现在还是几个。这一步相当于"把成品再拆开检查一遍"，对多 dex 的包尤其值得做：它能直接回答"我这轮改动有没有改变包的结构"这个问题，而不是靠猜。确认完这个临时项目删掉即可（删除有防呆：只允许删项目目录的直接子目录）。

这两个例子里，"以前"的痛点其实分布在两个不同的位置：实例一痛在判断与搬迁（人工分辨报错、人工搬目录），实例二痛在确认（到底动没动结构，只能靠感觉）。而这两件事恰好都是"流程固定、判断标准明确"的活儿 —— 也正是最适合交给一条自动化链路 + 一句中文需求的活儿。

七、用户评价：他们被 65536 教育过之后

八、结语：把"容量问题"和"代码问题"分开看

把技术部分收成三句话：65536 是 dex 用 16 位下标寻址方法引用与字段引用的必然结果；multidex 把"一个 dex 装不下"变成"两个 dex 分开装"，而 smali_classesN 目录就是这套结构在工程里的样子；类放在哪个 dex 不影响它被调用，所以"搬目录"不需要改动一行调用。 使用部分也收成三句话：一轮只做一件事、别手工造标志文件、验证要看三层（签名、改动点、无关功能）。

于是你打开安卓修改大师智改工坊时，看到的还是那句口号描述的样子：只需说话，就能让应用变成你想要的样子 —— 拖入自家的包，用中文写清这一轮要改什么，剩下的反编译、等待、回编、对齐、签名、校验、装机，都交给这条流水线。容量撞线这类"看似可怕、其实有解"的问题，你要做的只是认出它、说清它。

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