📚 课程目录第2章 AGP签名配置简介

AGP签名配置简介：signingConfigs配置块、配置属性详解

聊到 APK 签名，很多同学第一反应就是「配个 keystore，输个密码就完事了」。说实话，我刚开始也是这么想的。直到有一次，我发现同一个项目，只是改了签名配置里的一个属性，生成的 APK 体积差了好几百 KB。那之后我才开始认真研究 signingConfigs 里面到底藏了多少门道。

今天我们就来扒开 signingConfigs 这块配置，看看每个属性都在背后干了什么，以及它们怎么影响 APK 体积。

signingConfigs 配置块：签名的「总控室」

在 AGP（Android Gradle Plugin）里，signingConfigs 是 android {} 块下的一个配置块。你可以把它理解为「签名的总控室」——所有跟签名相关的参数，都在这里声明。

android {
    signingConfigs {
        release {
            storeFile file("my-release-key.jks")
            storePassword "123456"
            keyAlias "my-alias"
            keyPassword "123456"
            storeType "jks"
            v1SigningEnabled true
            v2SigningEnabled true
            enableV3Signing true
            enableV4Signing false
        }
    }
}

我个人习惯把 release 和 debug 分开配置。debug 通常用 Android Studio 自动生成的 debug.keystore，但 release 必须手动指定。嗯，这里要提醒一句：千万别把密码硬编码在 build.gradle 里提交到 Git。我之前接手过的一个项目，密钥直接写在配置文件里，结果仓库泄露，整个签名体系都得重建——教训深刻。

核心配置属性：每个字段都不是白给的

下面这张表格，把 signingConfigs 里常用的属性都列出来了。你可以边看边对照你自己的项目。

属性名	类型	说明	对包体积的影响
`storeFile`	File	密钥库文件路径（.jks/.keystore）	无直接影响
`storePassword`	String	密钥库密码	无直接影响
`keyAlias`	String	密钥别名	无直接影响
`keyPassword`	String	密钥密码	无直接影响
`storeType`	String	密钥库类型（jks / pkcs12）	无直接影响
`v1SigningEnabled`	Boolean	是否开启 JAR 签名（v1）	开启会增大 APK 体积
`v2SigningEnabled`	Boolean	是否开启 APK 签名方案 v2	开启会减小 APK 体积
`enableV3Signing`	Boolean	是否开启 APK 签名方案 v3	体积影响与 v2 类似
`enableV4Signing`	Boolean	是否开启 APK 签名方案 v4（增量更新）	开启会增加 APK 体积（嵌入签名块）

你可能会问：v1、v2、v3、v4 这些签名版本，到底怎么影响 APK 体积的？简单说，v1 是传统 JAR 签名，会在 META-INF 下生成一堆文件（MANIFEST.MF、CERT.SF、CERT.RSA），这堆东西直接占空间。v2/v3 把签名信息嵌在 APK 的「签名块」里，效率更高，而且因为去掉了那些冗余文件，APK 反而更小。v4 是为了增量更新设计的，会在 APK 尾部附加签名信息，所以体积会变大。

关键结论：如果你的 minSdkVersion >= 24，完全可以把 v1 关掉，只保留 v2+v3。APK 体积能瘦 100~300KB，而且签名验证速度也更快。

签名版本与包体积的「权衡」

讲到这，我想起之前优化一个视频类 App，APK 体积 80MB。调查发现它居然同时开启了 v1、v2、v3 甚至 v4。我说这没必要啊，因为目标 minSdk = 26（Android 8.0）。关掉 v1 和 v4 之后，APK 直接少了 1.2MB，而且 Google Play 还没告警。你想想看，这 1.2MB 要是换成资源优化，得多花多少功夫？

下面这个表格帮你快速决策：

minSdkVersion	推荐签名方案	包体积影响（相对）
≤ 23（Android 6.0 以下）	v1 + v2	中等（v1 产生文件开销）
24 ~ 27（7.0~8.1）	v2 + v3（可关闭 v1）	小（节省 100~300KB）
≥ 28（9.0 以上）	v2 + v3，按需 v4	最小（完全可去掉 v1）

我的经验：对于绝大多数新项目，直接设置 minSdk 24，然后 v1SigningEnabled false + v2SigningEnabled true + enableV3Signing true + enableV4Signing false。既兼容性好，APK 又最小。如果要做 Google Play 的增量更新，再考虑开 v4。

签名配置的知识结构图

下面这张图，把 signingConfigs 的核心概念串在一起。你可以把它当作「速查地图」。

⚠️ 安全警告：千万别把 storePassword 和 keyPassword 直接写在 build.gradle 里提交到版本控制。建议使用 gradle.properties 中的环境变量，或者通过 CI/CD 系统的密钥管理注入。我曾经见过一个公司的 APK 签名密钥直接在 GitHub 公开仓库里挂了两年——那画面太美不敢看。

小总结：记住这三句话

signingConfigs 是签名参数的总配置文件，每个字段都有明确用途。
签名版本直接影响 APK 体积：v1 增加体积，v2/v3 更高效，v4 为增量更新而生。
不要为了兼容而过早开启所有签名版本：根据你的 minSdk 做减法，体积和安全性都能兼顾。