第2条：开启minifyEnabled混淆代码

在gradle使用minifyEnabled进行Proguard混淆的配置，可大大减小APP大小：

android {    buildTypes {        release {            minifyEnabled true        }    }}

在proguard中，是否保留符号表对APP的大小是有显著的影响的，可酌情不保留，但是建议尽量保留用于调试

第3条：开启shrinkResources去除无用资源

在gradle使用shrinkResources去除无用资源，效果非常好。

android {    buildTypes {        release {            shrinkResources true        }    }}

第4条：删除无用的语言资源

大部分应用其实并不需要支持几十种语言的国际化支持。还好强大的gradle支持语言的配置，比如国内应用只支持中文：

android {    defaultConfig {        resConfigs "zh"    }}

第5条：使用tinypng有损压缩

android打包本身会对png进行无损压缩，所以使用像tinypng这样的有损压缩是有必要的。 重点是Tinypng使用智能有损压缩技术，以尽量少的失真换来图片大小的锐减，效果非常好，强烈推荐。

Tinypng的官方网站：http://tinypng.com/

第6条：使用jpg格式

如果对于非透明的大图，jpg将会比png的大小有显著的优势，虽然不是绝对的，但是通常会减小到一半都不止。在启动页，活动页等之类的大图展示区采用jpg将是非常明智的选择。

第7条：使用webp格式

webp支持透明度，压缩比比jpg更高但显示效果却不输于jpg，官方评测quality参数等于75均衡最佳。

相对于jpg、png，webp作为一种新的图片格式，限于android的支持情况暂时还没用在手机端广泛应用起来。从Android 4.0+开始原生支持，但是不支持包含透明度，直到Android 4.2.1+才支持显示含透明度的webp，使用的时候要特别注意。

官方介绍：https://developers.google.com/speed/webp/docs/precompiled

第10条：删除armable-v7包下的so

基本上armable的so也是兼容armable-v7的，armable-v7a的库会对图形渲染方面有很大的改进，如果没有这方面的要求，可以精简。

第11条：删除x86包下的so

x86包下的so在x86型号的手机是需要的，如果产品没用这方面的要求也可以精简。

第12条：使用微信资源压缩打包工具

微信资源压缩打包工具通过短资源名称，采用７zip对APP进行极致压缩实现减小APP的目标，效果非常的好，强烈推荐。

详情参考：Android资源混淆工具使用说明

原理介绍：安装包立减1M–微信Android资源混淆打包工具 建议开启7zip，注意白名单的配置，否则会导致有些资源找不到，粗略配置如下，

<?xml version="1.0" encoding="UTF-8"?><resproguard>    <!--defaut property to set  -->    <issue id="property" >        <seventzip value= "true" />        <!--  ...  -->    </issue>    <issue id="whitelist" isactive="true">        <path value ="com.xxx.yyy.R.drawable.emoji_*" />        <path value ="com.xxx.yyy.... />    </issue>    <issue id ="compress" isactive="true">        <!--  ...  -->    </issue></resproguard>

第13条：使用provided编译

对于一些库是按照需要动态的加载，可能在某些版本并不需要，但是代码又不方便去除否则会编译不过。

使用provided可以保证代码编译通过，但是实际打包中并不引用此第三方库，实现了控制APP大小的目标。

但是也同时就需要开发者自己判断不引用这个第三方库时就不要执行到相关的代码，避免APP崩溃。

第14条：使用shape背景

特别是在扁平化盛行的当下，很多纯色的渐变的圆角的图片都可以用shape实现，代码灵活可控，省去了大量的背景图片。

第15条：使用着色方案

相信你的工程里也有很多selector文件，也有很多相似的图片只是颜色不同，通过着色方案我们能大大减轻这样的工作量，减少这样的文件。

借助于android support库可实现一个全版本兼容的着色方案，参考代码：DrawableLess.java

第16条：在线化素材库

如果你的APP支持素材库(比如聊天表情库)的话，考虑在线加载模式，因为往往素材库都有不小的体积。

这一步需要开发者实现在线加载，一方面增加代码的复杂度，一方面提高了APP的流量消耗，建议酌情选择。

第17条：避免重复库

避免重复库看上去是理所当然的，但是秘密总是藏的很深，一定要当心你引用的第三方库又引用了哪个第三方库，这就很容易出现功能重复的库了，比如使用了两个图片加载库：Glide和Picasso。

通过查看exploded-aar目录和External Libraries或者反编译生成的APK，尽量避免重复库的大小，减小APP大小。

第18条：使用更小的库

同样功能的库在大小上是不同的，甚至会悬殊很大。

如果并无对某个库特别需求而又对APP大小有严格要求的话，比较这些相同功能第三方库的大小，选择更小的库会减小APP大小。

第19条：支持插件化

过去的一年，插件化技术雨后春笋一样的都冒了出来，这些技术支持动态的加载代码和动态的加载资源，把APP的一部分分离出来了，对于业务庞大的项目来说非常有用，极大的分解了APP大小。

因为插件化技术需要一定的技术保障和服务端系统支持，有一定的风险，如无必要（比如一些小型项目，也没什么扩展业务）就不需要了，建议酌情选择。

第20条：精简功能业务

​从统计数据分析砍掉一些没用的功能是完全有可能的，甚至干脆去掉一些花哨的功能出个轻聊版、极速版也不是不可以的。