什么是 zipalign？为什么在签名前必须执行 zipalign？
解读
面试官抛出这道题，核心想验证三件事：
- 你是否真正打过正式包（很多候选人只跑过 debug，没走完整发布链）；
- 对 Android 安装包结构的理解深度；
- 对“对齐”与“签名”顺序背后安全与性能逻辑的掌握。
国内大厂与中小厂都把包体积、启动速度当成核心 KPI，答不出 zipalign 的本质，会被直接判定为“只调 API 的搬运工”。
知识点
- zipalign 是 Google 官方提供的对齐工具，位于 SDK/build-tools/版本号/zipalign，作用是把 APK 内部所有未压缩资源（如 .so、.png、.mp3）按照 4 字节边界对齐。
- 对齐后，资源在 APK 文件里的偏移量 mod 4 == 0，运行时 mmap 可直接按页映射，避免运行时二次拷贝，降低 PSS 内存并提升 I/O 效率。
- 签名（apksigner 或 jarsigner）会在 ZIP 的 Central Directory 与每个 Entry 插入签名块；若先签名再对齐，对齐过程会重排 Entry 偏移，导致签名摘要失效，安装时提示“INSTALL_PARSE_FAILED_NO_CERTIFICATES”。
- 国内多渠道包（Walle、VasDolly、ApkChannelPackage）依赖在 APK Comment 区或 ID-value 区写入渠道号，必须在 zipalign 与签名之后插入，否则同样会破坏对齐或签名。
- 从 Android 11（R）开始，系统对未对齐 APK 会在安装阶段强制做对齐校验，未对齐直接拒绝安装，日志关键字“ZIP_ALIGNMENT_FAILED”，因此无论 targetSdk 多少，都必须对齐。
- AAB（Android App Bundle）交给 Google Play 后，由 Play 在服务器端按 ABI/密度拆分成 APK，拆完后服务器会自动再做一次对齐，但本地上传前的 AAB 本身仍需对齐，否则 bundletool 在本地 generate-apks 阶段会报警告。
答案
zipalign 是 Android 官方提供的 4 字节对齐工具，它通过重排 APK 内未压缩资源的偏移，使所有资源起始地址落在 4 字节边界。
运行时系统利用 mmap 按页映射这些资源，可减少 RAM 消耗并加快加载速度；同时，对齐后的文件在读取时不会触发内核的页对齐修复逻辑，降低 CPU 占用。
由于签名机制会对每个 ZIP Entry 的偏移量做摘要，一旦先签名后对齐，偏移被改动就会导致签名验证失败，因此规范流程必须是：
编译 → 混淆 → zipalign → 签名 → 多渠道写入。
国内各大应用商店与终端厂商 OTA 升级系统均会校验对齐标志，未对齐 APK 会被拒绝安装或后台统计扣分，所以 zipalign 是发布包不可跳过的必经步骤。
拓展思考
- 如何验证对齐是否成功？
命令行：zipalign -c -v 4 existing.apk，输出“Verification succesful”即通过；若出现“BAD - alignment is 2”，说明未对齐。 - 为什么 4 字节而不是 8 字节或 16 字节？
ARM32 时代 4 字节就能满足内存总线对齐；ARM64 虽支持 64 位，但 4 字节对齐已足够覆盖主流 SoC 的缓存行与页大小，Google 保持兼容未改。 - 使用 R8/ProGuard 的“fullMode”时，代码被高度内联，可能导致 .so 体积增大，对齐收益更明显；此时若跳过 zipalign，启动阶段 mmap 缺页中断（major page fault）会增加 5–10%，在低端机上冷启动耗时差距可达 80–120 ms，可直接左右大厂启动速度灰度实验的 p50 指标。
- 国内某些加固厂商会先加壳再对齐，顺序变为：编译 → 混淆 → zipalign → 加固 → 二次 zipalign → 签名。二次对齐是为了保证加壳后的 libshell.so 也落在 4 字节边界，否则部分加固版本在 Android 14 上会因对齐失败触发系统 abort。
- 未来 Android 可能引入 16 KB 页大小（Pixel 8 已实验），届时对齐粒度可能从 4 字节提升到 16 字节，但 zipalign 工具会保持向下兼容，开发者只需升级 build-tools 即可，无需改动构建脚本。