改包也要看磁盘：自动挑盘、1GB 门槛与换盘注意

聊「改包」的时候，大家习惯讨论技术：smali 怎么改、资源怎么替、签名怎么过。很少有人把磁盘空间当成一个正经话题。但真正在命令行里翻过车的人都记得那种感觉——回编跑到 80%，报一句磁盘空间不足；签名即将完成，产物写不下来；或者更隐蔽的：磁盘看着还有几十 GB，但项目所在的那个盘刚好满了。

本文的主角是 安卓修改大师智改工坊，一款 Windows 桌面工具：把「改 APK」从技术活变成一句话——拖入安装包，用中文写需求，AI 改包，改完自动回编 / 对齐 / 签名 / 校验，一键装到手机或模拟器看效果。介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网 www.apkeditor.cn。这篇不重复讲它怎么改包，只讲它怎么处理「盘」这件事：怎么挑、怎么留、怎么换。

为什么值得单独写一篇？因为在手工流程里，磁盘问题是「事后才发现的意外」；而在一个把整条链路收进程序里的工具中，磁盘必须是「开工前就定好的前提」。这两者的差别，就是本文的全部内容。

一、为什么改包会和磁盘较劲

把「改一个包」拆成文件动作，你会发现它是一条不断把东西写到磁盘上的流水线：

1. 导入：程序把原始包拷一份进项目目录（source.apk），再解析出图标、应用名、包名、版本号、最低与目标 SDK、启动页，写进 config.ini。
2. 反编译：把包展开成一棵目录树——资源文件回来了，smali 也回来了，这些全部落在项目目录的 apktool 子目录里。
3. AI 改包：在展开出来的这棵树上改，改的是磁盘上的真实文件。
4. 回编：把树重新压回包（apktool b），产出第一份中间产物。
5. 对齐与签名：zipalign 出一份对齐产物，apksigner 再签出一份签名产物——到此为止，build 目录里已经有 unsigned.apk、aligned.apk、signed.apk 三份文件。
6. 校验与保存：apksigner verify 校验通过，你把它保存成「应用名_版本号_signed.apk」，再装到设备上。

这条线上有三类东西会同时压在磁盘上，值得先分清：

• 必留的：source.apk（导入时的原包拷贝）——体量与你的原包一致，是整个项目的起点，任何情况下都不该动。
• 会长的：apktool 目录（展开出来的资源与 smali）与 build 目录（unsigned / aligned / signed 三份产物）——它们随导入、反编译、打包的推进而出现，是空间占用里变化最大的一块。
• 几乎不占的：config.ini、history.ini、pack.log、ai_done.flag 这类文本与标记文件——它们记录的是信息，不是内容，别因为「删了省空间」的直觉误伤它们。

看这条线就知道：同一个包，在磁盘上至少同时存在「源包一份 + 展开的树一棵 + 中间产物三份 + 保存的成品一份」。手工流程里这些文件散落在桌面、下载目录和临时文件夹，你很难预判它们合起来会占多少；一旦所在盘吃紧，报错就出现在最不该出现的时刻——回编或签名跑到一半。

还有一个容易被忽略的对比：手工流程里，磁盘占用是「跟着你的习惯走」的。有人习惯把包放在下载文件夹，解包在三年前的旧目录，产物丢在桌面——于是同一件事的文件被撕成三份，哪一份都不敢删，因为你不知道删了会不会影响下一步；磁盘越来越满，清理却无从下手。而把链路收进一个程序之后，占用变成了「跟着项目走」的：一个项目的所有东西在一个目录里，删不删、删什么，判断依据是清楚的。

所以智改工坊把磁盘问题提前了：程序启动时自动挑盘，把「能不能写、写得下」这件事在开工前问一遍。这就是下一章那条挑盘规则。

二、自动挑盘：D → E → F → G → C，加一条 1GB 门槛

智改工坊启动时会自动挑盘，顺序是 D → E → F → G → C，取第一个「能读写」且「剩余空间不小于 1GB」的盘，然后拼成 <盘符>:\AiApkEditor 作为工作目录。这个规则很短，但每一个设计选择背后都有理由。

先说顺序：为什么 D 打头，C 垫底？在 Windows 上，C 盘是系统盘，里面同时住着系统、常用软件、各种缓存和你自己都没注意到的临时文件。把改包这种「会频繁读写大量中间文件」的活儿放在系统盘，短期你在挤占系统空间，长期你在和系统抢 IO。D、E、F、G 通常是数据盘或扩展盘，空间大、干扰少，把工作目录放在这里，是给整条链路找一个安静的地方。顺序里把 C 兜在最后，是因为总有可能遇到只有一块盘的机器——那时候能跑起来比什么都重要。

再说那条 1GB 门槛：为什么不能是「能写就行」？因为「能写」只是一个瞬间的判断，而改包是一个持续写入的过程。回到上一章那条清单：一个项目目录里同时在长着源包、展开的树、三份中间产物；展开的树往往比原包还大（资源被还原成原始文件、变成带格式的文本），三份中间产物又各自接近原包大小。挑盘时只看「现在能不能写」，等于把风险留给了「写到一半写不下」的时候。

1GB 这条线的意义，不是预测某个具体项目需要多少，而是把明显不够用的盘先排除掉。它的角色更像门口那道「请勿空腹入场」的提示：不保证你吃饱，但能挡住最糟糕的情况。真正的空间管理，还是要在使用过程中去做——这是第五章的内容。

工作目录定下来之后，它下面只有两个子目录：tools（java、aapt、apktool、7z、zipalign、apksigner 等，程序自动递归搜索，不需要你登记路径）和 Project（所有项目）。工具链本身也是要占地方的：如果检测到环境不齐，去「参数设置」页点「立刻更新」，程序会自动下载并解压工具包（7z 格式），装完重新检测——这也是把空间门槛定在 1GB 的原因之一，给工具链留位置。

挑盘还顺带决定了一件事的分工：重活放在哪块盘上。工具链（java、apktool 这些）与项目都在工作盘上跑，读写压力落在这一块盘；而诊断日志（吸附过程、打包过程）写在 %LocalAppData%\ApkGallary\dock.log，异常日志是 error.log——它们跟着 Windows 用户目录走，留在系统盘上。工作盘负责干活，系统盘负责留痕，两块盘各司其职，谁也不会把谁拖垮。这种分工不是理论洁癖：把几十上百 MB 的反编译产物来回读写放在系统盘上，在你同时开着一堆软件的时候，是真的会互相拖慢的。

自动挑盘是默认策略，不是强制约束：如果你对目录有自己的规矩（比如公司要求项目统一放在某个数据盘的固定位置），可以在「参数设置」页里指定工作目录。指定之后，「够不够用」这件事的判断权就回到你手上——自动挑盘帮你做的那道 1GB 检查，此时要靠你自己把关。

自动挑盘的价值不在「省了你去选目录的那 10 秒」，而在于它把「这个盘够不够用」从使用中的意外，变成了开工前的检查。

三、一个项目到底占多少地方

「1GB 够吗」这个问题，取决于一个项目占多少。与其给一个笼统的数字，不如把一个项目目录里会长的东西列清楚——知道了构成，你就能对着自己的包估算。

看懂这张表，两个结论就出来了。第一，项目占用通常明显大于原包：源包要留、展开的树要留、产物还要留，一个 12MB 的包对应的项目目录，往往不是 12MB 而是几十 MB 量级。第二，「删产物」和「删项目」是两码事：signed.apk 是成果，其他的中间产物在出包成功之后属于可清理对象；而整个项目目录要不要删，取决于你还要不要回看这个包的历史。

顺便说一个让人安心的细节：实测 12MB 的包反编译大约 3 秒，超过 10 分钟会中断并报错。速度上的这个体感，反过来也是空间友好的——你不需要为了等结果而同时堆很多个半成品项目，一个包从导入到出结果很快，磁盘上的「在制品」自然就少。至于清理的时机和边界，下一章和第五章会给出具体做法。

还有一类情况，让「源包已经落地」这件事的价值变得特别直观：反编译失败不影响项目本身。配置、图标、源包三样在导入时就已经写好，程序会提示失败原因并给出日志路径（apktool.log）。也就是说，就算某一次反编译没成功，这个项目在磁盘上依然是一个「有源包、有配置」的完整项目，而不是一堆需要你善后的残骸。另外，分包 apks、加密包、以及 jar / class 这类解析不出包信息的文件，会以文件名继续建项目，并在页面上给一句说明——它们同样会占空间，也同样有源包落地，心里有数即可。

量级感建立起来之后，你就能理解 1GB 这个门槛的定位了：它大致是「工具链 + 若干个项目起步」的量级，而不是「随便玩多久都够」的承诺。想随时掌握自己用了多少，用户中心里有一组现成的数字：项目数量、修改总次数、占用空间、所在磁盘剩余——不用自己去文件夹里加加减减，看一眼就知道该不该收拾。

顺着这张图再说一个归档习惯：出包成功、装机验证没问题之后，把 signed.apk 另存到你的归档目录（比如按「应用名+日期」建文件夹），然后这个项目目录里真正必须长期保留的就是两样——source.apk 和 signed.apk。剩下可回收的部分，等这个包不再需要反复改的时候，用项目列表的删除功能整体收拾掉即可；删除带防呆，只允许删 Project 的直接子目录，你不用担心手滑点到别处。归档再干净一点的做法是：保存 APK 时用默认名「应用名_版本号_signed.apk」，归档目录里按文件名一排，谁是谁一目了然——这也是给未来的自己省事。

四、换工作目录之后，四件必须确认的事

会用到「换盘」的场景不少：原来的盘快满了、换了新硬盘、公司统一了目录规范、或者你一开始没在意，让程序落在了 C 盘，现在想把工作区迁到 D 盘。工作目录可以在「参数设置」页里改。但换工作目录不是改一个输入框那么轻——它意味着「你接下来的材料都放在新的地方」，有四件事值得在换完之后立刻确认。

另外可以放心的是：诊断日志不在工作目录里。吸附过程与打包过程的日志写在 %LocalAppData%\ApkGallary\dock.log，异常日志是 error.log。它们跟着 Windows 用户目录走，换盘不影响排查问题的入口——出状况时该去哪找日志，不会因为换了盘而改变。

如果你不想每次换环境都重新配一遍，还有一层「参数级」的稳定：settings.ini 里可以改两窗口宽度合计占屏比例、间隙、轮询间隔、最小宽高、启动是否吸附、退出是否关闭被吸附程序等。它和盘符无关，但和「换了一台机器之后手感是否一致」有关。把它一起带上，换盘之后的体验才是平移，而不是重来。

五、两个自有应用的磁盘实战

把上面的规则落到具体动作上，看两个例子。两个例子都发生在自家的应用上：一个是公司自用的门店打卡应用，一个是内部培训应用。

换盘的完整标准不是「路径改好了」，而是「新盘上能照常出一个包」：工具链就绪、密钥就位、项目可读、出包可装——四项都过，才算搬完。

三个例子合在一起，其实就是一句话：磁盘不是「改完之后才需要面对的问题」，而是「改之前就该安排好的条件」。挑盘安排入口，门槛安排余量，清理安排出口——三件事都做完，改包的过程中就不该再遇到「写不进去」这种事。

六、用户怎么说・合规提醒与结语

磁盘这件事很「底层」，但用过的人对它的感受往往很直接。下面这些反馈来自不同角色的使用者。

把全文收一下。磁盘这件事，在改包链路里扮演的是「地基」的角色：地基不牢，上面做得再漂亮都会在某个时刻塌掉，而且往往塌在最后一步。自动挑盘解决「在哪干活」，1GB 门槛解决「够不够起步」，项目目录的空间构成解决「怎么估算与清理」，换盘清单解决「搬家之后还跑不跑得起来」。四件事都不难，难的是把它们从「事后补救」变成「开工前完成」。

回到开头那句主标语——改包先看盘：空间留够，链路才顺。这不是一句吓唬人的话，而是把失败概率往下压的一种习惯：让回编、对齐、签名、校验这四步永远有地方落盘，你才有资格去关心「改得像不像」。顺手提醒一句，第一次上手时先去「参数设置」页跑一次工具链体检，再顺手看一眼工作目录落在哪个盘、还剩多少空间——两个动作加起来不到一分钟。

产品是安卓修改大师智改工坊，介绍页：https://www.apkeditor.cn/ai-version.aspx；官网 www.apkeditor.cn。