第3章 不同签名版本对APK大小的影响：签名块开销对比

3.1 签名块到底藏了多少“水分”？

咱们做Android打包，代码、资源、Native库这些大头大家都会盯着。但签名块那几KB到几十KB的开销，很多人直接忽略了。我当年在优化一个超大型APK时，发现签名块竟然占了将近100KB——这在动态下发场景下，可是实打实的流量浪费。

签名块是什么？简单说，就是APK里用来存放签名信息、证书链、摘要哈希的特殊区域。不同签名版本，结构不同，体积也天差地别。

3.2 各版本签名块的大小到底差多少？

我直接拿一个典型的中型APK（约30MB）测过，结果如下表。注意，这些数字会因证书链长度、签名算法不同而浮动。

签名版本	签名块大小 (典型值)	主要构成	体积影响因素
V1 (JAR签名)	1 ~ 3 KB	META-INF 目录下三个文件	算法RSA vs DSA，证书链长度
V2 (APK签名方案v2)	3 ~ 8 KB	二进制签名块 (ID-0x7109871a)	签名算法 (RSA 2048 ≈ 3KB, ECDSA ≈ 1KB)
V3 (APK签名方案v3)	5 ~ 15 KB	支持证书轮换的签名块	证书链长度、轮换标志位、附加属性
V4 (增量签名)	20 ~ 50 KB (增量包更大)	哈希树 + 签名数据	APK原始大小、分块数量

3.3 实战案例：同一个APK，换了个签名算法少了6KB

去年我帮团队优化一个金融类APK，当时大小65MB左右。我们为了安全同时启用了V2和V3签名（这是Gradle默认行为）。我偶然看了一下签名块大小——好家伙，V2签名块7.2KB，V3签名块11KB，加起来近18KB。

后来我查了一下签名算法配置。项目里用的是RSA 2048位 + SHA256，证书链包含了两个中级CA，一共三层证书。我尝试切换到ECDSA P-256 + SHA256，证书链缩短到两层（自签名+根），结果V2签名块降到2.5KB，V3降到4.1KB，合计6.6KB。

省了11.4KB。听起来不多，但想想如果把这个APK每天下载十万次，流量节省还是很可观的。

3.4 避坑指南：签名选项怎么选？

• 不要为了省体积只用V1——V1签名安全性太低，Android 11以上强制要求V2/V3。我曾经在兼容老旧设备时只开了V1，结果被Google Play拒了。
• 优先使用ECDSA而非RSA——同样安全强度下，ECDSA签名数据比RSA小将近一半。Gradle里配置 signingConfig.keyAlgorithm = ECDSA 就行。
• 证书链尽量短——每多一级证书，签名块就多1~2KB。如果你用的是公开CA，尽量选择不含中间CA的根证书直接签名（但注意信任链问题）。
• V4签名单独控制——如果你不做增量更新（如Google Play的增量包），可以在 build.gradle 中显式关闭V4：

android {
    signingConfigs {
        release {
            enableV4Signing = false  // 若不需增量分发，关闭V4
        }
    }
}

3.5 签名块开销的“隐形”影响

你可能觉得这十几KB不算什么。但想想看：如果你的APK需要经过网络分发（如游戏包的分站下载、灰度更新），每1KB都是成本。我见过有些团队为了压缩资源把图片从PNG换成WebP，结果签名块却开着四层证书链+V4，白白浪费了省下来的空间。

另外，V4签名的哈希树大小跟APK分块数量有关。如果APK超过100MB，V4签名块可能冲到50KB以上。这时候权衡利弊就很重要了——如果你的应用根本不通过Google Play分发，直接关掉V4就好。

好了，这一章就聊到这儿。签名块虽小，但苍蝇腿也是肉。下次我们接着聊如何用APK Analyzer定位签名块的“水分”。