Android APK瘦身全面总结——如何从32.6M到13.6M

Posted 2020-09-08 我就是马云飞

前言

之前我简单介绍了关于svg图片瘦身的问题，在公司，瘦身这个问题是我提出来的，所以这锅我背了。公司项目是32.6M，我给自己的要求就是低于20M。上周花了一个星期瘦身，至于为什么花了一周，主要是svg适配问题我被搞蒙蔽了。然后发现还要改大量代码，想想也就算了，又换了另一种瘦身方法。
很多人是因为这标题而来的，怎么可能，32.6M的居然可以变成13.6M。下面容我慢慢道来。

APK结构介绍

classes.dex

classes.dex是Java源码编译后生成的java字节码文件。但由于android使用的dalvik虚拟机与标准的java虚拟机是不兼容的，dex文件与class文件相比，不论是文件结构还是opcode都不一样。目前常见的java反编译工具都不能处理dex文件。Android模拟器中提供了一个dex文件的反编译工具，dexdump。用法为首先启动Android模拟器，把要查看的dex文件用adb push上传的模拟器中，然后通过adb shell登录，找到要查看的dex文件，执行dexdump xxx.dex。另，有人介绍到Dedexer是目前在网上能找到的唯一一个反编译dex文件的开源工具，需要自己编译源代码。

clases2.dex

同上，上面的是对你的java文件的编译，这个是对你所导入的jar文件的编译。

resources.arsc

编译后的二进制资源文件

AndroidMainfest.xml

该文件是每个应用都必须定义和包含的，它描述了应用的名字、版本、权限、引用的库文件等等信息，如要把apk上传到Google Market上，也要对这个xml做一些配置。

assets

assets目录可以存放一些配置文件（比如webview本地资源、图片资源等等），这些文件的内容在程序运行过程中可以通过相关的API获得。

lib

lib目录下的子目录armeabi存放的是一些so文件。这个地方多讲几句，都是在开发过程中摸索出来的。eclipse在打包的时候会根据文件名的命名规则（lib**.so）去打包so文件，开头和结尾必须分别为“lib”和“.so”，否则是不会打包到apk文件中的。其他非eclipse开发环境没有测试过。如果你是用SDK和NDK开发的话，这部分很重要，甚至可以通过把一些不是so文件的文件通过改名打包到apk中，具体能干些什么那就看你想干什么了！

META-INF

META-INF目录下存放的是签名信息，用来保证apk包的完整性和系统的安全。

Res目录

这是我们存放xml drawable string color等等一些资源文件。

32.6M——13.6M

首先，我先声明下，不然我怕会被打，目前13.6M的还在测试中，因为机型问题，目前没法测试。现在稳定包的大小是在19.8M——20.4M。

混淆和去除无用资源

在gradle使用minifyEnabled进行Proguard混淆的配置，可大大减小APP大小

删除无用图片资源

我们公司项目到现在逸代了2年了。可想而知，代码的冗余太多了。版本更新会导致很多资源用不到，然后依旧存在包中。这事我是交给老大的做的，毕竟项目他最熟。于是乎删了差不多100多张图片。因为做了图片适配。所以删除的图片资源差不多是在400张的样子。这样。我们的app包从32.6M变成了26.8M。记得刚打包测试的时候，测试经理来个句。你们这包不对啊，怎么少了6、7M。然后就回了是正常的，说我这边搞完差不多会在20M左右。测试经理：什么？在瘦个20M。这么夸张。我：……..好了，不扯了，跑题了。

删除无用resource资源

这个和上面的肯定不一样的。我这边主要还是指xml。首先，我们需要点击Analyze——>Run Inspection by Name…

继续输入：unused resource

直接点ok，然后等待：

看来公司项目还能少个300k~。你们对比着你们的项目一个个的删就行了。

图片瘦身之熊猫大法

前面我也说了。用svg适配改的代码量太大了。于是乎我转用了熊猫瘦身，也就是tinypng。官方网站：https://tinypng.com。下面我从官网给大家介绍下tinypng：

TinyPNG有什么作用？

TinyPNG使用智能有损压缩技术来减小 PNG文件的文件大小。通过选择性地减少图像中的颜色数量，需要较少的字节来存储数据。效果几乎不可见，但它使文件大小有很大的差别！

为什么要使用TinyPNG？

PNG是有用的，因为它是唯一广泛支持的格式，可以存储部分透明的图像。格式使用压缩，但是文件仍然可能很大。使用TinyPNG缩小您的应用程序和网站的图像。它将使用更少的带宽和更快的加载。

它是如何工作的？

当您上传PNG（便携式网络图形）文件时，图像中的相似颜色会合并。这种技术被称为“量化”。通过减少颜色数量，24位PNG文件可以转换为更小的8位索引彩色图像。所有不必要的元数据也会被删除。结果：更好的PNG文件100％支持透明度。有你的蛋糕，吃它了！

它支持到处吗？

TinyPNG生成的文件在所有现代浏览器（包括移动设备）上完美显示。仍然需要支持Internet Explorer 6？它通常忽略PNG透明度并显示实心背景颜色。使用TinyPNG的背景变得透明了。二进制透明度没有任何解决方法！

你为什么创建Tinypng？

我们经常使用PNG图像，但对加载时间感到失望。我们创建TinyPNG在我们的使命，使我们自己的网站更快，更有趣的使用最好的压缩。在2014年，我们添加了JPEG图像的智能压缩，并在2016年，我们添加了对动画PNG的支持。

使用方法

我们看到官网的介绍，在这边上传你的jpg或者png 一次最多20张，每张最大5MB。接下来我们随便来个测试：

从1.4M变成570k。缩了60%。可想而知，熊猫的强大。想要一次上传全部，这tm就尴尬了。一年25美元。你们可以让你们的UI给你们图片的时候就用Tinypng压缩在发过来。不过有的公司就给你个设计稿。那就得自己亲自下手咯~

熊猫大法VS SVG大法

我对比了熊猫和svg的压缩，前者app’大小是在20.4M，后者是在19.8M。下面上图给你们对比下：

19.8M——13.6M

前面我也说了，这个目前还在测试机型。所以稳定性还没保证。先说说是如何做的把。我们公司项目用到了百度地图SDK。所有用到了so库。

当然我这边只是部分。下面我是搜到了一些关于这些so库的介绍：

mips、armeabi、armeabi-v7a和x86到底是什么

mips：MIPS是世界上很流行的一种RISC处理器。MIPS的意思是“无内部互锁流水级的微处理器”(Microprocessor without interlocked
piped stages)，

其机制是尽量利用软件办法避免流水线中的数据相关问题。

armeabi：默认选项，将创建以基于
ARM* v5TE 的设备为目标的库。 具有这种目标的浮点运算使用软件浮点运算。 使用此 ABI （二进制接口）

创建的二进制代码将可以在所有 ARM* 设备上运行。所以armeabi通用性很强。但是速度慢

armeabi-v7a：创建支持基于
ARM* v7 的设备的库，并将使用硬件 FPU 指令。armeabi-v7a是针对有浮点运算或高级扩展功能的arm v7 cpu。

x86:支持基于硬件的浮点运算的
IA-32 指令集。x86是可以兼容armeabi平台运行的，无论是armeabi-v7a还是armeabi，同时带来的也是性能上的损耗，

另外需要指出的是，打包出的x86的so，总会比armeabi平台的体积更小。

小结

如果项目只包含了 armeabi，那么在所有Android设备都可以运行；
如果项目只包含了 armeabi-v7a，除armeabi架构的设备外都可以运行；

如果项目只包含了 x86，那么armeabi架构和armeabi-v7a的Android设备是无法运行的； 如果同时包含了 armeabi， armeabi-v7a和x86，

所有设备都可以运行，程序在运行的时候去加载不同平台对应的so，这是较为完美的一种解决方案，同时也会导致包变大。

所以，这个还是需要根据用户的机型来判断，目测我这边还在测试中，如果没问题。大小基本就在13.6M左右了。

总结

我们需要对APP瘦身的时候需要了解他的结构，就像我第一次做瘦身的时候，虽然解决了，不过对各种问题都是属于一脸蒙蔽的情况。所以，我们需要要了解apk包下每个文件都是干嘛的，做了什么，是否有用。只要你用心去做，就一定可以解决。就像我当初给自己的目标是小于20M一样。虽然现在和20M差不多。不过如果那边测试可以通过。那便是13.6M而不是20M。希望我的方法能帮助到你们。欢迎讨论~~~