APK瘦身记，如何实现高达53%的压缩效果

 

我是怎么思考这件事情的

APK是Android系统安装包的文件格式，关于这个话题实际上是一个老生常谈的题目，不管是公司内部，仍是外部网络，前人前辈已经总结出不少方法和规律。不过随着移动端技术近两年的飞速发展，一些新的思惟方式和优化方法也逐渐涌现和成熟起来。笔者在实践过程当中踩过一些坑，收获了一些经验，在这里作个思考和总结，因此随笔给你们，但愿对你们从事相关工做的时候有所帮助和参考，同时也是抛砖引玉，但愿你们共同探讨这个开放性的话题。

关于为何APK要瘦身，这个很少说，只从三个方面唠叨一下，对于用户（或者客户）来讲，APK越大，在下载安装过程当中，他们耗费的流量会越多，安装等待时间也会越长；对于产品自己，意味着下载转化率会越低（由于竞品中，用户有更多机会选择那个体验最好，功能最多，性能最好，包最小的）；对于研发来讲，是一种优化改进技术的机会。

欲瘦身，咱们先找找胖的缘由和问题。按目标－路径－资源的思惟模式，找缘由和问题有以下几条路径，一是拍脑壳，按本身的经验和判断，甚至是主观想象；二是去搜索引擎找关键字，逛各类技术论坛听技术大牛们怎么说，看各种技术文章抽取提炼；三是用一种可测量的工具或者方法发现问题。

前两种不赘述，我这里说说第三种方法。用一种可测量的工具或者方法来分析，所谓工欲善其事，必先利其器。这个器能够能够本身锻造，也能够用现成的。这里推荐一个在线apk分析工具，由于是外部工具，因此你们请在使用过程当中，不要上传未发布出去的产品，为了数据安全，笔者这里拿一个github上开源的Android项目做为瘦身示例。

寻找问题

NimbleDroid 是美国哥伦比亚大学的博士创业团队研发出来的分析Android app性能指标的系统，分析的方式有静态和动态两种方式，其中静态分析能够分析出APK安装包中大文件排行榜，各类知名SDK的大小以及占代码总体的比例，各类类型文件的大小以及占排行，各类知名SDK的方法数以及占全部dex中方法数的比例，废话很少说，下面上高清无码大图看看颜值吧。

若是想使用分析功能分析本身的产品，请登陆并上传本身产品的apk包，全部功能目前均无偿使用，若是是想分析Google Play上已经发布的产品，能够直接点击"Play Apps"查看，还可使用搜索功能根据应用名和包名查看结果。再次强调下，请不要上传任何未发布的产品。

■登陆

 

■上传apk文件

 

■分析结果摘要，能够看到一些概览的信息，apk文件大小，总的方法数

 

■文件大小分析详情页，大文件列表，这里列出的是apk文件中超过100k的文件排行，这里的文件大小指的是apk文件中的大小

 

■各类知名SDK的大小以及占代码总体的比例，这里目前能识别出Android Support，Jackson JSON parser, Google Play Services, Paypal, Glide, OkHttp, Facebook SDK, Fabric, Gson等等，Application表示App中本身编写的代码部分

■各类类型文件的大小以及排行

 

■各类知名SDK占全部dex中方法数的比例

 

■各类知名SDK的方法数排行榜

 

看完这个apk内剖图是否是有一种神清气爽的感受！我把这个分析工具比作咱们家买的智能体重秤，能够称体重，脂肪含量，骨重，骨密度，肌肉含量等等，那么，咱们是否是发现了一些问题，进而把这些问题和咱们以前靠经验和一拍脑壳的缘由能够用逻辑联系在一块儿。

那么，咱们接下来能够经过分析数据整理出咱们的优化目标

1. 大文件排行榜里，有11张png文件的大小超过了100k，记住，这但是压缩以后的啊

2. 大文件排行榜里，resources.arsc的大小接近2M，这也是一个优化点；

3. 大文件排行榜里，classes.dex接近3M，classes.dex是代码的载体，这块的优化须要细分，再去看看细分SDK的排行榜；

4. 组件占比环图里，Android Support, Jackson JSON Parser和Google Play Services是三方库的前三甲；

5. 文件类型排行榜里，png, dex 和arsc是前三甲；

 

梳理优化目标

 

因此咱们的目标是没有蛀牙，不对，是下面的目标：

1. png图片优化；

2. resources.arsc文件的优化；

3. 代码优化

 

3.1图片优化的尝试

首先是第一个目标，图片的优化，慢点，咱们看看这些图为何这么大先，准确的说，为何这些图在apk（其实就是zip文件）里这么大，好了，上工具分析。

■此次用了一些简单的工具组合，系统自带的cmd就好。

■命令执行的结果以下

 

恩，全部的png文件竟然是STORE的方式存储到apk里的，关于zip里的STORE和DEFLATE，详见 )

通俗的说，当文件是STORED的方式存储到zip，表示这个文件并无通过压缩，若是是Defl:N的方式，表示经过DEFLATED normal的方式压缩存储到zip。

这看起来有点不合理，png原封不动的放入zip，固然最后产出的apk会比较大。那么，如何解决呢？笔者首先尝使用android gradle plugin的方式，发现aaptOptions和packagingOptions都未能解决问题。在github上发现一个开源项目AndResGuard，试了集成到项目中，再看结果以下：

 

■优化前：

10536027字节

 

■优化后：

普通zip压缩： 8786265字节 （压缩了将近17%）

采用7zip压缩：8567150字节 （压缩了将近19%）

再看看这个工具作了什么，对比下开启资源混淆先后

■优化前

■优化后

 

1.  资源（png, xml, jpg等）名称混淆，资源路径名称混淆以及名称长度压缩；

2.  原来以STORED形式存储到zip中的png文件被改为了DEFLATED（普通压缩存储）方式；

3.  意外发现resources.arsc, META-INF/*.SF 以及 META-INF/*.MF变小了，并且是解压以后的文件大小也变小了。

 

■用apk反编译神器jadx内窥apk寻找真相

原来apk中资源（png, xml，以及properties文件）的相对路径会存放到META-INF/*.SF 以及META-INF/*.MF中并为每一个资源文件计算SHA1值并存储在这两个文件中，至于为啥这么作以及这两个SHA1有啥区别和做用请参考网络上关于这方面知识的文章，已超出本文的主题因此这里再也不赘述。

■对于resources.arsc文件

很容易看出来它是资源文件索引表，因此，看到这里你们应该明白这三个文件为啥会变小了吧。

3.2一次意外的发现

■顺着resources.arsc往下看，发现一个有趣的东西，

 

这又将成为一个优化点，去除那些没用的翻译资源，引入一些第三方的SDK，每每这些SDK带了不少翻译资源在里面，好比android support库，去掉后咱们来看看效果。

假设咱们只保留英文，固然只是个实验，现实中看具体状况了，

采用7zip压缩：8220738字节 （压缩了将近22%，再增长3个点）

固然，真实的项目里不可能这样，可是蚊子肉也是肉啊！

其实，我想说的是这提供了一种优化思路，就是利用gradle的配置干掉无用的资源，一样的能够用在so本地库上，分辨率（gradle配置已deprecated）上。

■gradle配置示例以下：

记得包在android{}中间哦。那么，有人要问了，abi里肿么没有x86？听说intel提供了一个解决方案叫houdini，是一个运行在x86设备上的中间件，能够将arm转码为x86的指令，不过效率很低，有些运算型的，好比计算MD5和SHA1，甚至不如java，笔者曾经作过测试对比，又是另一个话题，此处不赘述，感兴趣的读者能够移步。

到此为止，咱们已经在朝第一个目标迈进，不经意间发现了第一个目标和第二个目标之间的关系，因此利用资源混淆工具，达成了第二个目标。

利用7zip压缩，咱们对整个包进行了2个点的压缩，这是一个超出预期的成果。

 

3.3图片优化的方法

关于第一个目标，咱们的路径尚未结束，拍脑壳想出来的路径是压缩png，非alpha图转成jpg，还有什么？因此去各类技术论坛逛了一圈，请教了各类技术大牛，梳理的路径以下：

1. 手动lint检查，手动删除代码中没有引用到的资源，实际效果不等。

在Android Studio中打开“Analyze” 而后选择"Inspect Code..."，范围选择整个项目，而后点击"OK"

■配置以下图

2.     gradle脚本中开启shrinkResources

■脚本参考以下

shrinkResources配合minifyEnabled使用效果更佳，详见shrinkResources用法以及注意

采用7zip压缩：8115283字节 （压缩了将近23%，再增长1个点）

 

3. 使用图片压缩工具，压缩png图的大小，将非alpha的图转换成jpg形式，关于这点同事以及网络上的大牛们已经整理的很详细了，我这里作简单总结，欲知详情，请见附录的参考。

• 使用tinypng，我只想说我们在公司作产品，此方案慎用，上传任何未发布产品的内容到外部网络，都有可能引发数据泄漏，因此慎用此方案。下面说替代方案。

• WASTED

• pngquant

• ImageAlpha

• ImageOptim

• 以上工具太散，有没有集成化的工具，答案是“有”，@心伦 童鞋开发的imagemin

• @姐夫童鞋开发的MSImageResourcesHelper

• png转成jpg格式 具体效果不等。

4.  终极大杀器，png转成webp，关于webp，更多详情请参考谷歌官方文档以及安卓开发者在线参考

■先上效果图：

采用7zip压缩：4926912字节 （压缩了将近53%，再增长30个点）

没看错吧，是30个点，目前apk的大小是原始apk大小的一半不到，而我作的，一行代码木有改动，仅用了一些工具而已！

说人话，我木有吃减肥药，木有绝食，体重却轻了一半！！！

可是，目前却没能用到项目中，由于有两个坑

• 在三星的部分机型上，部分有alpha背景部分的图会有一条很明显的黑线，这里就不上图了，这个问题目前经过白名单的方式不去作成webp的图来处理；

• 在小米2刷成4.xx的手机上，未能正确识别xml文件中描述的webp图片，致使界面起来后加载xml布局文件，文件加载webp失败，报错说resource file not found，致使app发生崩溃。跟踪发现是小米机器代理了类Resource为MIUIResource，可是这个MIUIResource未能正确识别webp，因此致使加载资源文件失败，初步断定，目前暂时没有解决方案，因此只能忍痛放弃这个优化方案。

关于第一个目标，图片资源的优化，就写到这里了。

3.4 代码优化

第二个目标已达成，剩下第三个目标，代码的优化，梳理以下优化路径：

1. 开启proguard的代码优化

将proguardFiles getDefaultProguardFile('proguard-android.txt'),'proguard-project.txt

改成

proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'),'proguard-project.txt'

开启代码优化后的注意点请参见附录。

2. 去除无用的库

若是apk支持的最低版本是API14,而代码中没有用到高于api14的api就能够考虑拿掉整个android support库。

3. 用更小的库替代方案

若是只用到了谷歌统计，那么就不要把整个google play services都集成进来，只集成须要的部分。

4. 按期清理废弃的代码

按期删除无用的逻辑和过时的业务功能模块，以及废弃的A/B test代码。

5. 业务模块采用插件化框架，代码动态从云端拉取

插件化，这是另一个课题了，这里不赘述。

apk瘦身记最终的成果

10536027字节压缩到4926912字节, 压缩了将近53%

总结

1.     脚本中开启资源混淆和资源压缩

2.     用7zip代替zip

3.     gradle脚本中开启代码混淆优化和无用资源删除

4.     用更小的图，使用压缩工具压缩图片大小

5.     去除无用的资源，语言，本地so库，二方三方库和分辨率

6.     用更小的库

7.     尝试将android support库完全踢出你的项目

8.     按期清理代码

9.     尝试用H5编写界面，图片云端获取

10.  尝试插件化业务模块

11.  寻找到zip文件夹中全部用STORE形式存储的文件（不限于raw目录下），尝试压缩，以及替代方案加载这些资源

12.  尝试webp的图片加载方案，寻求突破

最后，继续学习和尝试新的优化方案

以此文献给“惟瘦身与产品不可辜负”的技术们！！！