包体积优化小意外

3,494 阅读4分钟

前言

承接上篇 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 编译产物增大包体积的抱怨,并且开始亲自动手的话,效率是可是非常喜人的。

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