业务逻辑不断累积、引入的 SDK 不断增加以及资源文件不断变大，APK 瘦身已经是每个应用开发者必须面对的问题了。坊间流传的各种瘦身方法有些切实可行，有的却流毒甚广。我们可以通过哪些方式减小 APK 文件的体积？这些方法分别对性能和兼容性有怎样的影响？在涉及有损压缩时该如何量化损失？我们将围绕以上问题展开讨论。

为什么要做APK瘦身?

一个很现实的事情是，到上个月底有23.49%用户使用移动网络使用App，其中有4.09%用户还在使用2G网络，这是一个很可怕的数字，因为到今天为止仍在使用Android2.3的用户已经是1%甚至连1%都不到的在网用户量，然而使用2G网络用户还有4.09%。因为现在用户使用移动网络时有一个比较高的成本，大致如果要超了套餐1M在0.1元左右，如果做一次App更新或者一个新用户安装用户成本是多少?现在国内应用市场还是劣币驱逐良币的环境，没有一家市场能够做到50%以上的量，意味着很多市场还是属于不是Sister map，带来最大的问题是并没有一个进网安装权限，一旦如果涉及到应用更新，没有办法做到用户无感知进行更新，用户会很烦这件事，有一些第三方市场会用Work round，比如做自动点击，这不是很好的解决方案。在升级成本本身除了费用上的成本，还有用户操作成本的情况下，结合这两者就带来了一个结果，用户对APK大小非常敏感，这里指的是Android用户。APK大小会带来两个附加影响，分别是安装时间，很好理解，当可视性文件跟so文件，变大安装时间一定会有影响，不管是在安装5.0之前，从DEX到ODEX的优化，还是安装5.0之后从DEX到OAT文件的预编译，时间肯定是正常的。还有一个问题是安装成功率，为什么APK大小对安装成功率有影响?比如1.0版本是10M，1.1版本变成了100M，用户只有50M空间，这当然是个极端例子，类似这样的问题就会导致如果APK大小突然变大，也有可能导致下发出现问题。

APK瘦身

APK瘦身只有一个大小的概念，谈到APK瘦身涉及到四个不同大小。首先是Raw APK Size，APK文件大小。除此之外还有三个不同的，Download Size，为什么跟Raw APK Size不一样?最早是国外做，但现在已经有很多国内市场也会做，在下发时会做一层，最简单可以做把APK本身在传输时做一层封装。第三点是在安装时，因为需要对DEX文件和so文件做相应操作，so文件跟DEX文件不一样，so文件需要拷贝出来，本身占用的体积一定跟APK Size不一样。最后一个是Update Size，为什么跟APK文件本身大小不一样?因为现在大部分应用市场已经做了这点，如果好一些可能会有自研的东西，可以做到一点，更新一个App，下载的并不是一个完整的APK，而是下载一个diff文件，本地合成完整的APK，从而减少用户在网络传输流量上的压力。

这四个Size当中，作为应用开发者最关心的应该是第一个和第三个，能控制的是第一个和第三个，不是说第二个和第四个没有办法控制，国内炒得非常热的插件化和Hotfix，就能够部分意义上解决第二个和第四个在应用开发者这一侧的控制问题。

简单看一下APK文件的生命周期。在前两行是APK文件生成和打包过程，从Source Code到class，到Dex文件。Resources和Native Code，在后面会插进来，Resources本身的流程当中会有一个简单的优化，APK会做，就现在的时间点来说比较傻，甚至还会有把Resources文件越压越大的问题。因为需要做不管是Dex到Odex的优化，还是要做Dex到OAT文件的预编译，这边一定会产生文件大小上的影响，会变大。Native code都是黄线，往下走时直到今天，Google在处理Native code还是使用了比较原始的方案，会把相应版本以so文件拷贝出来。

音频文件，是时候该放弃mp3了，如果App中包含了音频文件，建议大家直接选择aac，在任何意义上都比mp3好得多，在同样的编码率下可以平均能够减少20%的Size。图片文件都可以脚本化做，不应该由人工做这件事。首先要把meta data删掉，第二步要做无损压缩，格式选定时也可以用一些简单标准做一个判断，

最后要做的，App本身有做这样的优化，在这样的情况下手动做这些优化App是不知道的，做了这样的优化，把App本身比较笨的优化关掉，否则会发现好不容易压下来的东西会被App重压过以后变大了。