欢迎访问我的个人站点：

让你的apk文件尽可能小，应该使移除未使用的代码和资源文件。那么本章节介绍了如何做到让APK更小，性能更好，下载转化率会更高，以及如何指定在构建APK过程中保留或移除的代码和资源，在我们还没有分析APK大小之前，项目中存在一些资源放置处理不当，没有统一的规范，依赖管理不合理，资源重叠，dex方法数过多等问题，导致APK文件比较大，公司要求APK体积大小要优化到3M左右。经过我们的努力终于达到要求，然而我们发现还能再小。

正所谓工欲善其事，必先利其器，我们得现有利器，下面就是我们常用的分析APK大小工具的利器。

在 resource 文件中指定 shrinkMode，你可以指定 Gradle 在处理该资源文件时候的方式，默认的值为 safe，你也可以将它指定为 strict（只会保留有明确引用的资源，以及处理被 tools:keep和

在后面 查看资源回收情况，我们会讲到，会遇到有些xml 无法被清除的问题，使用shrinkMode可以解决这个问题。

Gradle resource shrinker只删除你在代码中未使用资源，这意味着它不会删除不同的设备配置的可替代资源。如果有必要，你可以使用Android Gradle plugin 的resconfigs属性删除替代资源文件。

例如：我们项目中适配10种国家语言，而项目依赖了v7、v4等其他support包里面包含20种国家语言，那么我们可以通过resconfigs 删除剩余的可替代资源文件，这对于我们APK大小可减少了不少，

以下代码说明了如何限制你的语言资源，只是英语和法语：

像上面那样通过resconfig属性指定的语言。未指定的语言的任何资源都被删除。

同样的图片资源我们也可以这么做，例如：我们提供一套xxhdpi的图片资源，其他的都过滤清除掉，这样大量清除了support，其他第三方library的资源文件，关于这个待会我们在后面会说。

默认情况下，Gradle也将同名的资源，比如相同的名字，可能是在不同的资源文件夹下，这样子不能通过shrinkResources属性来去除。

只有当两个或多个文件共享相同的资源名称、类型和限定符时才发生资源合并，关于资源的合并优先级如下：

Gradle 主要从以下位置合并资源：

Gradle合并重复资源优先顺序为：

例如：找出为什么 @drawable/ic_plus_anim_016，仍然包含在你的APK中，在resource.txt 搜索该文件名，你可能会发现它是被另一个资源引用，如下：

如果你不使用严格的检查（就是上面讲的 shrinkMode），同样的我们如果我们在drawable中使用了字符串’#FFFFFF‘ 这样的使用 resource shrinker也不能将他移除在APK中，通常我们可以在Gradle Console中看到以下信息：

那么这种情况我们如何解决呢，可以通过以下方法来清理：

• 使用tools:discard，在 tools:shrinkMode=”strict” 的时候生效，指定某资源文件需要删除。在你确定该资源文件无效的时候使用。

• 利用Lint找出未使用的资源并清理掉

到这里APK的大小又小了不少。

例如：那些未使用的多套替代资源，或者是library内部隐患着引用着的资源而我们却没有使用到。或者是我们要根据用户的手机去提供不同版本的APK，如分辨率(xxhdpi,mhdpi等)，so库等。那么我们可以使用 APK Splits大大的减少一些无用的资源，这里我们主要参考了 文档。

APK Splits比起使用 flavors，能让应用程序更有效地构建一些形式的多个apk。

多 apk 只支持以下类型：

使用新的 APK Splits，构建同一个应用程序的hdpi版本和mdpi版本，能够共享很多的任务 （如 javac，dx，proguard）。此外，它会被认为是一个单一的variant，并且同一个测试程序将会被用来测试每个多APK。

• enable： 启用屏幕密度拆分机制

• exclude： 默认情况下所有屏幕密度都包括在内，你可以移除一些密度。

• include： 表示要包括哪些屏幕密度

• reset()： 重置屏幕密度列表为只包含一个空字符串 （这能够实现，在与include一起使用时可以表示使用哪一个屏幕密度，而不是要忽略哪一些屏幕密度）

• compatibleScreens：表示兼容屏幕的列表。这将会注入到manifest中匹配的 节点。这个设置是可选的。

构建完成后可以在out/apk/目录下看到多个版本的APK

• exclude： 默认情况下所有ABI都包括在内，你可以移除一些ABI。

• reset()：重置ABI列表为只包含一个空字符串（这可以实现，在与include一起使用来可以表示要使用哪一个ABI，而不是要忽略哪一些ABI）

• universalApk：指示是否打包一个通用版本（包含所有的ABI）。默认值为 false。

例如：我们项目主要提供xxhdpi的图片资源，而项目中引用到了很多第三方库(v7、v4、google Service 等Libarry资源)我们无法使用到，那么我们可以通过这种方法来去除那些资源。这样我们的APK又减小了非常多。

Multiple APK Support是一个在Google Play，可以发布不同的应用程序，分别针对不同的设备配置特征。每个APK是一个完整的、独立的应用程序版本，但他们分享在Google Play相同的应用程序清单，必须共享相同的包名和与签名。Google Play 会自动给你匹配相应的APK，这样我们的APK 就可以是分不同版本构建需要资源文件，从而减小APK的大小。

通过发布有多个APK，我们可以：

• 支持不同的屏幕尺寸和密度的APK

• 支持不同的设备功能的APK

• 支持不同的平台版本的APK

目前我们基于这个方案做了不同屏幕的APK。

我们可以在项目中使用资源动态加载形式，例如：表情，语言，离线库等资源动态加载，减小APK的大小。

• 使用更轻量级的库代替，或者优化library的大小，不然自己写更好。

• 删除armable-v7包下的so、删除x86包下的so，基本上armable的so也是兼容armable-v7的，armable-v7a的库会对图形渲染方面有很大的改进，不过最好的是根据上面我们说的提供多版本APK，对不同的平台精简，再或者动态的加载so。

• 使用H5编写界面，图片云端获取

• 资源缓存库不放在assets下，云端获取更新。

未来对于一些独立业务模块，可以做成插件化动态加载，用户需要使用时，只需下载少部分插件。

ReDex是Facebook开源一个减小安卓app大小以提高性能的工具，内嵌以及清除僵尸代码这样的优化来减小字节码，主要是对Dex进行了优化，能让APK 运行更快，不过需要多测试是否会崩溃。

教程很简单具体更详细的内容请参考：

关于APK瘦身就我们就总结到这了，应该还有很多更好的方案，若有错漏，欢迎补充。

APP架构师是一个数十万开发者探讨APP开发架构的公众号，分享最有价值的干货文章，我们探讨Android性能优化，Android内存泄露，动态化、插件化等最新的Android开发技术，还有IOS开发架构，高级开发知识，我们的愿景是服务每个APP开发者，做一个有逼格的APP架构师！

看完文章，顺便点击下方广告 ，打赏一下小编，非常感谢！