这里是安卓修改大师智改工坊。你可以先打开 https://www.apkeditor.cn/ai-version.aspx 看看产品形态，再回到这篇文章。本文不聊玄学，只聊两件能立刻验证的事：一个自家应用凭什么能变小，一个自家应用凭什么能启动得更快。涉及的机制、指令和边界，都来自工具里真实存在的资源与话术，不编造不存在的功能。

自家应用的「体重」：从安装包到冷启动的三个数字

一个应用的体积不会一夜之间涨上去。它是一年一年加上去的：设计同学要高清图，于是多了一套 xxxhdpi；运营同学要海外版，于是多了 values-en、values-ja 两套语言；开发同学接了三家第三方 SDK，于是 lib 目录下多出了四个架构的原生库。每一次都合理，加起来就变成一个没人愿意下载的安装包。

内部工具尤其明显。它们没有专门的人管体积，理由通常很朴素——"反正只在自己人手机里"。可内部工具的分发场景恰恰最苛刻：仓库老师傅的手机是三年前的中端机，点安装之前先看一眼包有多大；车间平板的存储常年只剩几百兆；群里发安装包的时候，超过某个大小就会被聊天工具拒绝或者压缩传输。体积这件事，在办公室的电脑上感觉不到，在一线手机上天天都能感觉到。

启动速度是第二个数字。冷启动到首页的时间大致由三部分决定：系统加载与 dex 校验、启动页停留、启动期要等的数据。前两项跟包体大小直接相关，第三项跟代码写法相关。很多内部应用卡在第三项上：启动页里做了一次同步的网络请求，网络一差就白屏好几秒，用户第一反应是"这应用坏了"，第二反应是"以后不点了"。

第三个数字是安装后占用。它比安装包大得多，因为解压、dex 优化、缓存都会占空间。把多余的语言目录和高密度图片收掉之后，安装包和安装后占用会一起下降。对存储紧张的老设备来说，后者往往比前者更重要。

改体积和改启动，目标不是"做到最小"，而是"把明显浪费的部分去掉，同时不牺牲功能"。一个内部工具削掉四成体积、把冷启动压进三秒以内，就已经解决了分发和抱怨这两件最现实的事。

先看清包里装了什么：资源与代码的四个角落

反编译之后，apktool 目录里能看到一个包的骨架。要动体积和启动，先得知道东西分别放在哪几个角落。不看结构就动手，等于闭着眼睛搬家。

拖入 APK 之后，智能修改电脑版会先用工作目录里的 aapt 解析图标、应用名、包名、版本、最低与目标 SDK、启动页。这一步给出的"现状"很重要：你会在界面上第一次清楚地看到，自己的应用名到底是什么、图标有几套密度、最低支持到哪个系统版本。改之前先看清现状，是这类改动不出错的前提。

图标那里有一个细节值得知道：aapt 报出的密度里，65534 表示"任意密度"，它是一个哨兵值，不是真的密度等级，不能拿去和常规密度比大小。工具只认正常范围内的密度档，取其中最高的那张原图，所以你在界面上看到的是清晰的原图，而不是被放大的低密度图。做体积优化时这一点尤其重要——你得先确定"当前用的是哪一张"，才知道该动哪几张。

每个项目会在工作目录的 Project 下建一个 8 位随机名的目录，里面写 config.ini、history.ini，复制一份 source.apk，反编译产物放在 apktool 目录，日志写进 apktool.log。这个目录是整件事的档案袋，也是唯一的回退入口。后面所有关于"改坏了怎么办"的问题，答案都在这里：原始包在，配置在，历史在，产物在。

在动手之前，建议先留一份体积基线。做法很土但很有效：把安装包字节数、资源目录大小、原生库目录大小、assets 目录大小、冷启动耗时五项抄进一张表，改完再抄一遍。没有基线，"好像小了点"就永远是感觉；有了基线，哪一块省了多少、哪一块反而涨了，一眼就能看出来。体积优化最容易犯的错，是改了半天却说不出收益来自哪里。

另外提醒一下工作目录的选择。反编译、回编、对齐、签名都要在磁盘上落临时文件，工作目录建议放在可用空间充足的盘上；空间不够时，回编阶段可能在中途失败，日志里给出的原因也不一定直观。先把空间留够，能避免一类很难排查的失败。

12 MB 左右的包，实测反编译大约 3 秒；如果超过 10 分钟还没结束，工具会中断并报错，不会让你对着一个假死的界面一直等。反编译失败也不会毁掉项目本身：配置、图标、源包都已经落地，日志里会写清原因和路径。做体积优化时你可能会连续改好几轮，这种"每一轮都有干净起点"的设计，比什么都重要。

资源侧第一刀：图片转 WebP 的正确姿势

图片是安装包里最容易瘦的一块，原因很直接：同一张图往往以四五个密度各存一份，PNG 又是无损格式，一张两百多 KB 的背景图乘以五套密度就是一兆多。把格式换掉、把多余密度收掉，收益来得最快。

好消息是这件事不需要你自己写指令。话术库「常规修改」类里就有一条成型指令叫"图片转WebP"，点一下就能填进需求框。它按改动范围分了几个方向：drawable 位图资源、assets 内置图片、启动页与背景图、图标与表情图、图片资源引用；每个方向下面还有四档强度，分别适合不同的心态。

这条指令的参数是写好的，值得照着核对：有损质量 85，带透明通道的图用无损 WebP 并保留 alpha，照片类用有损；覆盖率上只处理 100 KB 以上的图片，体积目标降低 40%。为什么设 100 KB 这条线？因为小图转换格式的收益很小，反而增加风险与工作量；把火力集中在大图上，性价比最高。这也是一条通用的优化经验：先动大头，再谈细节。

为什么透明通道要单独对待？因为图标、按钮底图、圆角遮罩这类图依赖 alpha 通道，用有损压缩容易出现边缘发灰、半透明处出杂边，放大看就是一圈脏边。而照片、横幅这类没有透明需求的大图，用有损质量 85 基本看不出差别。这条区分不是抠细节，而是决定"改完之后要不要返工"。

有一条边界必须提前知道：不同版本的 Android 系统对 WebP 的支持不一样。老系统上如果遇到不认识的格式，界面可能直接不显示图。所以这条指令里特意要求"留一张兜底图"，验收标准也写清了——浅色与深色系统主题下都要显示正常，没有看不清的文字。把验收标准写在需求里，比事后靠眼睛判断靠谱。

还有一条容易被忽略：转换之后资源名与引用要同步。图片从一种格式变成另一种格式，文件名、资源表条目、布局里的引用、清单里的资源名，都要一起改。少改一处，回编阶段就会报"找不到资源"，或者更麻烦——编译通过了，运行时那块区域显示空白。指令里"同步更新资源引用与清单里的资源名"这半句，就是为这件事写的。

1. 拖入并确认。把 APK 拖进智能修改电脑版，等 aapt 解析完，确认包名、版本与启动页信息都对。
2. 选指令。打开详情页，在话术库里选「常规修改」→ 图片转WebP，先选一个方向；第一次建议用"保持兼容"或"全局统一"。
3. 补三句自己的话。这次只处理哪些目录、哪些图必须保持无损、体积目标是多少。
4. 给附件。如果手里有"哪些图必须原样保留"的清单，作为附件传上去，用途写清不少于 10 个字。
5. 点立刻修改。需求原文与日期会写进 history.ini，之后可以在详情页的历史里回看。

附件系统在这里很好用。一次可以多选文件，每个文件都要写一句它是干什么用的，而且不能少于 10 个字；发送前会校验文件是否存在、是不是目录、是不是 0 字节、能不能读出来，四项有一项不过就会被拦下。把"这几张图不能动"写成一句完整的话，比口头交代靠谱得多，也让下一次接手的人能看懂。

资源侧第二刀：多倍图、多语言与无用 assets 怎么取舍

WebP 解决的是"同样一张图占多少字节"，接下来要解决的是"这张图到底还需不需要"。前者是压缩问题，后者是取舍问题；压缩有参数可依，取舍要靠业务判断。

话术库「常规修改」类里的"精简无用资源"就是干这个的，它按五类范围给出成型指令：高密度图片目录、多语言资源目录、未使用的布局与图片、重复与过期资源、无用 assets 文件。在「混淆去毒」类里还有两条相关指令可以搭配使用："资源压缩减肥"（覆盖图片与图标资源、assets 大文件、字体与词库文件、重复资源与冗余目录、音频与视频资源）和"去重复与无用引用"（覆盖重复图片与音频、无效资源引用）。一个负责把内容变小，一个负责把重复与空引用清掉。

多倍图的取舍要想清楚。最高密度那一套图是给高像素密度屏幕准备的，一张图可能顶另外几套的总和。如果这个应用只在 1080p 级别的内部平板上跑，保留中间一两档就够；如果它有对外分发、要覆盖各家旗舰机，那就别动。判断标准不是"哪套好看"，而是"实际要覆盖的屏幕最多需要到哪一档"。这个答案可以从设备清单里直接读出来，不需要猜。

多语言资源也一样。英文、日文、韩文这些目录，如果应用里根本没有语言切换入口，留着就是纯占位。但要先确认一件事：有些第三方库会在自己的资源里带上多语言目录，删之前要看清楚它是谁的资源，别把库依赖的字符串删掉。做法上建议按目录逐一看归属，而不是按名字批量勾选——名字看起来像"多语言"，不代表它属于你的业务代码。

assets 目录经常藏着最容易被忘记的大件：上个版本的内置网页、演示用的示例包、重复的字体文件、早期版本留下的大体积数据。这类文件不进资源表，处理起来相对安全，但同样要确认代码里没有按路径去读它。「混淆去毒」类里的"清理第三方残留｜多余的 assets 文件"就是给这种情况准备的：先确认归属，再动手。

字体与词库文件是另一类"安静的体积"。为了几行特殊字符，有的应用会内置一套完整的中文字体；为了一个搜索框，会带上一份体积不小的词库。这类文件动辄几兆，而且往往只在个别界面用到。「资源压缩减肥」里把"字体与词库文件"单独列为一个范围，就是提醒你：先看它到底覆盖了多少使用场景，再决定要不要整体收掉。同理，内置的音频与视频资源也常是几十兆的来源，如果只是示例素材，处理起来收益很直接。

判断"有没有用"这件事，最笨也最稳的办法是列清单：把这个资源对应的界面找出来，点一遍，看它到底显不显示。列不出界面的，就是可以处理的候选。这一步没有捷径，工具能帮你改，但"要不要改"必须由懂业务的人决定。把清单写成附件发给工具，也顺便留了一份决策依据。

为什么不能硬删资源：资源 ID 错位与「替换或禁用」

这一节是整篇文章最重要的边界。资源可以变小，但不能"直接删"。原因藏在 Android 的资源机制里，理解了它，后面所有操作都会变得有章法。

反编译之后，资源不是一堆散文件，而是一张资源表。布局、代码、清单通过资源名去引用它，编译时再映射成 ID。你直接删掉一个图片文件，但布局里还引用着它，回编阶段就会报错；如果连资源表里的条目一起删，剩下的资源 ID 会整体重新分配，原本指向 A 的引用可能落到 B 上——这种错误编译期不一定报，装到手机上才闪退，或者显示成完全不相干的一张图。这就是"资源 ID 错位"，也是体积优化里最常见的一次翻车。

所以正确做法是"替换或禁用"，而不是硬删。三条思路，按场景挑：

• 替换。用同尺寸、同格式的占位图顶上去。要彻底瘦身，就换成一张极小的图；只是暂时不用，就换成新的设计稿。引用链一点不动，风险最低。
• 禁用。把引用改掉，让它指向一张保留下来的图，或者把入口本身去掉，让这段界面不再出现。
• 收缩。把不用的语言目录、不用的密度目录整体收掉，但要同步确认资源表与引用都还成立，改完立刻回编验证。

回编这一步是检验改动是否成立的关口。资源引用错误、重复资源、文件名不合法，都会在回编时暴露，错误写进 apktool.log。所以顺序永远是：改完先回编，回编过了再装机；不要跳过回编直接"大概没问题"。很多人的坏习惯是只看图标有没有换掉，不看日志——体积优化恰恰是"看不见的部分"最容易出问题。

三条红线：一，不要在资源表里留下悬空引用；二，不要删掉其他资源还在依赖的文件；三，不要在没有备份原始包的情况下做任何不可逆的删除。项目目录里的 source.apk 就是你的保险绳。

顺带说一句命名。资源文件名只能用英文小写字母、数字和下划线，不能有大写字母，也不要用短横线。很多人在电脑上把带中文名、带空格的素材直接拖进资源目录，系统能存下来，回编会挂。素材先在本地改成规范名字，再作为附件给工具，问题会少一半。这类小规矩看着琐碎，却是回编一次过的关键。

最后再补一个判断标准：当你发现某个资源的处理方式需要"先删了试试"，就说明这次改动的信息还不够。正确的顺序是先确认引用关系、再决定替换还是禁用、最后回编验证。体积优化不怕慢，怕的是改完不知道哪里变了。

代码侧：ABI 裁剪与 so 库的取舍边界

代码侧的第一刀通常落在原生库目录上。Android 的安装包会按 CPU 架构分目录放原生库：arm64-v8a、armeabi-v7a、x86、x86_64。一个用了几款原生库的应用，四个架构各放一份，体积就是四倍。这些库不会因为"你没用到那个架构"就自动消失，它们老老实实地占着位置。

话术库「混淆去毒」类里有"so符号裁剪与加密"，其中"库体积与架构裁剪"就是处理这件事的成型指令；同一个组里还有"导出符号与调试信息""JNI 方法注册""关键函数名"等方向，分别对应符号表瘦身与保护。做体积优化时通常先只动"库体积与架构裁剪"，把其他几项留到需要时再说——一次只改一类东西，出问题才好定位。

判断能不能删，不要凭感觉。把目标设备插上，用 adb 查它的架构属性，看它实际加载哪一套库；内部工具就把所有在用机型的架构列一张表，取交集。这一步做完，才知道哪些架构是"真的没人用"。很多人不敢删，不是不知道方法，而是从来没把设备清单列出来过。

删原生库的风险比删资源更高，因为它一旦缺失，表现是运行到某个功能时直接崩，报的是找不到库，而不是启动就报错。所以边界要写清楚：如果设备清单里有任何一台是 32 位机型，就不能删 armeabi-v7a；如果有同事还在电脑模拟器上跑测试，就不能删 x86 系列。删之前先问清楚"谁在什么设备上用"，这句话能省掉一次线上事故。

如果需求不是删库，而是改库里的字符串，规则完全不同：话术库里的"so文件文字替换｜lib 目录下的原生库"要求等长替换、不足用零填充，覆盖 arm64-v8a 与 armeabi-v7a，替换后校验文件大小并确认库能正常加载。二进制里改字符串，长度变了结构就坏了，这是硬约束，不能像改文本文件那样随手加字。

还有一类容易踩的坑：有的库只出现在某一个架构目录里。删的时候按目录整体处理是安全的，按文件名在不同目录之间"对齐"删就很容易删错。做法上建议一条一条对着清单处理，而不是凭目录列表的观感批量勾选。清单从哪里来？从设备架构表来。工具负责执行，判断留给人。

代码侧：去掉调试日志与调试开关

代码侧的第二刀是调试相关的代码。它们在功能上"没用"，但在体积和启动速度上都实实在在地吃资源，而且还带着风险。

话术库「常规修改」类里的"去除调试信息"给了五个方向：日志打印调用、窗口与 WebView 调试开关、调试菜单与入口、数据库与网络调试输出、崩溃信息界面显示。这五类基本覆盖了正式包里不该留下的东西。按经验，第一类和第三类收益最大：日志调用影响启动，调试入口影响安全边界。

为什么日志会影响启动？因为启动阶段是日志最密集的时候：初始化配置、检查网络、拉取用户信息、加载首页数据，每一步都可能在写日志。写日志本身是磁盘 IO，加上格式化字符串的开销，在低端机上能明显拖慢启动。把刷屏日志去掉，是启动优化里性价比最高的一步——改的地方不多，效果能被用户直接感觉到。

调试开关是另一类问题。有些应用在设置页或者某个隐藏入口里留着调试菜单，可以切换服务器地址、打开日志面板、清空数据。这些入口在开发阶段确实有用，但正式分发版留着就有风险：用户误触之后行为会变得不可解释，反馈问题时也说不清"我点了哪里"。去掉调试菜单与入口，是给后续排障减负。

这里要提一个反向的边界：不要为了"干净"把排障能力一起删掉。崩溃与错误的本地记录如果还有用，就保留最小的一份；否则出了问题是真没法查。合规的做法是"去掉面向调试者的入口与刷屏日志，保留必要的错误记录"，而不是把整块清空。这个度需要按团队自己的排障习惯来定。

还有一组容易忘的残留文件，在话术库「混淆去毒」类的"清理残留与日志"里：开发期调试文件、打包产生的无用文件、运行期日志与崩溃文件、临时缓存目录、备份与测试配置。它们不属于业务代码，但确实会出现在安装包里，尤其是前两类。开发期的测试配置被打进正式包，是内部工具里很常见的一种"体积小问题、风险大问题"。

"去除调试信息"里的另外两个方向也值得单独说一句。数据库与网络调试输出，指的是把 SQL 语句、请求地址与返回内容直接写进日志的那类代码；它们不仅占体积、拖启动，还可能把内部接口地址留在日志里。崩溃信息界面显示，指的是崩溃时把堆栈直接弹在界面上；这类界面在开发阶段有用，分发版留着会让用户看到一堆看不懂的文字，既影响体验，也不利于收集有效反馈。

1. 先在话术库里选"去除调试信息"，把范围定成"日志打印调用"与"窗口与 WebView 调试开关"两项。
2. 需求里补一句：保留崩溃与错误的最小本地记录，不要影响错误上报链路。
3. 再补一句：去掉调试菜单入口与界面上残留的调试按钮。
4. 回编后装机，走一遍主流程，确认没有因为去掉日志而暴露之前被日志掩盖的问题。
5. 最后在 pack.log 里确认这次打包四步都跑完，产物落在 build 目录下。

启动优化：精简启动页与启动期的网络等待

启动页是用户对"快不快"的第一印象，也是最容易改的一块。它同时属于视觉和性能两件事，所以既要用设计思路，也要用工程思路。

话术库「界面美化」类里有"启动页美化｜应用冷启动页"，它的参数写得很克制：启动页总停留控制在 1.5 秒内，动画不影响启动速度；用主题背景色而不是纯白，避免从启动页到首页闪白；标识用矢量或高分辨率图，大屏上不能模糊；启动页不要放需要联网才能显示的内容。验收标准是"冷启动到首页不超过 3 秒"。

这四条其实回答了启动页优化的全部问题。停留 1.5 秒是"别为了看动画而拖时间"；主题背景色是"别闪白"；矢量或高分图是"别糊"；不放联网内容是"别把启动页做成等待页"。前三条关系到观感，最后一条关系到性能，也最容易被忽略。

最后一条尤其重要。很多内部工具的启动页会顺便做一次配置拉取或者版本检查，网络一慢，启动页就一直转。正确的做法是：启动页只负责显示品牌，数据请求放到首页去做，并且给一个明确的超时和兜底值。这不是"删功能"，而是把功能挪到它该在的位置。

启动期的网络等待还有一个隐藏版本：首页的第一屏在等接口返回，接口没回来就整屏空白。这属于业务逻辑改动，需求里必须写清三件事：超时时间是多少、超时后显示什么、失败后用户能不能重试。写清这三件事，改动就是可控的；只写一句"优化启动速度"，结果往往只是把等待换了个地方。

启动页还有一个常被忽略的细节：多张启动图。有的应用为不同分辨率准备了多套启动背景，改版之后旧的那几张没人删。用"精简无用资源"里的"未使用的布局与图片"处理一遍，往往能顺手清掉几百 KB。体积和启动这两件事经常在这里汇合：删掉不用的启动图，既小了包，也少了一次没必要的资源加载。

两个自家应用的改包实例：从改到验的完整链路

实例一：自家记账 App —— 图片瘦身加启动页重做

第一个实例是团队自己开发的记账应用，版权在自己手里，改它不需要任何外部许可。它的典型问题是"迭代出来的胖"：图标存了五套密度，启动页背景存了三张不同分辨率的图，首页横幅是 PNG，还有一批早期版本的插画没人用。

以前怎么做。设计同学把新素材按五个密度各导出一份，开发同学手工替换各个密度目录下的文件，改完打包看效果。少替换一个目录，高分辨率手机上还是旧图，只能重新导一遍。启动页背景换过一次，旧的那三张图留在包里没删——理由很实在："删了怕编译不过。"于是每一轮改版都往上叠一点，包就一年年变胖。

现在怎么做。把 APK 拖进智能修改电脑版，等 aapt 解析完，在话术库里选「常规修改」→ 图片转WebP，范围选"drawable 位图资源"和"启动页与背景图"，档位选"保持兼容"。然后在指令后面补三句：只处理 100 KB 以上的图；带透明通道的图标保持无损；启动页背景改为一张图配主题色。再补一条"精简无用资源"的指令，范围选"未使用的布局与图片""高密度图片目录"，处理旧插画与多余密度。

这两条需求可以一次发出去，也可以分两次做。团队的经验是分两次：先做图片格式，装机验证没问题，再做资源精简。因为格式转换是"替换"，资源精简是"取舍"，后者风险更高，分开做才知道是哪一步出的问题。

改完怎么验证。第一，看体积：项目目录里的原始包与打包产物各记一次字节数，按话术库给出的体积目标（降低 40%）核对，再顺手看图片相关目录的大小变化。第二，看界面：桌面图标、启动页、首页横幅，在浅色与深色主题下各点一遍。第三，看启动：强制停止后连续启动两次，取第二次的耗时，对照"冷启动到首页不超过 3 秒"这条验收线。第四，覆盖安装一次，确认草稿与账目数据都还在。

实例二：自家教学 App —— 多语言、多密度与原生库架构一起收

第二个实例是团队做的教学应用，只在国内的 Android 平板上使用，包里却带着完整的多语言资源、四个架构的原生库和一堆调试日志。它的体积里，"用户根本用不到的部分"占比很高，是典型的"顺手带出来的浪费"。

以前怎么做。开发同学在工程里手动删多语言目录，删完发现某个第三方库的资源也在一起，回编报错，只能一份一份恢复。原生库的处理更麻烦：四个架构并列在目录里，谁也不敢删，因为"不知道测试机是什么架构"。日志则是常年留着，反正"能跑就行"。于是这个应用每年的体积增长都比功能增长快。

现在怎么做。先用 adb 把在用的几台平板的架构查出来，确认全部是 arm64-v8a；然后写三段需求。第一段用"精简无用资源｜多语言资源目录"，只保留中文与英文两套，并写明"先确认目录归属，不要动第三方库依赖的资源"；第二段用"so符号裁剪与加密｜库体积与架构裁剪"，明确只保留 arm64-v8a，并写明"如果设备清单里有 32 位机型就不要执行"；第三段用"去除调试信息｜日志打印调用"，同时保留崩溃与错误的最小本地记录。三段需求分开做，每段做完回编装机一次。

改完怎么验证。装机后先冷启动两次，取第二次的启动耗时；再走一遍主流程——登录、加载课程列表、打开一节课程、播放视频或打开讲义；然后比对体积，确认资源目录与原生库目录的变化符合预期；最后用旧版包做一次覆盖安装，确认升级路径正常、登录状态没丢。四步都过，才把包发到班级群里。

改动链路：从拖入 APK 到装机验证

1. 拖入 APK。工具用 aapt 解析图标、应用名、包名、版本、SDK、启动页，解析与反编译跑在后台线程，界面不卡。
2. 建项目。在 Project 下生成一个 8 位随机名目录，写 config.ini、history.ini，并复制一份 source.apk 作为原始包。
3. 写需求。详情页里从话术库选成型指令，再补上自己的参数与边界；附件逐个写用途，不少于 10 个字。
4. AI 改反编译工程。点"立刻修改"，需求原文与日期写进 history.ini；AI 完成后在项目目录留下完成标志文件。
5. 自动回编。主窗口每 2 秒轮询一次标志文件，读到就删除并进入打包流程，apktool 回编生成未签名包，全过程写 pack.log。
6. 对齐与签名。zipalign 做 4 字节对齐，apksigner 签名，默认走 v1+v2+v3，兼顾新老设备。
7. 装机验证。adb 找设备、装包、用 am start 拉起主界面，再用 dumpsys 复核前台应用确实是它。
8. 归档。成品包、pack.log、需求原文一起留档，source.apk 保留用于回退。

这套链路里有一个细节值得单独说：等待上限是 1 小时。这个机制的好处是不用盯着屏幕，但也不会无限期地等一个已经失败的任务；超过一小时没有结果，正确动作是去翻 apktool.log 和 error.log，而不是反复点按钮。体积优化常常要改好几轮，这个"能等、但不等过头"的设计，比想象中省心。

打包四步与可回退的档案

1. 回编。把反编译工程重新编译成未签名的包。资源引用错误、重复资源、文件名不合法，都会在这一步暴露，错误写进 apktool.log。
2. 对齐。做 4 字节对齐，让应用在运行时能更高效地读取未压缩资源。对齐没做通常也能装，但属于"埋着的坑"。
3. 签名。支持 v1、v2、v3、v4，默认走 v1+v2+v3；签名口令通过环境变量传入，不拼进命令行，也不落进日志。
4. 复核。用 apksigner verify 验证签名并打印证书信息，回答"到底签没签上"这个问题。

为什么多一步复核？因为签名命令有时看起来跑完了，实际并没有签上。密钥格式不对、别名写错、口令不对，这些问题在签名那一步可能只给一个含糊的返回，只有复核会明确报出来，并打印证书信息，正好用来确认"这是不是我们那套证书"。产物落在 build 目录下：未签名包、对齐后的包、签名后的包，全过程写进 pack.log。

签名有四条路可选：默认签名、JKS 或 keystore、证书配私钥、随机签名。内部应用升级最怕的是"覆盖安装失败"，而它十有八九是签名不一致：上一版和这一版用的不是同一套证书。沿用上一版那套证书，问题就少一大半。如果拿不到旧证书，只能改包名让它并存，但那会带来数据目录、推送、分享链接一连串变化，需要提前评估。

体积与冷启动的对比做法

• 体积对比。同一个项目目录里，原始包是改前的基准，打包产物是改后的结果，各记一次字节数；再顺手看资源、原生库、assets 三个目录的大小变化，知道体积是从哪一块省出来的。
• 冷启动对比。装机后拉起应用，看输出的启动耗时。冷启动必须先把应用强制停止再启动，而且连做两次取第二次——第一次往往包含系统首次校验与预编译开销，第二次更接近用户日常感受。
• 主流程对比。登录、列表、详情、播放或下载，每个环节点一遍，重点看图片是否显示、文字是否清晰、有没有空白块。
• 覆盖安装对比。用旧版包直接覆盖安装新版，确认数据没丢、登录状态还在、签名一致。

验证清单、回退与合规边界

把前面这些动作收敛成一份清单，每次改包照着勾。它不追求覆盖所有情况，只保证最常见的坑都被看见。

• 装机。目标机型至少一台，装完先看桌面图标与应用名是否正确。
• 冷启动。强制停止后连续启动两次，取第二次的耗时与现象。
• 主流程。登录、列表、详情、播放或下载，逐个点一遍，重点看图片与文字。
• 比对体积。记录原始包与成品包的字节数，记录资源、原生库、assets 的变化。
• 覆盖安装。用旧版包覆盖安装新版，确认数据、登录状态与签名一致。
• 回退准备。确认项目目录里原始包、配置、历史、打包日志都在。

回退这件事要说清楚。项目目录里的 source.apk 是原始包，任何一次改动都可以从这个包重新开始；history.ini 里留着每次需求的原文与日期，改了什么一目了然；pack.log 记录打包全过程，签名复核的输出也在里面。这三样东西放在一起，就把"改包"从一次性的手艺变成了可复盘的流程。体积优化一定会试错，有回退路径才敢试。

还有几条经验值得记下来。一次只改一类东西：先做图片，再做资源精简，再做原生库与调试信息，每步之间都装一次机，出问题能立刻定位到是哪一步。需求里永远写清"不要动什么"，尤其是权限、数据库结构、签名配置和错误上报链路。附件用途写足十个字，不是为了凑字数，而是逼自己把"这个东西是干什么的"说清楚。

写到这里必须把边界讲清楚。这套做法只适用于自有版权的应用，或者已经获得明确授权的应用。请勿用于破解他人付费应用、去除授权校验或绕过安全机制，也不要用它去改别人的商业应用。工具只是工具，边界在用它的人手里。做体积与启动优化尤其要注意这一点：你改的是自己的东西，改完要对自己的人负责。

真出了问题时，日志比猜测有用。运行过程中的信息写进运行日志，异常与失败写进错误日志，打包全过程写进打包日志，反编译与回编的细节写进反编译日志。四份日志各有分工，遇到"回编失败""装机失败""启动闪退"这三类问题，先按对应的日志定位，比反复重试快得多。体积优化改的是别人看不见的地方，日志就是唯一能看见它的窗口。

最后说一句协作。这类改动最好留一份说明：改了哪些范围、用了哪几条成型指令、体积与冷启动各是多少、哪些资源被替换过、哪些架构被裁掉了。半年后有人要再加一个架构、再补一套语言，看着这份说明就知道从哪里下手。工具能保证这一次改得干净，文档能保证下一次改得不乱。

回到最开始那三个数字。体积、冷启动、安装后占用，它们不是靠某一次激进改动降下来的，而是靠三件事反复做出来的：看清包里有什么、把明显浪费的部分替换或禁用掉、每一步都验证。一个内部工具削掉四成体积、把冷启动压进三秒以内，就已经解决了分发与抱怨这两件最现实的事。

安卓修改大师智改工坊把这套链路做成了"拖进去、说一句、自动回编签名装机"：Windows 10/11 64 位，需要 .NET Framework 4.6.2 及以上，安装包约 6.86 MB。官网在 www.apkeditor.cn，介绍与下载页在 https://www.apkeditor.cn/ai-version.aspx。

只需说话，就能让应用变成你想要的样子。你不需要懂 smali，也不需要配一整套 Android 开发环境；你需要的是知道包里哪一部分在浪费空间、哪一部分在拖慢启动，然后把这件事说清楚。剩下的回编、对齐、签名、装机，交给工具跑完，你只负责验收。

用户评价

我的记账应用一直是"越迭代越大"，图标五套密度、启动页三张背景。照着文章的思路先转 WebP 再精简资源，包明显瘦了，冷启动也没那么磨人了。

—— 阿澈 · 独立开发者

以前删多语言目录总要小心翼翼，怕把第三方库的资源一起删掉。现在先列清单、再用成型指令分段做，回编一次过，装机一次过。

—— 林工 · 企业内训应用维护

最认同"替换或禁用，而不是硬删"这句。资源表这东西，删文件的时候感觉没事，跑起来才知道引用错位有多难受。

—— 老周 · 安卓逆向爱好者

我不写代码，但我会看体积和启动时间。"冷启动两次取第二次"这个细节挺实用，以前我们拿第一次的数据讨论，白焦虑了半天。

—— 苏敏 · 自有应用产品经理

内部工具以前没人管体积，直到群里发不动安装包。现在每版都记一次原始包和成品包的字节数，涨了就查原因，成了固定动作。

—— 程工 · 团队技术负责人