minSdk 从 26 升到 31 ，打包体积变大3倍 ，packaging dex 了解一下

minSdk 从 26 升到 31 打包体积变大3倍1. 先分清三个「大小」很多人一看到几十 MB 的.apk就慌先建立三个概念概念大致含义谁在看APK 文件大小你在资源管理器里看到的文件体积本质是ZIP 包你传文件、看磁盘ZIP 里每项「未压缩大小」各文件「真实字节数」zip 里可压缩或未压缩分析工具 / 脚本装到手机后的占用系统解压、优化dex/oat后的结果和 APK 不总一致用户「存储空间」学什么优化「下载/拷贝」时往往盯 APK 文件优化「手机里占多少」有时要看安装后数据。APK 变大 ≠ 业务代码突然多了几万行。2..apk本质上是一个 ZIP双击改后缀或用解压软件打开你会看到类似classes.dex,classes2.dex, … ——应用代码Kotlin/Java 编译结果lib/abi/xxx.so——原生库JNI视频解码等常在这里面resources.arsc、res/——资源AndroidManifest.xml二进制形式等学什么想查「体积从哪来」可以先看哪几个 dex / 哪几个 .so 最大。3. Debug 包为什么常比 Release「显胖」常见原因包括不必全中你的项目可能只占其中几条默认不开代码压缩minifyEnabled/ R8 关掉时没用到的类也会打进 DEX。**debugImplementation**只在 debug 变体里打进包的工具例如 Compose 的ui-toolingrelease 里没有。调试信息符号、行号等会让 DEX 略大。但Debug 不是唯一原因。有时Release 也没开混淆那 debug/release 的代码体积差距会缩小真正「从 25MB 飙到 75MB」也可能是下面第 6 节的情况。4. 依赖库是最大的常客带视频播放 / 大屏展示的 Android 应用典型的大头有Jetpack Compose Material3UI 框架本身 运行时。**material-icons-extended**成套图标体积很容易涨一截若只用了少数图标可考虑改成只依赖需要的子集或改用material-icons-core 按需资源。Media3 / ExoPlayer播放器、解码相关常带native.so多 ABI 会成倍増大未单独拆包时。学什么同样的业务依赖选得「重」APK 就容易大这和「多写了几行业务 Kotlin」通常不在一个数量级——后者往往只有几 KB 量级。5. 一次小迭代与体积几乎无关某次改动里增加了设备标识相关的读取逻辑、与后台交互的展示名字段默认值、以及少量网络相关权限声明。这些对DEX 体量影响极小不会单独解释「25MB → 75MB」这种量级。6. 本案例的关键发现为什么「旧备份」约 25MB当前约 75MB6.1 对比两份工程配置两份工程的app/build.gradle.kts里依赖列表几乎一模一样。唯一明显的默认配置差异旧备份**minSdk 26**当前**minSdk 31**。6.2 对比两个已经打好的app-debug.apk用脚本或工具看ZIP 里每个classes*.dex的「压缩后大小」和「未压缩大小」旧备份 APKCompressedLength明显小于原始长度 → DEX 在 ZIP 里被压缩存储。当前 APK多数 dex 的CompressedLength 原始长度→ DEX 在 ZIP 里不压缩STORED。再算一遍 ZIP 内所有条目的「未压缩字节总和」两份其实在同一个量级约七千多万字节说明装进包里的代码/资源体量相近差的是压缩与否反映在「文件体积」上。6.3 官方行为你要记的结论Android Gradle PluginAGP的约定大致是当**minSdk 28** 且未另行设置时默认把 APK 里的 DEX 以不压缩方式放入 ZIP利于安装与运行时的映射等考量。**minSdk较低**例如 26时更容易仍走压缩 DEX的旧习惯于是同一个依赖、同量级代码你看到的APK 文件却可能小很多。所以不是「开了 debug」单独造成的落差而是**minSdk抬高后触发了 DEX 在 APK 内的默认打包策略**再叠加第 4 节的大依赖文件看起来就特别胖。7. 若你希望「APK 文件」再次接近小体积例如只侧传 APK在**app/build.gradle.kts** 的android { }里可以增加与现有packaging合并即可packaging{dex{useLegacyPackagingtrue}}含义让 DEX 按「旧习惯」在 APK 里被压缩文件往往明显变小。取舍与细节以 DexPackagingOptions 及 AGP 发行说明为准若走Google Play 的 AAB处理不完全等同本地 APK。分发体积还会由 Play 再8. 若想系统性「减肥」进阶路线可以按顺序尝试每项改完打 release、真机测核心业务流程Release minifyEnabled true 写好 Proguard 规则Kotlin/Compose/反射/XML 要测全。**shrinkResources true**配合 minify。拆分 ABIabiFilters或上架用 AAB避免「一台机器只跑 arm64却打进去 x86」。审视**material-icons-extended** 是否可瘦身。查阅 Media3/ExoPlayer 文档按需模块避免引入不需要的解码器。9. 你可以自己动手的小练习用解压软件打开app-debug.apk按文件大小排序记下最大的 5 个条目。把当前工程的minSdk临时改成26仅本地试验clean 后重装打 debug对比 APK 文件大小理解后请改回你产品需要的minSdk。加上第 7 节的useLegacyPackaging true再对比一次 APK 大小。10. 一页纸总结APK ZIP大头常在DEX和**.so**。Debug会多一些调试向依赖但不是本次「25 vs 75MB」的主因。同依赖、同代码量级下**minSdk从 26 升到 31** 会触发DEX 在 APK 内默认不压缩文件体积陡增和手机里「逻辑体积」不是一回事。少量业务逻辑改动不会让包突然大几十 MB。要小文件可考虑**dex { useLegacyPackaging true }**再配合混淆、资源收缩、ABI 拆分做长期优化。基于同一应用「旧备份工程」与「当前工程」的配置对比以及对两份 debug APK 内 ZIP 条目的检查整理方便日后遇到「包怎么变大了」时能按步骤自查。