Google I/O 2016 笔记：APK 瘦身的正确姿势

小咪咪 2022-09-23 15:58 3阅读 0赞

作者：Caspar  
链接：https://zhuanlan.zhihu.com/p/21543787

业务逻辑不断累积、引入的第三方 SDK 不断增加以及图片资源不变变大，APK 瘦身已经是每个 Android 应用开发者不得不考虑的问题了（[iOS 应用也有瘦身的问题，但相比之下 Android 应用的瘦身压力大得多][iOS _ Android]）。坊间流传的各种瘦身方法有些切实可行，有的却流毒甚广。不妨结合这届 I/O 的两个相关 topic 来学习下 APK 瘦身的正确姿势。

想更详细了解的同学可以过一下这两个 topic 的 video：

[Image compression for Android developers][]

[Lean and fast: Putting your app on a diet][Lean and fast_ Putting your app on a diet]

## **先来看下图片压缩有关的问题** ##

VD 千般好，但无奈换用它的成本略高，此次先不讨论。

WebP, PNG , JPG 三者的选择可以借助下图来判断：

![2110e88e4ee0804f32e7cb0850c31675_b.png][]

如果只需要考虑 Android 4.0+, WebP 是个不错的选择，同画质下体积更小（在生产环境中使用最好谨慎些，在第三方 Rom 上多测试下）。PNG--> WebP 的格式转换十分简单：

> brew install webp

![bad6db80cbdedf6320943d660f413dc6_b.png][]

对于 PNG 和 JPG，在按上面的流程图选择正确的类型后还需要进行一个步骤：压缩，这也是很多开发者忽略的一点。

个人最喜欢的图片压缩工具是 [ImageOptim][]，集成了很多好用图片压缩库：

> [ImageOptim][ImageOptim 1] by Kornel Lesiński and contributors is a GUI for 3rd party utilities:
> 
>  *  [OptiPNG][] by Cosmin Truta,
>  *  [PNGCrush][] by Glenn Randers-Pehrson,
>  *  [Zopfli][] by Jyrki Alakuijala, Lode Vandevenne,
>  *  [AdvPNG][] by Andrea Mazzoleni, Filipe Estima,
>  *  [Jpegoptim][] by Timo Kokkonen,
>  *  [Gifsicle][] by Eddie Kohler,
>  *  and [PNGOUT][] by Ken Silverman.

值得一提的是，借助 [Zopfli][]，它可以在**不改变 PNG 图像质量**的情况下使图片大小明显变小，看疗效：

![816a6dda556570876282e4650034e6a6_b.png][]代价是压缩速度比较慢，不过从效果看，等待是值回票价的。

[ImageOptim][] 的默认设置已经能获得不错的效果。但如果需要进一步压缩（有损压缩），我们需要做出一个抉择：我们可以牺牲多少图片质量？

回答这个问题需要先回答另一个问题，如何量化两张图片在视觉上的差别（psychovisual similarity of two images）。Google 提供了一个工具进行这种量化：[butteraugli][] . 有兴趣的同学可以尝试一下

最后需要注意的是在生成 APK 时，aapt 默认会进行一些图片压缩的操作，但效果并不是太好。鉴于我们已经自己进行了这一步，相应的将 aapt 的相关操作跳过：

![cecd8f32867bd61073335b1c44d93e6f_b.png][]如果不跳过，aapt 并不知道图片已经压缩过了，就会出现上图中图片经过 aapt 处理大小反而变大的情况。

## **resources.arsc 和 .so** ##

resources.arsc 中存储的是资源 ID 和资源名称的对应关系。从下图中可以看到在正常情况下这个文件在 apk 中是非压缩性存储的。然后就有好多文章和工具（真的是好多…）出于 APK 瘦身的目的，压缩了这个文件。看起来没有问题，但这其实确实不是一个好主意……

![110515b78db12a8343fbd5b686de8fad_b.png][] **resources.arsc 在 APK 安装之后仍需要被频繁的读取，如果将它进行压缩，在每次读取前系统都必须进行解压的操作**，从性能上考量这显然是得不偿失的。所以，赶紧摒弃通过压缩 resources.arsc 来给 APK 瘦身的方法吧。

resources.arsc 正确瘦身方式是删除不必要的 string entry. 借助 [android-arscblamer][] 可以检查出可以优化的部分 ( eg. Null Entries )

![5247ba8320bafcc558b1f8711cfc5ef2_b.png][]

Android 6.0 之前，在安装 APK 时，.so 会按照一定的逻辑被从 APK 中复制出来，这一流程也[引入了一个长年大坑][Link 1]，掉坑者无数。从下图中我们可以看到 APK 安装后占用空间的情况。可以看到 解压后的 .so 这部分空间其实是可以省去的。

![a5b7fc91566dcbc34ed94b1fbeeec632_b.png][]

Android 6.0+ 后 .so 在安装中终于不用再复制出来，从而减少 APK 安装后对空间的占用，也避免了安装时由于 .so 拷贝失败导致的各种诡异的错误。

Android Studio 中只要做如下声明，在 Android 6.0+ 中就可以避免 .so 的拷贝了。需要指出的是，默认情况下，声明后所有 .so 都会非压缩性存储在 APK 中。希望不会再有不靠谱的 APK 瘦身工具对它们再动手脚。  
![e2ee35b86e9c5fa557e069dcc280401c_b.png][]

此外，从 Android Nougat ( API 24 ) 开始，系统[不再以整个 DEX 为粒度进行 AOT ][DEX _ AOT]也在一定程度上减少了 APK 安装后的体积占用。

最后要提一下，上面说过 resources.arsc 和 .so ( 6.0+ ) 都应该保持非压缩存储。但这显然会导致**原始 APK 大小 ( Raw APK Size)** 的增长。这里 Goolge 还另外提及了两个纬度：**下载大小 ( Download Size )** 和 **安装后大小 ( Installed Size )**。如果从 Google Play 下载，下载大小是要小于原始 APK 大小的。这是由于 Google Play 对 APK 进行了压缩传输，和增量更新 ( 通过 binary diff ) 。可惜，不是每个第三方市场都做了这两点，摊手。下载大小作为应用开发者无法控制，但原始 APK 大小和安装后大小则是我们必须要考虑的问题。

Android

[iOS _ Android]: https://www.zhihu.com/question/37321029/answer/93666703
[Image compression for Android developers]: https://link.zhihu.com/?target=https%3A//events.google.com/io2016/schedule%3Fsid%3D8c2d2aeb-0bef-e511-a517-00155d5066d7%23day1/8c2d2aeb-0bef-e511-a517-00155d5066d7
[Lean and fast_ Putting your app on a diet]: https://link.zhihu.com/?target=https%3A//events.google.com/io2016/schedule%3Fsid%3Dd4c824f1-0bef-e511-a517-00155d5066d7%23day1/d4c824f1-0bef-e511-a517-00155d5066d7
[2110e88e4ee0804f32e7cb0850c31675_b.png]: /images/20220720/a2700d6780c44701ad62c48b58b75aa5.png
[bad6db80cbdedf6320943d660f413dc6_b.png]: /images/20220720/429c8bd7558c42f4b57997273e96a9d8.png
[ImageOptim]: https://link.zhihu.com/?target=https%3A//imageoptim.com/mac
[ImageOptim 1]: https://link.zhihu.com/?target=http%3A//imageoptim.com/
[OptiPNG]: https://link.zhihu.com/?target=http%3A//optipng.sourceforge.net/
[PNGCrush]: https://link.zhihu.com/?target=http%3A//pmt.sourceforge.net/pngcrush/
[Zopfli]: https://link.zhihu.com/?target=https%3A//code.google.com/p/zopfli/
[AdvPNG]: https://link.zhihu.com/?target=http%3A//advancemame.sourceforge.net/doc-advpng.html
[Jpegoptim]: https://link.zhihu.com/?target=http%3A//www.kokkonen.net/tjko/projects.html
[Gifsicle]: https://link.zhihu.com/?target=http%3A//www.lcdf.org/gifsicle/
[PNGOUT]: https://link.zhihu.com/?target=http%3A//www.advsys.net/ken/utils.htm
[816a6dda556570876282e4650034e6a6_b.png]: /images/20220720/ba32673fc49b49eeb11d413c2d58834a.png
[butteraugli]: https://link.zhihu.com/?target=https%3A//github.com/google/butteraugli
[cecd8f32867bd61073335b1c44d93e6f_b.png]: /images/20220720/f039b42012a0447eb3c8ab6067f528ff.png
[110515b78db12a8343fbd5b686de8fad_b.png]: /images/20220720/80627ecfdb924035a36a878341fdc426.png
[android-arscblamer]: https://link.zhihu.com/?target=https%3A//github.com/google/android-arscblamer
[5247ba8320bafcc558b1f8711cfc5ef2_b.png]: /images/20220720/f4bab638b4134b14900fb8577a86d1f1.png
[Link 1]: https://zhuanlan.zhihu.com/p/21359984
[a5b7fc91566dcbc34ed94b1fbeeec632_b.png]: /images/20220720/94c6aa8eecb240e3883a3b97c91876ed.png
[e2ee35b86e9c5fa557e069dcc280401c_b.png]: /images/20220720/112ddeb05bac4a8f867ed9935c17be57.png
[DEX _ AOT]: https://www.zhihu.com/question/41206642/answer/90093139