Android应用瘦身

时间 2019-11-10

原文原文链接

转：https://zhuanlan.zhihu.com/p/25465537

瘦身的目的

从目的导向来看，咱们是不会平白无故去作一件事情的，那咱们对应用瘦身的目的是为了什么？答案是：提升下载转化率。什么是下载转化率？举个栗子：你的应用大小是 18MB ，有100个潜在用户想要去下载尝试使用，结果有20个用户嫌弃安装包太大直接扬长而去，有20个用户在等待下载的过程当中取消下载，最终只有60个用户真正下载安装，那么应用的下载转化率就是 60/100 = 60% 。html

简单的小结即是：安装包越小，用户下载等待的时间越短，对手机存储配置小的设备体验愈佳，应用的下载转化率也就越高。记得之前在腾讯大讲堂听微信大牛说过，微信第一个版本只有差很少 400KB ，瞬间膜拜。android

安装包的组成

要对安装包作瘦身，首先须要了解安装包的组成结构，这里简单的梳理了一下组成各个部分及其做用：微信

其中，在安装包中占比较大的包括：dex文件、res文件夹、assets文件夹、lib文件夹以及resource.arsc文件。因此，接下来的瘦身优化就是让这些文件变小，以此达到瘦身的目的。网络

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

资源瘦身

了解完 APK 的组成，咱们能够开始着手优化的工做了，由于资源文件在 APK 中的占比最高，因此优先从资源瘦身开始着手。框架

尽可能只保存一份图片资源ide

开发目录下会有个 drawable 或者 mipmap 目录用于适配不一样 dpi 的屏幕，下面是不一样命名目录所适配的 dpi 范围工具

目前市面上绝大部分机型都处于 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 代替 PNG

因为 WebP 效果好，且相同效果下， WebP 文件比 PNG 文件要小得多，因此，网上不少人说使用 WebP 代替 PNG，对此，我保持异议。理由以下：

WebP 在 Android 端，最低只支持 4.0 ，要兼容 4.0 如下的环境须要额外引入兼容库，反而增大安装包体积；
Android Studio 不支持预览 WebP 图片，引用 WebP 的布局文件也没法预览显示；
解压了 BAT 们的应用，以及同类竞品，基本没有发如今资源文件中用 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

实际开发中须要使用音频文件尽可能采用 MP三、Ogg 这种有损格式，尽可能不要用 WAV、PCM 这种无损音频。

移除无用的资源

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

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

删除没有使用的资源，经过 Android Studio 选中项目右键 => Analyze => Run Inspection by Name => 输入 Unused Resuroces

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

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

工具

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

TinyPNG：TinyPNG – Compress PNG images while preserving transparency ，支持对 PNG/JPEG 文件作压缩处理，效果不错。
pngquant：pngquant - lossy PNG compressor ，支持 PNG 压缩，有时候 TinyPNG 处理过的图片噪点会稍多，能够考虑用 pngquant 来处理。
ImageOptim：better Save for Web ，支持压缩 PNG/JPEG/GIF ，并且效果显著，能够看看这里分享一个很是好用的免费 Mac 图片无损压缩工具 ImageOptim ，遗憾的是它只支持 Mac ，Windows 党很难过。
mozjpeg：ImageOptim online ，用于 PNG 转 JPEG、JPEG 压缩，效果很好。
Adobe Audition CC：Adobe Audition CC ，Adobe 出品，支持对音频的采样率，分辨率和声道数目作更改，以此达到裁剪音频的目的（采样率，分辨率和声道数目是音频文件格式的关键参数，决定着音频文件的大小）。

以上是我优化过程当中用到的以为不错的工具，有更好的推荐，欢迎补充。

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

Native库瘦身

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

根据咱们用户的机型分布，最终只保留了对 armeabi-v7a 支持。注意，这里须要根据自家产品的实际状况来决定。因为以前对 CPU 的架构分布不是很熟悉，感谢微信的张绍文、沪江的徐宜生以及虎牙的郑晓滨几位老司机给我科普了一发。

综上所述，就能够有效的精简咱们安装包中的 lib 文件夹大小，从而达到瘦身目的。也有一种作法是经过在 build.gradle 配置 include 来针对每一个 CPU 架构生成单独的安装包，虽然看起来很不错，可是不少国内应用市场上架的时候并不支持这种每一个 CPU 配置一个包的作法，因此此作法较为鸡肋，不太建议去作，若是应用只上 Google Play ，那确实要比配置 abiFilters 好得多。

代码瘦身

这里能够作的事情也是不少，主要以下：

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

综上所述，就能够有效的精简咱们安装包中的 dex 文件大小，从而达到瘦身目的。