签名基础概念：从原理到体积的第一印象

大家好，我是你们的老朋友。今天我们来聊聊 Android 打包时那个绕不开的坎——Keystore 签名。很多同学问我：签名不就是点一下“Generate Signed Bundle”吗？没错，但里面门道可不少。签名不仅关乎安全，还跟包体积有直接关系。咱们先从最基础的概念讲起。

数字签名原理：到底签的是什么？

数字签名，说白了就是给文件贴一个“防伪标签”。你想想看，我们在商店买东西，包装上有个二维码扫码验证真伪。数字签名干的事类似——不过它更底层，用的是密码学。

具体怎么做的呢？我简化一下流程：

1. 哈希指纹：先把原始数据（比如 APK 里的所有文件）算出一个固定长度的哈希值。这个值就像文件的指纹，一点点改动都会让指纹完全不同。
2. 私钥加密：然后用你的私钥（Keystore 里那个）对这个哈希值进行加密。加密后的结果就是“签名”。
3. 打包输出：把签名连同原始数据一起放到 APK 里。

别人收到 APK 后，会拿你的公钥（包含在证书里）去解密这个签名，得到一个哈希值 A；同时自己重新算一遍文件的哈希值 B。如果 A 等于 B，说明文件没有被篡改，而且确实是你签的。简单吧？

Android 签名的目的：不只是防篡改

Android 系统为什么要强制签名？我刚开始学的时候觉得这步很多余——反正 APK 都是你发的，签个名还多一步。后来踩了坑才明白，签名主要有三大目的：

目的	作用	我印象深刻的事
身份认证	证明 APK 是由你（而非其他人）发布的	有一次我换了一台电脑打包，签名密钥没迁移，导致旧用户无法覆盖安装。用户骂我说“你的 App 被冒名顶替了”……
完整性校验	确保 APK 在传输过程中没有被中间人修改	某次从服务器下载的 APK 被运营商注入了广告，签名校验失败，直接拒绝安装。用户反馈“安装不了”，其实是运营商在搞鬼。
应用升级控制	同一个包名只能由同一个签名密钥更新	老项目换签名？那得先卸载所有旧版本，否则会提示“安装失败”。这坑我带着团队踩过两回……

所以你看，签名不是形式主义。它是 Android 安全和更新体系的基石。

签名与包体积的初步关系：你以为没影响？

这里就要引出咱们这门课的核心问题了：签名到底会不会增加包体积？答案是——会，但没你想象的那么多。

咱们来算笔账。APK 签名后会额外加入以下几样东西：

• 签名数据块（Signing Block）：包含数字签名、证书链、签名算法标识等。大小通常在 1KB 到 10KB 之间，取决于你用了几张证书。
• 签名分块文件（针对 v2/v3 签名）：会把原始文件按块签名，这些分块信息也会占空间，基本是几百字节到几 KB。
• ZIP 中央目录偏移：为了兼容 v1 签名，ZIP 结构会被微调，多出几个字段。

综合下来，签名本身带来的体积增加通常在 10KB ~ 50KB。对于动辄几十 MB 的 APK 来说，这点体积几乎可以忽略。但为什么有人觉得“签名后包变大了很多”？嘿嘿，那是因为签名和 AGP（Android Gradle Plugin）的配置一起玩了个花招——这咱们后面章节详细聊。我只透露一点：签名方式会影响资源对齐和压缩，从而间接影响最终体积。

手绘一张流程图：签名到底干了啥？

光说不练假把式。下面这张 SVG 图把签名和验证的完整流程画了出来，同时也标出了签名数据对包体积的贡献点。你可以保存下来，以后面试时随手画一遍——加分。