开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 26 天，点击查看活动详情

前言

我们工作上开发经常也遇到各种各样的问题，今天我们开发组的大哥就发现一个问题，他在打包完提测时发现我们的APP包体积变大很多，于是我们就探讨了这个问题出现的原因。

正文

情景是我们的oppo推送和vivo推送要接入，于是老大把需求给了我们开发组大哥，但大哥在完成需求后，在蒲公英提测时却发现我们的包体积比之前大了一半多，而我们的APK中并没有加什么占体积的功能代码，于是他就开始寻找原因。

首先，当然是从他的需求对代码的改动上找原因，仔细一琢磨，应该是我们的Gradle配置上有变更，因为vivo推送的接入文档要求我们这边minSdkVersion的最小为23，而我们之前是21，所以代码做了变更来适配，好，这时其实原因已经找到了一半，罪魁祸首最终我们也发现确实是这个变动，是它带来的包体积变化，但当然也不可能就是改个数字就能增大体积，这里还一定有相关变化出现。

在网上检索了minSdkVersion的最小为23导致APK包体积变大后，很快我们锁定了原因，其实这之前我们大哥已经知道是因为我们的so库，JNI没有压缩导致了包体积变大了，但我也搜到了相关的文章（Android M 的 NDK 行为变更对 APK 包体积的影响 | Welcome to sunzn's Blog），这篇文章让作者本人了解了事情的原委。

我们的开发项目用到了Native开发，其中的so库在打包时如果是之前的minSdkVersion（小于23）就会生成APK时去压缩so库，而如果大于等于23就会默认不去压缩so库，而其中的变化就是一个清单文件的属性android:extractNativeLibs，在23后，如果开发者不主动将其设置为true的值注入清单文件，那打包时就会默认给这个属性添加false，而这个属性的设置不同就会带来不同的结果，其中最明显的就是我们的APK体积的显著提升：

此外，根据相关资料的显示，这个变动早在2015就出现了，只是当时大家的最低版本要求一般都为了兼容而选择小于了23，所以关注度并不高，而在如今的2023，相信大家都要上升到大于等于23的minSdkVersion了，随之而来的困惑也就越来越多。

最后，其实大哥仍然没有选择去压缩so库的对应设置属性，可能是担忧这个属性所带来的其他影响，不过这一点我是不清楚了。

总结

本篇是一个日常开发的小记，也是算我们开发中遇到问题所记录的相关原因，方便作者后续忘却时再回顾。