APK瘦身记，如何实现高达53%的压缩效果，apk53%
作者：非戈@阿里移动安全
1、我是怎么思考这件事情的
APK是Android系统安装包的文件格式，关于这个话题其实是一个老生常谈的题目，不论是公司内部，还是外部网络，前人前辈已经总结出很多方法和规律。不过随着移动端技术近两年的飞速发展，一些新的思维方式和优化方法也逐渐涌现和成熟起来。笔者在实践过程中踩过一些坑，收获了一些经验，在这里做个思考和总结，所以随笔给大家，希望对大家从事相关工作的时候有所帮助和参考，同时也是抛砖引玉，希望大家共同探讨这个开放性的话题。
关于为什么APK要瘦身，这个不多说，只从三个方面唠叨一下，对于用户（或者客户）来说，APK越大，在下载安装过程中，他们耗费的流量会越多，安装等待时间也会越长；对于产品本身，意味着下载转化率会越低（因为竞品中，用户有更多机会选择那个体验最好，功能最多，性能最好，包最小的）；对于研发来说，是一种优化改进技术的机会。
欲瘦身，我们先找找胖的原因和问题。按目标－路径－资源的思维模式，找原因和问题有如下几条路径，一是拍脑袋，按自己的经验和判断，甚至是主观想象；二是去搜索引擎找关键字，逛各种技术论坛听技术大牛们怎么说，看各类技术文章抽取提炼；三是用一种可测量的工具或者方法发现问题。
前两种不赘述，我这里说说第三种方法。用一种可测量的工具或者方法来分析，所谓工欲善其事，必先利其器。这个器可以可以自己锻造，也可以用现成的。这里推荐一个在线apk分析工具，因为是外部工具，所以大家请在使用过程中，不要上传未发布出去的产品，为了数据安全，笔者这里拿一个github上开源的Android项目作为瘦身示例。
2、寻找问题
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内剖图是不是有一种神清气爽的感觉！我把这个分析工具比做我们家买的智能体重秤，可以称体重，脂肪含量，骨重，骨密度，肌肉含量等等，那么，我们是不是发现了一些问题，进而把这些问题和我们之前靠经验和一拍脑袋的原因可以用逻辑联系在一起。
那么，我们接下来可以通过分析数据整理出我们的优化目标
3、梳理优化目标
所以我们的目标是没有蛀牙，不对，是下面的目标：
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%）
再看看这个工具做了什么，对比下开启资源混淆前后
优化前
优化后
用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，还有什么？所以去各种技术论坛逛了一圈，请教了各种技术大牛