android apk瘦身实战

瘦身的目的

app运营中经常会听到一句话：提高下载转化率。什么是下载转化率？举个栗子：你的应用大小是 18MB ，有100个潜在用户想要去下载尝试使用，结果有20个用户嫌弃安装包太大直接扬长而去，有20个用户在等待下载的过程中取消下载，最终只有60个用户真正下载安装，那么应用的下载转化率就是 60/100 = 60% 。
简单的小结便是：安装包越小，用户下载等待的时间越短，对手机存储配置小的设备体验愈佳，应用的下载转化率也就越高。记得以前在腾讯大讲堂听微信大牛说过，微信第一个版本只有差不多 400KB ，瞬间膜拜。

安装包的组成

要对安装包做瘦身，首先需要了解安装包的组成结构，
在 Android Studio 2.2.3 开始，就加入了浏览 APK 结构的功能，我们直接把安装包拖入 IDE ，就可以直接浏览其组成和对应大小，这样能够很方便的对比分析出每一步优化后的结果：

我们可以清楚的看到apk的各个文件及文件的大小，其中，

• res文件： 存放所有的资源文件；
• dex文件： 我们编写的java文件会被dx工具转换成dex文件，运行在davilk虚拟机上；
• assets文件： 存放需要保持原始文件的资源，打包时不会被压缩、二次处理；
• libs： 用于存放native库文件，各种so；
• resources.arsc：存放所有资源的id映射；
• AndroidManifest: android全局配置文件；
• META-INF: 存放签名校验相关文件，用于保证apk的完整性和安全性；
• 其他：其他一些配置生成的文件；

资源瘦身
了解完 APK 的组成，我们可以开始着手优化的工作了，因为资源文件在 APK 中的占比最高，所以优先从资源瘦身开始着手。

尽量只保存一份图片资源

目前市面上绝大部分机型都处于 xxhdpi 的适配范围，所以可以考虑只保留 xxhdpi 目录下一份图片资源，具体保留哪个目录下的资源和保留几份资源还得依照应用自身的实际机型分布决定。

使用 Drawable XML、Color、.9 PNG 代替 PNG

• 一些情况下，我们可以考虑使用 Drawable XML 来代替 PNG，如：渐变的背景图，用几行 XML 就可以描绘出来，何必使用几十到上百K的 PNG 文件；
• 用 Color 代替 PNG，如：纯色的背景；
• 从性能上看，比起使用图片资源需要先将其生成 Bitmap 再传到底层交由 GPU 渲染，用 Drawable XML 和 Color 则更加高效，它是直接将 Shape 信息传到底层由 GPU 进行渲染，CPU 和 内存的占用会更少；
• 用 .9 PNG 代替 PNG，场景很多，不举例了；

使用 JPG 代替 PNG

用 JPG 代替 PNG，由于 JPG 没有 Alpha 通道，所以文件更小，适用于不需要透明度的图片可以考虑。

使用webp图片格式

具体可以看下webp探寻之路，里面有对webp的详细介绍，这里简单说下webp其实是谷歌开发的一种新的图片格式，它跟PNG有点相似，最大优点在于压缩率高，支持有损和无损压缩，但是Android4.0及以上才支持webp格式，4.0以下想使用webp就需要其他辅助支持库了。
推荐一个在线转webp格式的网址，能立刻看到压缩后的图像和压缩前的图像的差别，还能按照需要选择压缩质量。

有损编码格式的音频文件代替无损格式的音频文件

从下面这篇官方文档
https://developer.android.com/guide/topics/media/media-formats.html

可以看到 Android 平台支持的音视频格式，下面列出有损和无损常用的格式（不要认为有损编码就是音质很差）：

无损格式：WAV，PCM，ALS，ALAC，TAK，FLAC，APE，WavPack(WV)
有损格式：MP3，AAC，WMA，Ogg Vorbis
实际开发中需要使用音频文件尽量采用 MP3、Ogg 这种有损格式，尽量不要用 WAV、PCM 这种无损音频。

移除无用的资源

这里的移除无用资源文件主要分为两个部分：不打包没有使用的资源和删除没有使用的资源。

• 不打包没有使用的资源，在项目的 build.gradle 中配置 shrinkResources true 即可。
  

• 删除没有使用的资源，通过 Android Studio 选中项目右键 => Analyze => inspect Code 可以查看项目中没有使用到的资源
  

即可看到所有未使用的资源文件，建议定期清理掉这些没用的文件，一方面可以减小工程的大小，另一方面太多的资源文件会导致打包后 resources.arsc 文件变得越来越大，公司有一项目 resources.arsc 文件已经达到 2-3 MB 的程度，有点惊人。

综合以上几点，就可以有效的精简我们安装包中的res文件夹、assets文件夹、resource.arsc文件大小，从而达到瘦身目的。

工具

上一章节提到的是优化的思路，本章节整理在优化过程中使用到的工具。

TinyPNG：https://tinypng.com/ ，支持对 PNG/JPEG 文件做压缩处理，效果不错。
pngquant：https://pngquant.org/ ， 支持 PNG 压缩，有时候 TinyPNG 处理过的图片噪点会稍多，可以考虑用 pngquant 来处理。
ImageOptim：https://imageoptim.com/mac ，支持压缩 PNG/JPEG/GIF ，而且效果显著，可以看看这里 https://www.diycode.cc/topics/496 ，遗憾的是它只支持 Mac ，Windows 党很难过。
mozjpeg：https://imageoptim.com/mozjpeg ， 用于 PNG 转 JPEG、JPEG 压缩，效果很好。
Adobe Audition CC：http://www.adobe.com/cn/products/audition.html ，Adobe 出品，支持对音频的采样率，分辨率和声道数目做更改，以此达到裁剪音频的目的（采样率，分辨率和声道数目是音频文件格式的关键参数，决定着音频文件的大小）。
以上是我优化过程中用到的觉得不错的工具，有更好的推荐，欢迎补充。

另外，在对图片做压缩的时候，不要贪图方便直接将整个资源目录下的图片一次性压缩一趟。很多时候，前面做这个项目的人可能已经对一些资源文件做过压缩处理，很容易导致二次压缩而引起一些图片失真。这里我建议是，去到应用的资源目录下将资源文件从大到小排序，定一个标准，如超过 20KB 的图片要做压缩处理，则将这些符合条件的图片 Copy 一份出来做压缩处理，处理后确保没出现失真的情况下再替换对应优化前的图片资源。 音频文件的处理，同理。

Native库瘦身

Native 库瘦身主要是减小对 CPU 架构的支持，配置起来很简单，在 build.gradle 使用 abiFilters 配置需要用到的 CPU 架构，并将不需要兼容的 so 文件从项目中移除即可。

删除armable-v7包下的so

基本上armable的so也是兼容armable-v7的，armable-v7a的库会对图形渲染方面有很大的改进，如果没有这方面的要求，可以精简。
这里不排除有极少数设备会Crash，可能和不同的so有一定的关系，请大家务必测试周全后再发布。

删除x86包下的so
x86包下的so在x86型号的手机是需要的，如果产品没用这方面的要求也可以精简。
建议实际工作的配置是只保留armable、armable-x86下的so文件，算是一个折中的方案。

根据我们用户的机型分布，最终只保留了对 armeabi-v7a 支持。注意，这里需要根据自家产品的实际情况来决定。

代码瘦身

这里可以做的事情也是很多，主要如下：

移除废弃功能的代码，反正有 VCS ，删了代码随时可以找回；
移除重复的代码，如：已经有了的功能代码，团队成员不知道自己又写了一套，只能靠代码 Review 解决了；
移除功能重叠的框架，如：项目中有几套网络访问框架 Volley、AsyncHttpClient、Retrofit 等，同样只能靠代码 Review 解决；
移除无用的 dependencies 或者 jar 包；
减小对 Support 兼容包的依赖，Support-V4 包非常大，项目引入无疑会增大 dex 文件的大小，Google 已经意识到这个问题，所以 Support-V7 一开始就做了拆分，并且开始对 Support-V4 做拆分，虽然目前成果还不明显，不过还是蛮值得期待的，特别是发现你少了 Support-V4 包后，可能就从2个 dex 变成1个 dex 了呢；
插件化，一种懒加载思想的体现，先让用户能够安装宿主包，对于一些功能模块做插件化，在特定的时机再下载安装；
综上所述，就可以有效的精简我们安装包中的 dex 文件大小，从而达到瘦身目的。