升级Android Studio至3.0后APK体积从8.9M增至10.1M，原因何在？

嘿，这个问题我之前帮不少开发者排查过，AS 3.0相比2.3.3确实有不少默认配置的变化，直接导致了APK体积上涨，我整理几个最常见的原因：

• D8 Dex编译器默认启用：AS 3.0开始把D8作为默认的Dex编译工具，替代了旧的DX。虽然D8在编译速度和运行时性能上更优，但3.0刚推出时的早期D8版本，生成的dex文件体积可能比DX略大——尤其是项目里用到较多Java 8特性或者复杂类结构的时候。后续D8版本优化了体积，但3.0初期这个情况很普遍。

• Support库自动升级：AS 3.0会默认把项目里的Android Support库升级到对应版本（比如从25.x升到26.x）。新版本的Support库往往添加了更多功能、修复了bug，代码量自然会增加，直接导致classes.dex的体积上涨。

• R8混淆器的初期适配问题：AS 3.0开始引入R8作为ProGuard的替代方案。虽然R8最终能生成更小的APK，但如果是从ProGuard切换过来，初期可能没适配好R8的混淆规则，导致混淆不彻底；而且3.0版本的R8还处于早期阶段，默认配置的压缩效率可能不如成熟的ProGuard，反而让体积变大。

• APK签名Scheme v2默认启用：AS 3.0默认使用更安全的APK Signature Scheme v2签名方式，这种签名会在APK中添加额外的签名块，虽然安全性提升了，但会增加几百KB到1MB左右的体积，具体大小取决于APK本身的内容。

• AAPT2资源编译工具的变化：AS 3.0默认启用AAPT2来处理资源，它在资源编译效率上更高，但早期版本的AAPT2在资源压缩（比如PNG图片压缩）上可能不如旧版AAPT，或者对某些资源格式的处理逻辑变化，导致资源文件体积增加。

排查小技巧 #

如果你想定位具体原因，可以试试这些方法：

• 用apktool反编译两个版本的APK，对比classes.dex、res文件夹、lib文件夹的大小变化，看哪部分是体积上涨的主力。
• 检查build.gradle里的Support库依赖，手动降回2.3.3时的版本，重新编译看体积是否回落。
• 在gradle.properties中添加android.enableD8=false，切换回DX编译器，对比体积差异，确认是不是D8的问题。
• 在build.gradle的签名配置里指定只使用v1签名（v1SigningEnabled true，v2SigningEnabled false），看看体积是否减少。

内容的提问来源于stack exchange，提问作者Martin Yu