先把主标语放在最显眼的位置：出包不是"打完就发"，是"验完才发"。改包改得快是本事，但把一版包交出去之前，你总得有一份说得出口的检查清单。

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

一、把"检查"挪到出包前：一次翻车的成本，远高于五次确认

先说个反复发生的事故：包改完、签完、发出去了，同事装上却提示安装失败；或者装上了，图标还是旧的；或者第一屏还是上一版的设计。问题都不大，但每一次都要重走一遍"改—打—发—装—看"。

所以质检的价值不在于"检查很专业"，而在于把问题拦在成本最低的位置：同一处错误，出包前发现只花一分钟，发出去之后要花一小时——还得解释、重发、让对方重装。

这篇的清单是五项：签名校验、体积变化、图标与名称、启动页、历史记录。前三项在电脑上就能看完，第四项要在设备上看一眼，第五项是归档习惯。

检查项	看哪里 → 不合格的信号
签名校验	打包第四步 verify → 校验没过；密钥不是你要用的那个
体积变化	build 三个产物与原包对比 → 涨得离谱，也许改超了范围
图标与名称	设备桌面 + 项目信息 → 图标旧图；名称没改；版本对不上
启动页	装完拉起后的第一屏 → 还是上一版，或根本没起来
历史记录	详情页历史 + pack.log + 打包标记 → 缺一即不完整

这五项的顺序不是随便排的：前三项是"电脑上能判定的事实"，第四项是"设备上的事实"，第五项是"以后还能不能查出事实"。

二、第一查 · 签名：前三步只看退出码，"签没签上"要 verify 说了算

打包是四步：回编（apktool b）→ 对齐（zipalign -p 4）→ 签名（apksigner + testkey）→ 校验（apksigner verify）。质检视角要盯的是最后一步。

原因是这样的：前三步只反映退出码，"到底有没有签上"要靠 verify 说话。退出码为 0 不等于结果正确——这在打包这件事上是一条被反复验证过的经验。多做一步 verify，就是把"我以为签上了"变成"确实签上了"。

第二件要确认的事是用的哪个密钥。签名密钥是工作目录根目录下的 testkey.pk8 与 testkey.x509.pem，可以替换：内部测试用默认的就够，需要固定签名身份的正式场景，就把自己的密钥换上再出包。这一条如果查漏，后面所有努力都会卡在"安装失败"上。

质检的第一原则：不把"退出码为 0"当成"结果正确"。多做的这一步 verify，成本是一个勾，省下的是整轮返工。

顺带说清产物：build 目录下有 unsigned.apk（未签名）、aligned.apk（对齐后）、signed.apk（签好名，设备上装的就是它）。设备验证必须用 signed.apk，拿 unsigned.apk 去装，装不上是必然的。

三、第二查 · 体积：回编后的包会变，关键看"变在不在预期里"

第二个检查项是体积。这里要先摆正预期：APK 经过"反编译—修改—回编"之后，体积发生变化是正常的。原因不神秘——资源被重新组织、包被重新压缩、对齐步骤也会影响最终字节数。所以这一查的目的不是"要求体积不变"，而是"判断变化是否在预期范围内"。

怎么判断？把 build 目录里的产物和原来的包放在一起看：

• 只换了图标、改了应用名：体积变化应该很小，量级上接近"换了一张图的差别"。如果涨得离谱，先回头看需求范围写清了没有。
• 换了启动页背景这类大图：体积变化主要来自这张图本身与重新压缩，属于可解释的变化。
• 只改文本与少量配置：体积几乎不该有可感知的起伏，出现明显变化就该多问一句"改到哪儿去了"。

顺手的地方在于：打包跑完可以「保存 APK」（默认名 应用名_版本号_signed.apk）或「打开所在文件夹」直接进 build 目录，三个产物挨着摆在一起，看属性就能对上大小。命名统一，你不用猜哪个文件是哪一版。

另外，打包过程中窗口不给关，防止你误以为"没在跑"而关掉它，导致产物半途夭折、日志断档。

四、第三查 · 图标与名称：别让"看起来对了"替你下结论

第三项最容易被忽略，因为它看起来"那么明显"。但恰恰是明显的部分，最容易被跳过。要查两样：桌面图标、应用名（顺带瞄一眼版本号）。

关于图标，有个细节值得知道：导入时程序用工作目录里的 aapt 解析图标、应用名、包名、版本号、最低与目标 SDK、启动页；图标是从包里取出的原图，按最高密度挑选——aapt 报出的 65534 是"任意密度"的哨兵值，不会被当成真实密度，所以不会挑到小图。你看到的图标，和装到手机上的图标，是同一张原图。

检查要点可以压成三句话：

• 图标对不对：装到设备上看桌面，放大确认是这次的图，而不是上一版。
• 名称对不对：内测版、正式版这类后缀最容易写反；改名前把需求里的名称原样核对一遍。
• 版本号与包名对不对：它们也是导入时解析出来的信息，出包前对着项目信息确认一次，避免"新包旧版本号"。

如果导入的包比较特殊——分包 apks、加密包、jar / class 这类解析不出包信息的——程序会以文件名继续建项目，并在页面上给一句说明。这种情况更要在出包前从设备侧确认图标与名称。

五、第四查 · 启动页：从"拉起来"到"确认前台是它"

前三项都能在电脑上判定，这一项必须到设备上看。动作只有一个：把包装上去，看应用被拉起后的第一屏。但工具为了让你不白等，在背后做了几件事：

• 用 adb 找手机或模拟器并安装；常见国内模拟器（雷电 / MuMu / 夜神等）装了但 adb 没连上时会自动扫端口。
• 拉起用 am start，而不是 monkey：新版安卓镜像已没有 monkey；更关键的是，monkey 失败时退出码还是 0，容易误判成"启动成功"。
• 启动页组件名三档查找：先看 config.ini 里的 LaunchableActivity；没有就向设备 resolve-activity；再不行才退回 monkey。
• 装完用 dumpsys 看一眼前台应用是不是它：这一步决定了"你看到的第一屏"确实是这个包的第一屏，而不是残留在后台的旧版。
• 看的方式：手机走 scrcpy 投屏到电脑，用鼠标直接点；模拟器把窗口提到最前面。

两种常见情况也有对应处理：模拟器装了但没开，会搜出安装路径并问你要不要现在打开；设备没授权，会提示你在手机上点「允许 USB 调试」。

六、第五查 · 历史与标记：让这一版以后还能被查出来

最后一项不是为了这次出包，而是为了下一次有人问"这版是谁改的、什么时候改的、改了哪里"时，你能立刻答出来。要查三处。

第一处：修改历史。详情页直接列出这个项目的修改历史，最新一条在最上面，每条显示 #序号 + 时间 + 需求原文，而且需求原文完整显示、不截断；右侧的「选择」能把那条需求填回输入框，方便"照上次那条再改一遍"；项目列表里每条的「历史」按钮可单独打开历史窗口。记录按"记录1、记录2"递增，删某一节即删那条记录。出包前扫一眼：这次的需求在不在里面、写得清不清楚。

第二处：打包标记。每次出包前，程序会自动往 res/values/styles.xml 写入一个 name="info" 的样式，内容是把时间、登录账号、机器码、机器名、系统用户名、程序版本、应用名、包名等信息编码后的标记——一版包发出去之后，它自己带着"是谁、什么时候、从哪台机器出的"这些信息。

第三处：日志与项目目录。打包全过程写进项目目录的 pack.log；吸附与打包过程的诊断信息进 %LocalAppData%\ApkGallary\dock.log，异常日志进 error.log。项目放在工作目录的 Project 下，每个项目一个 8 位随机字符串目录，里面有 config.ini、source.apk 和反编译输出（apktool 目录）。反编译失败也不影响项目本身：配置、图标、源包已落地，程序会提示原因并给出 apktool.log。

七、两个自家应用：把五查清单真正用一遍

清单写得再漂亮，也得落到具体动作上。下面两个例子都发生在我们自己 / 内部的应用上。

八、用户评价与合规提醒

最后听听做质检、做交付的人怎么说。他们的关注点出奇一致——不是"能不能改"，而是"改完能不能证明它对了"。

把全文收一下：五项检查说到底是在回答一个问题——"我凭什么说这版是对的？"签名有第四步下结论，体积有 build 里的三个产物可比，图标与名称在桌面上看得见，启动页有前台确认，历史与标记让这一版以后还能被查出来。五项查完，你交出去的不只是一个包，而是一份有据可依的交付。出包不是"打完就发"，是"验完才发"。

产品是安卓修改大师智改工坊，介绍页：https://www.apkeditor.cn/ai-version.aspx；官网 www.apkeditor.cn。想让清单变成习惯，最快的办法是拿一个自家的包走一遍：拖入安装包 → 写一句话需求 → 看它自动回编 / 对齐 / 签名 / 校验 → 一键装到手机或模拟器看效果 → 再把五项检查各对一遍。