多项目并行的目录与磁盘策略：从挑盘规则到缓存清理的一份整理手册

先把对象说清楚。安卓修改大师智改工坊是一款 Windows 桌面工具：把自家的 APK 拖进去，用中文写一句需求，AI 改 smali 与资源，改完自动回编、对齐、签名、校验，再一键装到手机或模拟器上看效果。它的介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

这篇文章不谈怎么改包，谈改包这件事在地面上留下的痕迹：文件放在哪、盘是怎么选的、缓存攒在哪、什么时候该清、项目多了以后怎么收拾。这些问题在只改一个包的时候全都不是问题 —— 反正只有一个目录；但只要同时开工两个包，或者连续做了几周，它们就会以"我那个包呢""盘怎么满了""这个文件能不能删"的形式一件件冒出来。

我们把它拆成四层来写：项目层（一个项目一个目录，里面有什么）、磁盘层（D → E → F → G → C 的挑盘规则与它的副作用）、缓存层（download、框架缓存与本地配置分别在哪、删与不删的代价）、整理层（项目多起来之后的一套动作）。每一层都给出可以直接照做的建议，最后配两个自家应用的改包实例。

一、并行改包的第一个坑：不是改得慢，是文件互相踩

先说一个很典型的翻车现场。手上有两件事：给自家的记账应用换图标，给内部的巡检工具换启动页。两个包都不大，于是顺手都解到同一个工作文件夹里：work\ 下面既有记账应用的 smali 和资源，也有巡检工具的解包结果，旁边还堆着几个中间产物、两个源包、一份"最终版"和一份"最终版2"。接下来会发生什么，几乎是可以预演的：

• 打包打错对象：回编命令指向的那个目录里，装着的是另一个包的内容 —— 或者更糟，是两者的混合。打出来的包"看起来是对的"，装上才发现改的是另一个应用。
• 改动无法归属："这个图标是谁改的、哪句需求改出来的"，翻遍文件夹也说不清，因为需求记录在别处，文件堆在一起。
• 回滚没有底牌：源包早就被覆盖或改名，想退回原始状态只能重新找人要一份安装包。
• 误删与误改：清理中间产物时删掉了别人的解包目录，或者手一抖把新做的资源覆盖掉。

这些问题的共同点是：它们不是"改包技术"的问题，而是"文件组织"的问题。 一个包在工作过程中会产生大量中间文件（反编译出来的代码、资源、日志、多个打包阶段的产物），它们天然需要被聚拢在一起、并且和别的包的东西严格分开。所以智改工坊在设计上做的第一件事，就是给每一个项目分配一个专属的工作目录。

这个目录名是一串 8 位随机小写字母加数字（例如 k3f9v2qa），由程序在创建项目时随机生成，创建前还会检查重名、避免撞车。第一次见到这个名字的人往往会问：为什么不用"记账助手"这种一看就懂的名字？理由有三条，都挺实在：

1. 应用名会变。改包这件事本身就经常改名字（"巡检打卡"改成"巡检打卡 内测版"），如果目录名跟着应用名走，改一次名目录就变一次，路径、历史、日志里记的东西全要跟着动。
2. 名字要能随便改。项目名是给人看的，放在项目配置里，你想改成什么就改成什么，不影响目录、不影响已有的修改历史 —— 两者解耦，改动才不会互相牵制。
3. 随机名天然不冲突。八个字符的随机串，配合创建前的重名检查，几乎不可能撞上；即便你手工从别的机器拷一个项目进来，也不会因为同名而覆盖掉本地的项目。

落地到日常使用上，这套设计带来的第一个好处是"并行无感"：两个包同时在改，你在项目列表里切来切去，每个项目各自的解包目录、各自的修改历史、各自的打包产物都待在自己的目录里，互不影响、互不覆盖。把 A 项目删掉，B 项目连文件都不会少一个。

二、项目目录解剖：一个随机名字里到底有什么

既然每个项目都是一个独立目录，那这个目录里到底存了什么，就决定了"哪些东西可以放心删、哪些删了就得付出代价"。下面这张表按"文件 / 目录"逐个说明，建议对照你自己的项目目录看一遍 —— 看完你就有了一个稳定的心智模型：这个目录是那个包从导入到出包的全部现场。

名字	是什么	删了的后果
config.ini	项目配置：应用名、包名、版本、最低与目标 SDK、启动页、图标文件名、原始包文件名等	项目列表里这一条会消失（列表就是靠它认项目的）
history.ini	修改历史：按"记录 1、记录 2…"递增，每条存时间与你写的需求原话	历史清空；但它是可手工编辑的明文，删某一条只需删对应那一节
icon.png（扩展名随原格式）	从原包里取出的图标原图（按最高密度挑的那一张）	列表里变成无图；不影响改包与打包
source.apk	导入时的原始包副本 —— 改坏了的底牌	失去最干净的回滚起点，只能重新去找原始包
apktool\	反编译出来的工程（清单、smali、res…），既是 AI 改动的现场，也是回编的输入	没法回编，得重新反编译一遍（实测中等大小的包约几秒，大包可能几分钟）
apktool.log	反编译的完整输出	包解不开时少了一份第一手线索
pack.log	每次打包的全过程（四条命令逐条记）	出包异常时少了一份可追溯的账
build\	打包产物：未签名、已对齐、已签名三个包	中间产物而已，重新打包就有（但要留归档请先另存）
ai_done.flag	临时标志：AI 改完写一个，主窗口读到就删（读完即删）	没什么后果；平时本来就不该看到它

这张表里最值得划重点的是 source.apk。它看起来只是一个"备份"，但它的价值在出问题的那一刻才显现：改坏了想从头来，不需要向任何人再要一次原始安装包 —— 直接以这个副本重新建一个项目，就是一个完全干净的起点。这也顺带解释了工具的一个设计取舍：反编译失败不会让项目创建失败。配置、图标、原始包副本在创建项目时就已经落地，反编译只是后一步；哪怕这一步失败，项目本身照样在列表里，日志里也写着原因，你可以补装工具之后再来一次。对并行改包的人来说，这意味着"项目一旦建下，就是个能兜底的存在"。

另外两个小细节也一起说了：config.ini 是带注释的明文，手工改完到项目列表点一下刷新就生效 —— 想给项目改个更清楚的名字，改这里就行；history.ini 同样是明文，按记录递增，想删掉某一条历史，把那一节删掉即可。这两个文件都保留了"人能直接读懂、能直接动手"的性质，这对长期维护一个项目目录非常重要。

还有一个和"清理"直接相关的设计细节：反编译输出的那个子目录名字是固定的，而程序在往里写之前会先清掉同名目录、再完整解一遍。也就是说，这个目录里永远只代表"最近一次反编译的结果"，不会出现新旧文件掺在一起、看不出哪份是这次的状况。反过来说也要记住：如果你手工往里面放过东西（比如自己动手改了某个资源），下一次反编译一来它就会被清掉 —— 手改的内容要么当场打包出包，要么自己先另存一份。

三、工作目录：D → E → F → G → C 的挑盘规则与两个子目录的分工

项目放哪，由"工作目录"决定。工作目录的挑选是程序启动时自动完成的，规则写得很直白：按 D、E、F、G 的顺序依次检查，取第一个"能用"的盘，拼成 <盘符>:\AiApkEditor；四个都不行，才退回 C 盘。 这套规则里有两处设计值得展开，因为它们直接解释了你见过的很多现象。

那 1GB 这个门槛是怎么来的？因为工作目录不只是"放项目的地方"，它还是工具链的家：解压一套 java 环境加 apktool、aapt、对齐与签名工具，是几百 MB 的量级。如果挑了一个只剩几十兆的盘，工具包解压到一半失败，留下半套环境，比一开始就换盘麻烦得多。所以挑盘时留出的余量，本质上是给"第一套工具"预留的地。

这套规则有一个必须提前知道的副作用：工作目录会漂移。 设想一个很常见的真实序列：某天 C 盘快满了，D 盘空间充裕，于是工作目录落在 D:\AiApkEditor，你在这里做了十几个项目；后来 D 盘被别的软件（或你自己的中间文件）填到只剩不到 1GB，下一次启动，程序判定 D 不可用，改在 E:\AiApkEditor 建立了新的工作目录 —— 于是项目列表"空了"，你之前所有的项目都不在列表里。它们并没有被删除，只是列表读的是当前工作目录，而当前工作目录换了一个盘。

"项目不见了"的绝大多数情况，都不是数据丢了，而是工作目录换了。第一反应不要去重装、不要急着重下工具 —— 先看清当前工作目录是哪个盘，再去那个老位置找项目目录。

解决办法也很简单，而且是一劳永逸的：到「参数设置」页把工作目录保存一次。 保存之后，程序会记住你指定的路径，不再每次自动挑盘。什么时候该固定？我们的建议是：只要你开始"连续做项目"就该固定。挑盘的初衷是让新用户第一次打开就能用，而不是让你每次开机都在赌这次落在哪个盘。换机器、插拔移动硬盘这一类动作都可能改变盘序与可用盘，固定之后这些变化就与你无关了。

还有一个容易忽略的连带事实：工作目录同时也是工具链的定位根。 程序会在工作目录下按固定名字找两个子目录 —— tools（工具）与 Project（项目）。所以"换工作目录"从来不只是换个文件夹：你必须把这两样东西一起带过去，或者在新位置重新准备一份工具链。这也是下一节的主题。

tools 与 Project：工具链与项目的分工

工作目录下面固定是两个子目录，这个"只有两层"的结构是刻意保持简单的：

子目录	放什么	换根目录时要一起带走吗
tools	java 环境、aapt、apktool、对齐与签名工具，以及 adb 与投屏程序等，按各自目录层层放着	要。否则新位置什么也干不了，只能重新装一套
Project	所有项目，每个项目一个 8 位随机名字的子目录	要。这就是你的全部工作与历史

工具是"怎么被找到"的，这里有一个值得知道的设计：程序不依赖任何登记表，而是直接在里面找。它先试几个约定位置（工具目录本身，以及其中若干常见子目录），找不到再在整个工具目录里做一次有上限的递归遍历。这样做的好处是"换个版本不用重新配置"：你把 apktool 的 jar 换成新版本、把 java 目录整个搬了个位置，程序照样能认出来 —— 甚至当目录里同时存在好几个版本的 apktool 时，它会挑版本号最高的那一个用；java 也是同样的思路，优先选更像"完整 JDK"的那一份，其次才比路径。

与之配套的是「参数设置」页里的工具链体检：它会逐个报出 java、aapt、apktool、对齐工具、签名工具这些组件"找到了没有、完整路径是什么"。这个页面对并行项目的人特别有用 —— 因为并行意味着你在不同时间点开几个项目、有时隔了几周，环境是不是还完整，看一眼比翻日志快得多。环境不齐时的标准动作也很清楚：点「立刻更新」自动下载并解压工具包（服务端下发的工具包是 7z 格式，解压由跟程序一起打包的那份 7z 负责，不需要你系统里另装一个），装完程序会重新检测一遍环境。

最后提醒一个"看不见的成员"：打包用的签名密钥就放在工作目录根下（两个密钥文件，一个私钥一个证书）。它不属于 tools 也不属于某个项目，是这一整套环境的公共资产 —— 这带来两个推论：一是换工作目录时它也要一起考虑（否则新位置打不了包）；二是团队里想让所有内测包都签成同一把密钥，替换这两个文件即可，换完之后所有新出的包就统一了。

四、缓存地图：攒在哪儿、哪些能删、删了亏什么

"能不能删"这个问题，答案取决于文件是谁写的、删了之后谁要重做。下面是并行工作里最常遇到的一批位置，全部列出来对照着看：

位置	是什么	删了会怎样
<工作目录>\download\	工具包的下载缓存：下过一次就留在这里，不重复下载	可以删。代价：下次更新工具环境要重新下载一遍
<工作目录>\tools\	工具链本体（java、apktool、aapt、对齐与签名、adb 等）	删了反编译与打包全部不可用，要用「立刻更新」重装一套
<工作目录>\Project\	项目与全部历史 —— 你的工作成果	按需清理单个项目；整目录删除前先确认没有要留的
%LocalAppData%\apktool\framework	apktool 自己的框架缓存；攒着它，再解同类包会明显快一些	可以删。代价：下次解同类包要重新生成缓存，会变慢
%LocalAppData%\ApkGallary\	诊断日志（吸附过程、异常记录）、登录缓存、本地头像	日志可删（代价是历史问题没法回溯）；登录缓存删了要重新登录
项目里的两份日志	反编译日志与打包日志，各自记录那一步的完整输出	可以删。代价：这一项目的排障线索没了

这张表里最反直觉的一行，是 apktool 的框架缓存放在系统盘的当前用户目录下，而不是工作目录里。也就是说：就算你把工作目录整个安排到了 D 盘，这个缓存依然在 C 盘的用户目录里长大 —— 清理 C 盘时看到它，不要当成"陌生文件"删掉，它的存在正是"第二次解包比第一次快"的原因。反过来说，如果你的 C 盘确实紧张，删掉它也不会有任何功能损坏，只是下次解同类包要重新付出生成缓存的那点时间。

还有一类"缓存"是项目目录里的临时标志文件：AI 改完之后会写一个固定名字的标志文件通知主窗口，主窗口每 2 秒看一次，读到就立刻删掉、然后弹打包窗口。它平时在你手工查看目录时基本见不到；如果你在目录里看到了它，多半意味着某一轮流程没有走完（例如等待被中途取消了）。它本身没有任何副作用，删掉也不会影响任何东西。

五、磁盘空间：占用从哪来、怎么算、怎么省

并行项目多了以后，"盘在悄悄变满"几乎一定会发生。要控制它，先要知道占用长什么样。一个项目的体积主要由三块构成：原始包副本（和你的安装包一样大）、反编译工程（解出来的代码与资源，通常比原包更大）、打包产物（未签名、已对齐、已签名三个包都会留在 build 目录里）。三块加起来，一个项目的占用很容易达到"原包体积的好几倍"；项目一多，总量就上去了。

这些数字不需要你去资源管理器里一层层算 —— 「用户中心」里有一组统计：项目数量、修改总次数、项目占用空间、所在磁盘剩余空间。它的设计里有一个体贴的细节：算这些要遍历项目目录、逐个读历史文件，是实打实的磁盘活儿，所以它在后台算完再回填到界面上，不会让界面卡住；想立刻重算，点一下刷新即可。用途很直接：看到"占用空间"和"磁盘剩余"两个数一起涨涨落落，你就知道该不该动手收拾了。

真到要腾空间的时候，我们建议按这个顺序做，代价从低到高：

1. 删各项目 build 目录里的中间产物：未签名包与已对齐包都是过程文件，下一次打包都会重新生成；已签名包如果已经另存归档，也可以删。这一步通常回收最多、损失最小。
2. 清理不再需要的项目：用项目列表的搜索框先筛一遍，确认没有价值再删。删除有防呆：只允许删项目目录的直接子目录，路径被人改坏也不会出现"删掉整块盘"这种事。
3. 删掉 download 里的旧工具包：省下的空间有限，但确实是纯缓存；代价只是万一要重装工具时重新下一次。
4. 换盘：把 Project 与 tools 一起挪到空间更大的盘，再到「参数设置」里把工作目录指向新位置。这是"搬家"，不是"清理"，两样东西必须一起走。

清理之前，有两个"确认"值得养成习惯。一是确认这一版已经另存：build 里的已签名包会被下一次打包整体覆盖，所以"删未签名包与已对齐包"随便删，但没有存档的那一版签名包，删之前先看一眼是不是已经另存过。二是确认项目真的不要了：删项目会连同原始包副本与全部修改历史一起删掉，而这两样恰恰是"反悔"时最需要的东西；拿不准的项目先别急着删，把它移出 Project 目录冷处理一周，再决定。至于"到底占了多少"，除了用户中心那两个数字，你也可以直接在资源管理器里查看 Project 目录的属性 —— 两种口径本来就是一回事，统计的来源就是这个目录。

关于"删除"，还有一条值得知道的边界：项目列表是直接读磁盘的 —— 你把一个项目目录用资源管理器整个拷进 Project 目录，点一下刷新就能看到它；反过来，把一个项目目录移出 Project，它就不在列表里了（文件还在，只是不再被列为项目）。这个特性是很多整理动作的基础，下一节展开讲。

"项目多起来之后"的整理建议

下面这套动作是我们自己在项目堆积起来之后慢慢固定下来的，按"做一次就能受益很久"的顺序排列：

"整理"里最容易做错的三件事

第一件：把 build 目录当版本库。 build 里那三个包是"这一次打包的产物"，下一次打包会整体刷新。有人习惯每打一版就留在原处、靠改文件名区分，几轮之后目录里全是"最终版""最终版 2"，而真正需要留住的那一版，很可能已经被下一次打包覆盖掉了。正确的姿势只有一句：要留的版本，打包完立刻另存到项目外面去。

第二件：在 Project 下面再分一层"分类文件夹"。 项目列表是按"直接子目录"来认项目的 —— 你在 Project 下建一个以年份命名的分类目录，再把项目放进去，这些项目就不会出现在列表里了，因为它们的位置深了一层。要归档，就把项目整个移出 Project、移到你自己的归档位置；"分类"这件事交给项目名与列表里的搜索框来完成，比目录层级可靠得多。

第三件：把工作目录当成"随便拷一部分就能复原"的东西。 工作目录里同时住着项目、工具链和打包签名密钥。换机器时只拷了 Project 目录，会得到一个"项目都在、但一个都打不了包"的局面 —— 缺的是 tools 与那两个密钥文件。迁移的正确做法是把整个工作目录搬过去；或者在新机器上先用「立刻更新」装好一套工具环境，再把 Project 放进去。

这份清单的共同逻辑只有一句：把"随手的"变成"定期的"。 并行的代价本来就是"东西变多"，而变多本身不可怕 —— 可怕的是等到盘满了、项目找不到了、某一份包被覆盖了，才被动地去翻。这些事情每一件都只要两分钟，但挑着时间做，收益是持续的。

六、两个自家改包实例：这套目录策略到底帮了什么

照例说明：下面两个例子改的都是自家应用与内部工具，素材也是我们自己的。

实例一：两个包同时改 —— 一次典型的并行。

需求来得很急：自家「记账助手」安卓版要换图标，公司内部「巡检打卡」工具要换启动页背景图，两件事都要当天出包。以前的做法是"一个工作文件夹走天下"：把这个包解到 work\ 下，改完打包，产物改名存到桌面；再清掉这个目录、解第二个包。一旦两件事交叉（等素材、等确认），就要时刻小心"现在目录里躺着的是哪个包"；而且改到一半被叫去处理另一个，回来常常要先花几分钟辨认现场。需求说了什么、改到了第几版，全靠脑子记或者翻聊天记录。

现在两个包分别建项目，各自落在自己的 8 位随机目录里。记账应用那句需求是"把应用图标换成附件里的新 logo"，巡检工具那句是"把启动页背景图换成附件里这张新版宣传图，保持原来的显示比例"，两张图分别作为附件写清用途后各发各的。改完之后，两个项目各自的修改历史里各有一条记录，时间、原文、附件说明都在；打包时也是各打各的，产物各在各的 build 目录里，连打包日志都是分开的两份。整个过程里我们唯一需要操心的"文件问题"，变成了"最后把两个另存出来的签名包发给对应的人"。

改完怎么验证？两个包都先在自己的模拟器上过了一遍（图标在桌面上是否生效、启动页比例是否被裁），然后用打包后的自动运行装到真机看了一次。因为项目没混，验证时也没有出现过"装了才发现装的是另一个包"这种尴尬。

实例二：D 盘满了，项目"消失"了一次 —— 一次真实的挑盘副作用。

这是个我们自己踩过的坑，非常值得写出来。当时 D 盘还宽裕，工作目录落在 D:\AiApkEditor，前后做了十几个项目。后来 D 盘被一批视频素材塞到只剩几百兆，某天打开工具，发现项目列表几乎是空的，当时第一反应是"项目被删了？"—— 冷静下来才想通：启动时 D 盘没通过"剩余空间不少于 1GB"这一条，程序按规则换到了 E 盘，新建了 E:\AiApkEditor，而项目列表读的是当前工作目录。项目一个都没丢，全在 D 盘上原地待着。

处理分两步：先把 D 盘清理出足够空间，然后在「参数设置」里把工作目录明确保存成 D 盘的那个路径，从此不再自动挑盘；顺手把 E 盘那个刚生成的新工作目录删掉，把它顺手建出来的 tools 也一并清掉。做完之后再打开，十来个项目全都回来了，历史记录一条不少。这次经历换来一条写进我们团队手册的经验：只要你打算长期用这套工具，就在第一次进「参数设置」时把工作目录固定下来。 挑盘机制是为了让新用户开箱即用，而不是让人每次开机都赌一次盘序。

顺带一提，这次经历也让我们第一次认真看了「用户中心」的那几个统计数字 —— 现在团队里的习惯是：谁发现盘紧张了，就在群里说一声，大家各自清一次 build 中间产物，通常一晚上就能回收出可观的空间。

实例三：一个包改坏了，靠项目里的原始副本重来。

有一次给内部「巡检打卡」工具换启动页背景图，改完装到测试机上才发现：返回上一级的那个按钮点不动了 —— 大概率是那一轮改动波及了某个资源。以前遇到这种情况，处理流程相当磨人：先得找"这个包的原始版本在哪"，它可能在同事的聊天记录里、可能在某个下载文件夹里、也可能只剩一个已经改过好几轮的版本；找到之后重新解包、重新描述需求、重新改一遍，而"上一轮到底改了哪些地方"其实谁都说不清。

现在的处理只有三步：先确认问题（拿着手机复现一次，记下是哪一步不行、什么机型、什么系统版本），然后用项目目录里的 source.apk 重新建一个项目 —— 那是导入时留下的原始副本，和当初那份安装包一模一样；最后把当时那条需求从项目的修改历史里"选择"出来，微调一下措辞（把启动页那张图再附一次）重新提一次。改完照常打包、装机验证，前后花的时间不到原来"找包"环节的一半。事后回看，真正省事的不是"重做"这个动作，而是起点是确定的：不是"某一份改过几轮的包"，而是"这件事最原始的样子"。

七、用户评价：他们在目录与磁盘上踩过的坑

下面这些是内部试用与技术交流群里关于"文件与盘"的交流整理 —— 这类话题的重复率出奇地高，说明它确实值得单独讲一篇。

八、结语：目录清晰了，并行才真正成立

把这篇文章收成几句话：一个项目一个随机目录解决了并行改包的隔离问题；D → E → F → G → C 加四项判据解决了"工程放哪"的自动决策，代价是可能漂移，固定一次即可；tools 与 Project 两层结构让工具链与项目各得其所，搬迁时记得一起走；缓存分布在三处（工作目录的下载缓存、系统盘的框架缓存、项目内的日志），删与不删各自的代价也都写清楚了；整理靠定期动作而不是临时翻找。

于是你打开安卓修改大师智改工坊时，流程就是那句口号描述的样子：只需说话，就能让应用变成你想要的样子 —— 需求写一句、附件拖一张，改完自动回编、对齐、签名、校验，一键装机看效果；而项目、工具、缓存这些"地面上的事"，现在你手里也有一张地图了。

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