📚 课程目录第4章签名对APK体积的影响机制（V1签名增加文件大小）

签名对APK体积的影响机制（V1签名增加文件大小）

V1签名为什么会让APK“胖”起来？

说实话，很多人第一次发现V1签名会导致APK体积变大时，都觉得挺意外的。我刚开始做Android开发那会儿也纳闷——签个名而已，怎么能多出上百KB？

V1签名（JAR签名）的原理是：它会把你APK里每个文件单独计算一个摘要，然后把这些摘要打包成一个MANIFEST.MF和CERT.SF。最后再对整个签名信息做一个数字签名，存到CERT.RSA里。

你想想看，如果APK里有500个文件，那MANIFEST.MF里就得写500条摘要记录，每条至少占用几十个字节。再加上签名文件本身的体积，这加起来就不是小数目了。

关键点：V1签名会向APK内注入额外的文件（META-INF目录下的三个文件），直接导致包体膨胀。

V2签名与V3签名的改进

V2和V3签名是Android 7.0之后引入的。它们不再是逐个文件签名，而是对整个APK的二进制数据进行签名。说白了，就是把签名信息塞到了一个叫“签名块”的区域里，不额外增加文件数量。

这就意味着：同样的APK，用V2签名比用V1签名，包体可以小不少。我遇到过几次因为V1签名导致APK超限的尴尬情况——渠道包本来压到刚好50MB，V1一签立马超了500KB，渠道包上传直接被拒。

签名方案	签名方式	对体积的影响	引入版本
V1（JAR签名）	逐文件签名	增加META-INF目录，包体膨胀较明显	Android 1.0
V2（APK签名方案v2）	对整个APK数据块签名	签名信息嵌入签名块，几乎不增体积	Android 7.0
V3（APK签名方案v3）	基于V2扩展，支持密钥轮换	与V2类似，仅增加少量元数据	Android 9.0
V4（增量签名）	用于增量安装	不写入APK，独立文件	Android 11.0

避坑经验：我曾经为了兼容老设备，不得不保留V1签名。但后来发现其实最低targetSdkVersion提到28之后再配合V2签名，绝大多数设备都支持。从那之后我直接在gradle里只配V2+V3，包体立马瘦了200KB以上。

签名文件具体占了多少体积？

我拿一个实际项目测过，效果很明显。下面是我的测试数据，大家可以对照看下自己的项目。

APK原大小（未签名）	V1签名后	V2签名后	V1 vs V2 体积差
24.8 MB	25.4 MB	24.9 MB	约 500 KB
48.2 MB	49.1 MB	48.3 MB	约 800 KB
128.0 MB	130.2 MB	128.1 MB	约 2.1 MB

为什么会这样？因为APK越大，里面的文件越多，V1签名需要记录的摘要条目也越多。而V2只增加一个固定大小的签名块（一般几十KB），几乎跟APK原始大小无关。

// 在 build.gradle 中配置签名方案（推荐）
android {
    ...
    signingConfigs {
        release {
            storeFile file("my.keystore")
            // 尽量使用 V2 + V3
            enableV1Signing = false
            enableV2Signing = true
            enableV3Signing = true
        }
    }
}

警告：如果你把V1签名关掉，一定要确保你的targetSdkVersion ≥ 28（Android 9.0），并且确认灰度设备都支持V2签名。否则部分低版本Android设备安装时会解析失败。

V1签名到底多了哪些文件？

我用一个简单的APK解压来看，大家就明白了。正常签名完成后，APK里会多出这样一个目录结构：

META-INF/
├── MANIFEST.MF      # 每个文件有一条摘要（SHA-256）
├── CERT.SF          # 对MANIFEST.MF的摘要 + 每条摘要的签名
├── CERT.RSA         # 最终的PKCS7数字签名（包含公钥证书）

这三个文件加起来，少则几十KB，多则几百KB到几MB。我看过一个有6000多个资源文件的APK，V1签名文件足足占了3.8MB——啧啧，这要是换成V2，直接省下近4MB的空间。

SVG：V1/V2/V3签名机制与体积影响流程图

怎么查看自己APK的签名体积？

不用猜，直接拿命令看一眼就清楚了。我一般这样操作：

# 解压APK，看看META-INF目录占用多大
unzip -l app-release.apk | grep META-INF/ | awk '{sum+=$1} END {print "META-INF total bytes:", sum}'

# 或者直接用aapt2 dump
aapt2 dump resources app-release.apk | grep META-INF

更直接的方法：对比关闭V1和开启V1的APK体积差。在build.gradle里分别打两个包，对比一下就一目了然了。

实战经验：有一次我打渠道包，发现某家应用商店要求必须使用V1签名（老平台不支持V2）。同一个包，V1签名后比V2大了将近1.2MB。后来我跟渠道沟通升级了平台，才把那1.2MB省回来。所以我的习惯是——除非有明确的老设备兼容需求，否则一律只开V2+V3。

V1签名还会带来哪些隐藏问题？

除了体积变大，V1签名还有两个坑：

签名验证慢：每次安装都要解压并逐个验证每个文件的摘要，文件越多越慢。我见过一个超大游戏APK，V1验证花了5秒多，用V2只需要1秒。
容易被篡改：V1签名不保护APK中的额外数据区域（比如注释块），所以存在被注入恶意代码的风险。

嗯，这也是为什么Google从Android 7.0开始主推V2，从Android 9.0开始主推V3。安全性和体积双赢的事，咱没理由不跟进。