APK包瘦身-追上那个胖子

引子

APK大家肯定都很熟悉了，安卓应用安装包文件。而APK的尺寸对于每个产品来说都是一个非常重要的指标。对于如何减小这个数字，有无数的前人总结的或全面、或零散的经验，许多团队也对此做过各种各样的努力，说实话也是一块嚼烂了的口香糖。
如何在此基础上再咀嚼出一丝甜味、再翻滚出新的厚度呢，这个是笔者一直在苦苦思索的问题。
仔细阅读很多其他团队总结出的APK瘦身相关的文章，大体都是讲一个APK包已经胖成那（nèi）样了我们如何让它瘦下来，这是一种促成式的结果导向的思维方式。这种哪胖减哪的方式存在什么问题呢？相信很多同学都与我有同样的遭遇：一次压制、后续报复性反弹。
道家言：一生二、二生三、三生万物，知一、方能知二知三。因此笔者还是想要从根源上去解释APK尺寸这个问题：一个APK包从根本上如何长到这么胖的，我们如何能在如此频繁的项目迭代中保持它的身材呢？本文将从这个角度来说明我们APK各部分增大到底是因为什么，以及我们对于APK尺寸的影响因素都有哪些误解，继而得出作为开发者的我们怎样才能从过程上去避免APK尺寸过分增大的问题。

这大体是一次面向过程的勘探。一些拙见，希望能够提供些新的思路、也欢迎大家指出错误、互相交流、提出建议。

项目初始：APK诞生之初

首先提出一问题：一个最小的HelloWorld应用APK尺寸可以有多小？带着这个问题思考，我做了几组循环对照试验，以便于我们对APK尺寸有一个直观的初始认识。在这里我也同时测试了一下很多人关心的，常常作为依赖库引入的support-v4、support-v7、以及design包，对于APK尺寸的最小影响。

Android Build Tools版本：25.0.2
构建工具：gradle_2.2.0
support-v4版本：25.3.1
support-v7版本：25.3.1
app包含内容：ic_launcher.png(3kb)、helloworld代码及必要资源

（以上混淆指的是代码混淆，资源混淆在后文中讨论，需要引入第三方库）
通过上面的实验，我们对于签名、proguard以及第三方库引用对于apk尺寸产生的影响应该有了一个更加直观的认识。

精简APK包的包内结构分析

图1： 精简APK包结构分析图

通过反编译神器Jadx-gui对刚刚生成的最小签名包进行反编译，可以发现APK包结构主要有以上5部分构成。
那么这五个必要部分、每个部分的到底各自包含一些什么信息呢？

APK包内成分详解：你真的了解它们吗

1. META-INF
META-INF文件夹是做什么的，在jar文件中，我们常常能看见它的身影。要论它的年龄，比Android要大的多。在Android还没有出生的时候，META-INF就已经被广泛用于jar包中存放各种发布、包安全、构建等辅助信息。在Android的APK中，它也承担了类似的职能，主要用于签名验证相关信息的存放。
Android APK中META-INF的结构：

图2：META-INF结构分析图
META-INF文件夹内一般会包含三个信息：MANIFEST.MF、 .SF文件及 .RSA文件。其中MANIFEST.MF是常驻居民，而.SF文件和.RSA文件在签名时才会生成。

MANIFEST.MF文件

图3：MENIFEST.MF 文件内容

如果未签名，MANIFEST.MF文件中只会保留最最基本的构建信息。签名后，文件中会增加APK包内所有文件名及对应的SHA1-Digest的数据指纹，每个三行、排列整齐。

.SF文件

图4：.SF 文件内容

可以看见，.SF文件的结构与MANIFEST.MF文件类似。.SF文件中，包含了MANIFEST.MF文件的SHA1-Digest后的数据指纹，同时包含MANIFEST.MF中每个资源［名称 - 指纹］键值对字符串、SHA1-Digest后的数据指纹。也正因此，.SF文件的尺寸一般来说与MANIFEST.MF文件的尺寸差不多。