致Android开发者：APP 瘦身经验总结

APP 为什么变胖了

在 Android 出现的最初几年时间里，除了游戏，我们很难看到动辄十兆或者几十兆的APP，但现在你只要到应用市场上去走一圈，就能发现十兆以上大小的应用比比皆是，究其原因，主要有以下几种。

随着 Android 系统版本的碎片化发展以及手机类型的极大丰富，每个 APP 要支持的主流 dpi 分类越来越多，从最初的 ldpi、mdpi、hdpi，到后来的 xhdpi、xxhdpi、xxxhdpi、tvdpi 等。

随着 Android 生态系统的不断发展成熟，出现了很多方便开发者的函数库和 SDK，随着引入的函数库和 SDK 数量的增多，不可避免的引入很多重复功能代码以及资源文件。

用户对 APP 视觉要求的不断提高，APP 提供的资源细节越来越丰富，占用的体积也不断上升。

优化图片资源占用的空间

目前移动端 Android 平台原生支持的图片格式主要有：JPEG、PNG、GIF、BMP 和 WebP ( 自从 Android 4.0 开始支持)，但是在 Android 应用开发中能够使用的编解码格式只有其中的三种：

JPEG、PNG、WebP，这可以通过查看 Bitmap 类的 CompressFormat 枚举值来确定。

public static enum CompressFormat {

JPEG,

PNG,

WEBP;

private CompressFormat() {

}

}

如果要在应用层使用 GIF 格式图片，那么需要自己引入第三方函数库进行支持。在对应用中的图片资源进行压缩和优化之前，我们有必要对这几种常见的图片格式做一个简单的了解和区分。

JPEG：JPEG（发音为/jay-peg/）是一种广== 泛使用的有损压缩图像的标准格式，它不支持透明和多帧动画，一般摄影类作品最终都是以 JPEG 格式展示。通过控制压缩比，可以调整图片的大小。

PNG：PNG 是一种无损压缩图片格式，它支持完整的透明通道，从图像处理领域讲，JPEG 只有 RGB 三个通道，而 PNG 有 ARGB 四个通道。由于是无损压缩，因此 PNG 图片一般占用空间比较大，会无形中增加最终 APP的大小，我们在做 APP 瘦身时一般都要对 PNG 图片进行处理以降低其大小。

GIF：GIF 是一种古老的图片格式，它诞生于 1987 年，随着初代互联网流行开来。它的特点是支持多帧动画。大家对这种格式肯定不陌生，社交平台上面发送的各种动态表情，大部分都是基于 GIF 来实现的。

WebP：相比前面几种图片格式，WebP（发音为 /weppy/）算是一个初生儿了，它由Google在 2010 年发布，它支持有损和无损压缩、支持完整的透明通道、也支持多帧动画，是一种比较理想的图片格式。目前国内很多主流 APP 都已经应用了 WebP，例如微信、微博、淘宝等。在既保证图片质量又要限制图片大小的需求下，WebP 应该是首选。

目前无论 Android 平台还是 iOS 平台，大多数 APP 在搭建界面时使用的几乎都是 PNG 格式图片资源，除非你的项目已经全面支持 WebP 格式，否则你都会面临对 PNG 图片瘦身的要求。

在这里，我们可以通过几个工具对 PNG 图片进行压缩来达到瘦身的目的。

1 . 无损压缩 [ImageOptim]

ImageOptim 是一个无损的压缩工具，它通过优化 PNG 压缩参数，移除冗余元数据以及非必需的颜色配置文件等方式，在不牺牲图片质量的前提下，既减小了 PNG 图片占用的空间，又提高了加载的速度。

2 . 有损压缩 [ImageAlpha]

ImageAlpha 是 ImageOptim 作者的一个有损的 PNG 压缩工具，相比较而言，图片大小得到极大的减低，当然同时图片质量也会受到一定程度的影响，经过该工具压缩的图片，需要经过设计师的检视才能最终上线，否则可能会影响到整个 APP 的视觉效果。

3 . 有损压缩 [TinyPNG]

TinyPNG 也是比较知名的有损 PNG 压缩工具，它以 Web 站点的形式提供，没有独立的APP 安装包，同所有的有损压缩工具一样，经过压缩的图片，需要经过设计师的检视才能最终上线，否则可能会影响到整个 APP 的视觉效果。

当然还有很多无损压缩工具，例如 [JPEGMini]4、[MozJPEG]5 等，大家可以从中选择适合自己项目的一个就行，主要是在图片大小和图片质量之间找到一个折衷点。

4 . PNG/JPEG 转换为 WebP

如果你的APP 最低支持到 Android 4.0，那么可以直接使用系统提供的能力来支持 WebP，如果是 4.0 以下的系统，也可以通过在 APP 中集成第三方函数库，例如 [webp-android-backport]来实现对 WebP 的支持。

根据 Google 的测试，无损压缩后的 WebP 比 PNG 文件少了 45% 的文件大小，即使这些PNG 文件经过其他压缩工具例如 ImageOptim 压缩之后，WebP 依然可以减少约 28% 的文件大小。

需要注意的是，对于具有 Alpha 通道的 PNG 图片来说，如果需要在 Android 4.2.1 之前的系统上运行，那么不能转换成 WebP 格式，因为只有在 Android 4.2.1 以上的系统中，才能解析具有 Alpha 通道的 WebP 图片。

WebP 转换的工具可以选择 [智图] 和 [iSparta]等。

5 . 尽量使用 NinePatch 格式的 PNG 图

利用 Android Gradle 配置

在 Android Studio 工程的 app/build.gradle 文件中进行一些配置可以进一步缩减最终生成的APK 大小，它们分别如下。

1 . minifyEnable

标识是否开启 Proguard 混淆，设置为 true 时需要同时设置 Proguard 配置文件名和规则。Proguard 的作用不仅仅是混淆，它还具有压缩、优化等功能。它会遍历所有代码并找出没有引用到的代码，这些无用代码在生成最终的 APK 文件之前会被剔除掉。同时 Proguard 会使用简短的字母组合替换原来的类名、属性名等，这些都能在一定程度上减少 APP 的大小。

2 . shrinkResources

标识是否去除无用的resource 文件。需要注意的是，shrinkResources 依赖于minifyEnable， 需要 minifyEnable 设置为 true 时才会生效。同时，shrinkResources 需要慎重使用，某些资源是通过反射获取的，这类资源可能也会被删除掉，从而在运行时会报Resources$NotFoundException 异常。

以上两种方式的代码示例如下。

android {

// 省略其他

buildTypes {

release {

minifyEnabled true

shrinkResources true

proguardFiles getDefaultProguardFile(‘proguard-android.txt’),

‘proguard-rules.pro’

}

}

}

3 . resConfigs

Android 开发过程中不可避免的会引入第三方开源函数库或者 SDK，在不修改它们的前提下，在最终生成的 APK 中，我们可能会引入很多其实不需要使用到的资源文件，主要可以分为两种。

DPI 目录：Android 从出现到现在，历经了多个版本，支持多种不同类型的设备，屏幕密度、屏幕形状、屏幕大小等都差别很大，支持的屏幕密度就有 ldpi、mdpi、hdpi、xhdpi、xxhdpi、xxxhdpi 等多种类型。在实际项目开发中，我们当然不可能为每一种屏幕密度提供对应的一套资源文件，这不仅没必要而且会显著增加 APP 的体积，我们需要调研产品的目标用户以及目前市场上主流的手机设备屏幕密度，满足这些用户和设备即可。因此需要剔除引用的第三方函数库或者 SDK 中可能存在的不需要的 DPI 目录及其文件。

国际化文件：Android 开发中不可避免地会引用外部的函数库，这些函数库是为了全世界开发人员服务的，不可避免地会存在很多国际化文件，而对于普通的 APP 来说，可能只需要支持本国语言就可以了。因此，也需要剔除无用的国际化文件。

在 Android Studio 中，我们可以通过在 Gradle 中进行配置，来选择最终打包到 APK 中的资源，这一步是通过指定 resConfig 或者 resConfigs 的取值，通过如下 DSL（Domain SpecificLanguage）防止 AAPT（Android Asset Packaging Tool）打包不需要的资源。

android {

// 省略其他

defaultConfig {

// 省略其他

resConfigs “en”, “fr”

resConfigs “nodpi”, “hdpi”, “xhdpi”, “xxhdpi”, “xxxhdpi”

}

4 . ndk.abiFilters

在工程的 build.gradle 文件中增加 ndk.abiFilters 配置，可以指定我们需要的 ABI 类型，从而可以过滤掉不需要的 ABI 类型的 .so 文件。

android {

// 省略其他

defaultConfig {

// 省略其他

ndk {

abiFilters “armeabi-v7a”, “x86”

}

}

5 . 重构和优化代码

保持良好的编码习惯，对你的代码进行持续的优化或者重构，减少重复代码，实现代码复用，这方面可以多读一读 Martin Fowler 的《重构- 改善既有代码的设计》 一书。在项目开发中，建议抽出一个基础库，提供基础的功能，例如网络、数据库、加解密、utils 工具包等，实现不同模块间复用基础的功能，甚至在公司层面维护一个公共库，在不同产品线之间共享。这样如果不同产品之间需要相互集成，复用一套公共库，能在很大程度上减少重复的代码。

6 .资源混淆

资源文件的混淆方案目前有 [ 美团] 和 [ 微信] 两种，前者是通过修改 AAPT 在处理资源文件相关的源码达到资源文件名的替换；后者是通过直接修改 resources.arsc 文件达到资源文件名的混淆。相比之下，微信的方案更优，而且微信已经将这个方案开源出来，地址在[AndResGuard]，感兴趣的同学通过上面的 README.md 介绍可以很容易集成到自己的项目中。

7 . 插件化