深入理解android 包体积优化，给apk瘦身全部技巧

Posted 2021-11-11 小松漫步时

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了深入理解android 包体积优化，给apk瘦身全部技巧相关的知识，希望对你有一定的参考价值。

前言

随着iphone13p最大内存放大到了1T，大内存手机的时代悄然降临，在android里面，三星也有，罗老师几年前说：如果我告诉你们我们在做1T的手机，你们可能以为我疯了。

看看现在，估计未来会有更多手机有1T版，大家开始真香了。

但是，如果现在有人说：要做一个1T大小的app，那他可能是真疯了，至少未来十年不可能。因为手机内存是越大越好，你一个app当然是能小就小呀

Android app的文件格式为apk，本文就是探讨对于一个android apk，有哪些方法可以减小体积

Apk组成

要想减小体积，首先我们需要了解apk的构成

我们写的.java文件会被编译为.class文件，再由dx工具编译为Classes.dex文件，由于android限制，每个dex文件最多65535个方法，所以多出来的方法就生成Classes2.dex , Classes3.dex~ClassesN.dex
Resource(res)与Assets比较像，区别是res目录下会生成资源ID，并在.R文件中记录，可以直接使用，这里平常我们用得很多，而assets不会有ID，而是通过AssetManager接口获取；

所以res类似于我们的桌面，一般放我们要操纵的控件资源，而assets类似于桌下的抽屉，放诸如数据库，html这类资源
Native Libraries平时打交道少，优化空间也很有限

上面是抽象的apk结构，下面我们看一个实际的

将qq.apk拖入android studio

可以看到最大的R文件夹，点进去，都是一些图片，第二大的是assets，里面是一些表情包以及插件图片

其他的我们刚刚也说过，值得注意的是，里面多了一个META-INF

他存放了应用的签名信息，其中

.MF: 每一个资源都有一个SHA1签名，存放在这里
.SF: 文件存放.MF经过base64编码后的签名
.RSA: 对.SF文件使用SHA1算法生成数字摘要（注意:.MF中是对每一个资源进行SHA1，这里是对文件），然后进行RSA加密，再用开发者私钥进行签名，安装时使用公钥解密

这样子，一个app安装在手机时，解密这一数字摘要，然后与内部的.MF文件比对，如果相符，证明资源内容没有被修改

Dex文件

在APK组成中我们可以看到，占用内存最大的是res，assets与classs.dex文件，这也是我们的优化方向，接下来，我们看看如何优化dex

首先我们看看dex的结构

更详细的版本在官网，这里如果对这些结构的作用有兴趣，可以看下图的详细版本

ProGuadrd

dex是代码编译而来，而对于代码文件，最重要的优化就是混淆了，将方法名，属性名等变为又短又无意义的名字，不仅能缩小体积还能避免反编译被人破解

在IDE中，我们可以看到qq里面的类都是小写字母，里面的变量和方法都按字母顺序排列了，从a开始

除了修改变量名，ProGuadrd还可以在功能等价的基础上重写代码，比如把多个函数调用写到一个函数里面去，更加增大了阅读理解难度（虽然初学者一般已经这样做了），以及打乱格式，增加空格等

主要步骤如下

压缩（Shrink）: 检测和删除没有使用的类，字段，方法和特性。
优化（Optimize） : 分析和优化Java字节码。
混淆（Obfuscate）: 使用简短的无意义的名称，对类，字段和方法进行重命名。
预检（Preveirfy）: 用来对Java class进行预验证（预验证主要是针对JME开发来说的，Android中没有预验证过程，默认是关闭）。

D8 与R8优化

这两平时接触不多，他们主要是在字节码处做优化的，开发时感知不强（感觉就是用来面试的）

D8主要是在编译字节码时重排序，将占用空间变得更小，比如对于greetingType方法，正常编译后的结果是

[000584] Main.greetingType:(LGreeting;)Ljava/lang/String;
0000: sget-object v0, LMain$1;.$SwitchMap$Greeting:[I
0002: invoke-virtual {v2}, LGreeting;.ordinal:()I
0005: move-result v1
0006: aget v0, v0, v1
0008: packed-switch v0, 00000017  // 这里

如果使用D8优化，编译后的结果

[0005f0] Main.greetingType:(LGreeting;)Ljava/lang/String;
0000: sget-object v0, LMain$1;.$SwitchMap$Greeting:[I
0002: invoke-virtual {v1}, LGreeting;.ordinal:()I
0005: move-result v1
0006: aget v0, v0, v1
-0008: packed-switch v0, 00000017  //  这里
+0008: const/4 v1, #int 1
+0009: if-eq v0, v1, 0014
+000b: const/4 v1, #int 2
+000c: if-eq v0, v1, 0017

可以看到 0008处后的几条指令有变化，多了几个if，对于不同的case做创建不同的变量，可以节省空间

R8也类似，只是策略有些不一样

更详细的了解可以参考 D8 Optimizations

总之，他们的作用是就是，在不改变功能的情况下，重写部分class指令，减小空间占用，但是有可能会增加指令数量

Redex优化

Redex是Facebook推出的一个优化Dex文件的工具，和D8R8一样，也是对字节码的处理，有以下效果

内联函数，减少调用
删除无用代码
将只有一个实现类的接口或者父类用实现类代替
字符串混淆所见

……

不过这个我没用过，但是感觉Proguard与D8R8都多多少少能做到，可能是他在细节上用了更好的算法

但是不管多少框架，对dex文件的优化说来说去也就这些

移除多余的库与代码

最后是移除第三方库和冗余代码，属于业务逻辑上的原因

多余的库

对于自己的小项目，还好，对于多人参与的大型项目，很有可能对同一个功能，不同的人用了不同的轮子，手Q里面就有，比如要写单测，之前使用Powermock，后来用JMock，再后来改为Mockk，一个项目，三个单测框架

由于不同的单测框架已经写了不少单测，短时间移除是不太可能的，但是可以慢慢转为同一种单测框架
多余代码

Android studio会自己检测，没有用过的会置位灰色提醒，但是会漏掉很多，通过插件Lint可以检测，

资源清理

上面都是在代码层面减小dex，apk的另一个空间占用大户，是资源，尤其是其中的图片，

图片，你可知道，多少OOM因你而起？多少app因你闪退？

图片压缩与更换格式

我们先看看图片为什么那么大

图片的显示，有ARGB 4个通道，其中默认的显示模式是ARGB8888，ARGB8888表示每个通道的颜色区间为[0,255]，也就是两个16进制数表示，也就是8bit -> 1字节

所以ARGB8888模式下，一个像素4个通道下占用4字节，一张1024*1024的手机图片图片，就是
$2^{10} * 2^{10} * 2^2 = 2^{22} = 4M$
一张图4M，太离谱了！

上面是打开后在运存的占用，我们可以修改颜色通道，不然ARGB565来减小单个像素所占用运存，不过有点跑题，本篇我们讲的是app的大小，也就是所占用手机的内存（我们约定手机运存 = 电脑内存，手机内存 = 电脑硬盘）

内存与运存中的图片存在形式是不一样的，压缩方法也不一样，很多人容易弄混

回到内存，内存中，图片是以png，jpg等格式存储

我之前开发的时候都是先将png图片，往tinypng网站中压缩一下再放入，所以可以压缩图片，一般能压个三分之一~三分之二。

也可以更换图片格式，比如webp，svg可以更小，android studio也提供了对应的支持，但是没有最好的格式，只是适用场景不同

👇

这里多提一下webp，因为这是google推出的，大家在谷歌浏览器下载图片的时候，一般默认下载下来就是webp格式，所谓更小的内存占用，本质上是对图片进行了压缩，webp的压缩算法是VP8视频编码，核心逻辑就是将图片分割成更小的子块，然后预测周围像素值，预测越准，周围的像素值就可以删去，再在图片打开时算出删掉的像素