包体积优化小意外

前言

承接上篇 Android App 包体积变化史 ，继续对 Apk 文件的大小进行压缩。

意外收获

在以前 Android App 包体积变化史 的最后，咱们经过一些很是很是基础的配置，把一个 Hello World 版本的 Demo 工程打包出的 release Apk 文件由 2MB 压缩到了 865kb。

因为工做时间的关系就没有继续跟进。在这期间，Android Studio 4.0 正式版发布了，随之最重要的两个改变就是

• Gradle Android 插件的版本升级到了 4.0.0。
• Gradle 本地包装器的版本升级到了 6.1.1。

固然，Android Studio 4.0 更新的一些特性已有相关介绍，详细你们都看过这篇 Android Studio 4.0 稳定版发布了。

这两天把以前用来测试的项目从新在 Android 4.0 打开后，按照提示自动升级了上面提到的两个版本号，想着继续优化包体积，结果当打出 release apk 文件的时候，突然有了意外收获。

竟然只有 701kb 了。

这是发生了什么，难道哪天晚上在梦中作了优化本身忘了吗？赶忙回滚到升级 gradle 插件以前的版本打个包试试看。

仍是 865 kb 啊。发生了什么，两个文件对比一下。

Android 自带的 apk 比较工具备 bug 啊，😭😭。

不过没关系，咱们直接肉眼对比两张图，大概能够看出来，是编译后的 kotlin 文件夹变小了，从 103kb 直接减小到了 9.7kb,事实的确如此吗？是否是其余配置暗度陈仓产生的效果？

为了保险，反手就用 Android Studio 新建了一个如出一辙的 Hello World，用同一个 key 打包。

kotlin 文件夹只有 9.7KB 了。整个 apk 文件也只有 1.9MB 而已，再顺手跑个 debug 的包看看。

能够翻回去看看在 Android App 包体积变化史 的时候，kotlin 文件夹的大小怎么着也有 103kb 啊。这不是意外收获还能是啥？

至此，能够得出结论，在 Android Studio 4.0 版本中。

• Gradle Android 插件的版本升级到 4.0.0。
• Gradle 本地包装器的版本升级到 6.1.1。

会对包体积有明显的增益。

Google Android 团队牛逼 😏😏，Kotlin 牛逼。

一些说明：

• 期间 kotlin 插件版本版本没有变化，一直都是 1.3.72
• 从图中能够看到 classes.dex 文件由稍微的增加，是由于 core-ktx 的版本由 1.2.0 升级到了 1.3.0

资源压缩

回到正题，尝完了意外收获，是否是得一气呵成想一想还能干点啥，把包体积再压一压？看看现状

Github MinApp-V2.0.0

因为是 Hello World 版本，没有什么具体业务，classes.dex 已经作了混淆，暂时也想不出还有什么可作的了。

代码能够混淆，那么资源能够混淆吗？固然是能够的，已经有大佬在领先咱们好久以前就想到了这个问题，甚至已经把这个问题解决了,这就是很是有名的 AndResGuard。

按照他的说明文件，简单进行一下配置（因为是 Demo 工程，没有地方库相关配置，按照配置模板直接进行便可），执行 resguardRelease 命令打出 final.apk 文件。

能够看到已经减少到了 610 kb，出很少又压缩了 90 kb。这样的压缩比纯粹经过其余方式仍是比较费劲和耗费人力的。所以，不管是对代码，仍是资源，经过混淆的策略进行压缩是一件性价比很是高的事情。

总结

610 kb 是极限吗？显然不是。 这里仍然有压缩的空间，只是压缩到这种程度咱们就须要考虑投入产出比这件事情了。

一个 Apk 文件从真实的场景出发，是包含着全部业务逻辑和 UI 展示效果的集合包。Apk 文件越小，新用户越容易获取到。其实，除了一味地使用技术手段压缩，咱们还能够从业务角度出发，针对不一样的区域及受众作不到的定制，而不是一股脑的把全部要作的东西塞在一块儿，而后想着怎么作减法，这样势必会变成一个零和游戏，由于需求不止，需求的变化不止。

但同时从意外收获也能够看到，不少时候官方发力作某些事情的时候，会比咱们开发者本身作更有效率，以前使用 kotlin 致使包体积变大的时候，甚至讨论过要不要回到 java。可是，一旦 Android 官方听到广大开发者对于 kotlin 编译产物增大包体积的抱怨，而且开始亲自动手的话，效率是但是很是喜人的。

最后，包体积优化任重道远，路漫漫其悠远兮。