本文会不定期更新，推荐watch下项目。

如果喜欢请star，如果觉得有纰漏请提交issue，如果你有更好的点子可以提交pull request。本文的示例代码主要是基于作者的经验来编写的，若你有其他的技巧和方法可以参与进来一起完善这篇文章。

业务方和开发都希望app尽量的小，本文会给出多个实用性的技巧来帮助开发者进行app的瘦身工作。瘦身和减负虽好，但需要注意瘦身对于项目可维护性的影响，建议根据自身的项目进行技巧的选取。

本文固定连接：

---

一、背景

目前app的大小越来越大，用户对于过大的app接受度不高，所以除了插件化和RN的方案外，我们只能老老实实的进行app的瘦身工作。

二、需求

1. 我要利用混淆来让我的代码尽可能少
2. 最好能用最少的切图完成功能
3. layout文件不要太多，太多了乱
4. 能动态下载的就做动态
5. 我希望能用大小最小的图片
6. 如果能用svg，我就用svg
7. 对于无用的资源，我要as能自动删除掉
8. 中国文字博大精深，而我只要我需要的字的字体
9. 最好能根据下载用户手机的cpu和分辨率来引入不同的资源

三、实现

分析app组成结构

做瘦身之前一定要了解自己app的组成结构，要有针对性的进行优化，并且要逐步记录比对，这样才能更好的完成此项工作。关于apk的大小，我推荐google的这个。目前as的2.2预览版中已经有了apk分析器，功能相当强大，此外你还可以利用来分析apk。

我们都知道apk是由：

• asserts
• lib
• res
• dex
• META-INF
• androidManifest

这几个部分构成的。

下面我会利用as的分析工具，以微信、微博、淘宝为例进行讲述。

分析完成后你还可以看到具体类目占的百分比，清晰明了。旁边的“对比”按钮提供了diff的功能，让你可以方便的进行apk优化前后的对比，简直利器。

assets

assets目录可以存放一些配置文件或资源文件，比如webview的本地html，react native的jsbundle等，微信的整个assets占用了13.4M。如果你的应用对本地资源要求很少的话，这个文件应该不会太大。

lib

lib目录下会有各种so文件，分析器会检查出项目自己的so和各种库的so。微博和微信一样只支持了arm一个平台，淘宝支持了arm和x86两个平台。

resources.arsc

这个文件是编译后的二进制资源文件，里面是id-name-value的一个map。因为微信做了资源的混淆，所以这里可以看到资源名称都是不可读的。

索性放个微博的图，易于大家理解：

META-INF

META-INF目录下存放的是签名信息，用来保证apk包的完整性和系统的安全性，帮助用户避免安装来历不明的盗版apk。

res

res目录存放的是资源文件，包括图片、字符串。raw文件夹下面是音频文件，各种xml文件等等。因为微信做了资源混淆，图片名字都不可读了。

微博就没有做资源混淆，所以可读性较好：

dex

dex文件是java代码打包后的字节码，一个dex文件最多只支持65535个方法，这也是为什么微信有了三个dex文件的原因。

因为dex分包是不均匀的，你可以理解为装箱，一个箱子的大小是固定的，但你代码的量是不确定的，微信把前两个箱子装满了，最后还剩了2m多的代码，这些代码也占用了一个箱子，最终产生了上图不均匀的情况。

现在，我们已经知道了apk中各个文件的大小和它们占的比例，下面就可以开始针对性的进行优化了。

优化assets

assets中会存放资源文件，这个目录中不同厂的app存放的内容各有不同，所以优化也比较难。自从引入RN以来，这个目录下还会有jsbundle的信息（可参考全民k歌）。如果你有地址选择的功能，这里还会存放地址的映射文件。

对于这块的资源，as是不会进行主动的删减的，所以一切都是需要靠开发者进行手动管理的。

删除无用字体

中文字体是相当大的，我一直不建议将字体文件随意丢弃到assets中。有时候一个小功能急着上，开发者为了追求速度，可以先放在这里图省事。但一定要知道这个隐患，并且一定要多和产品核对功能的必要性。对于有些只会用在logo中的字体，我推荐将字体文件进行删减处理。

是一个字体提取工具，readme中写到：

经过测试，已经把项目5MB的艺术字体，按需求提取后，占用只有20KB，并且可正常使用。

减少icon-font的使用

icon-font和svg都能完成一些icon的展示，但因为icon-font在assets中难以管理，并且功能和svg有所重叠，所以我建议减少icon-font的使用，利用svg进行代替，毕竟一个很小的icon-font也比svg大。这里给出一个提供各种格式icon的网站，方便大家进行测试：

• svg：549字节
• png：375字节（单一分辨率的一张图）
• ion-font：1.1kb

动态下载资源

字体、js代码这样的资源能动态下载的就做动态下载，虽然这样会增加出错的可能性，复杂度也会提升，但对于app的瘦身和用户来说是有长远的好处的。

如果你用了rn，你可以在app运行时动态去拉取最新的代码，将图片和js代码一并下载后解压使用。也可以把rn模块化，主线的rn代码随着app发布，入口较深的次要界面可以在app启动后通过断点下载。

压缩资源文件

有些资源文件是必须要随着app一并发布的。对于这样的文件，可以采用压缩存储的方式，在需要资源的时候将其解压使用，下面就是解压zip文件的代码示例：

public static void unzipFile(File zipFile, String destination) throws IOException {        FileInputStream fileStream = null;        BufferedInputStream bufferedStream = null;        ZipInputStream zipStream = null;        try {            fileStream = new FileInputStream(zipFile);            bufferedStream = new BufferedInputStream(fileStream);            zipStream = new ZipInputStream(bufferedStream);            ZipEntry entry;            File destinationFolder = new File(destination);            if (destinationFolder.exists()) {                deleteDirectory(destinationFolder);            }            destinationFolder.mkdirs();            byte[] buffer = new byte[WRITE_BUFFER_SIZE];            while ((entry = zipStream.getNextEntry()) != null) {                String fileName = entry.getName();                File file = new File(destinationFolder, fileName);                if (entry.isDirectory()) {                    file.mkdirs();                } else {                    File parent = file.getParentFile();                    if (!parent.exists()) {                        parent.mkdirs();                    }                    FileOutputStream fout = new FileOutputStream(file);                    try {                        int numBytesRead;                        while ((numBytesRead = zipStream.read(buffer)) != -1) {                            fout.write(buffer, 0, numBytesRead);                        }                    } finally {                        fout.close();                    }                }                long time = entry.getTime();                if (time > 0) {                    file.setLastModified(time);                }            }        } finally {            // ...        }    }复制代码

全民k歌中的assets目录下我就发现了大量的zip文件：

android上也有一个帮助我们方便的使用7z，我目前没用到，有需求的同学可以尝试一下。

优化lib

配置abiFilters

一个硬件设备对应一个架构（mips、arm或者x86），只保留与设备架构相关的库文件夹（主流的架构都是arm的，mips属于小众）可以大大降低lib文件夹的大小。配置方式也十分简单，直接即可：

defaultConfig {    versionCode 1    versionName '1.0.0'    renderscriptTargetApi 23    renderscriptSupportModeEnabled true    // http://stackoverflow.com/questions/30794584/exclude-jnilibs-folder-from-production-apk    ndk {        abiFilters "armeabi", "armeabi-v7a" ,"x86"    }}复制代码

armeabi就不用说了，这个是必须包含的，v7是一个图形加强版本（如果用到模糊算法，则不要删除），x86是英特尔平台的支持库。

：

按 ABI 拆分

android {  ...  splits {    abi {      enable true      reset()      include 'x86', 'armeabi-v7a', 'mips'      universalApk true    }  }}复制代码

• enable： 启用ABI拆分机制
• exclude： 默认情况下所有ABI都包括在内，允许移除一些ABI
• include：指明要包含哪些ABI
• reset()：重置ABI列表为只包含一个空字符串（这也是允许的，在与include一起使用来可以表示要使用哪一个ABI）
• universalApk：指示是否打包一个通用版本（包含所有的ABI）。默认值为 false。

根据手机的cpu来引入so

我们在舍弃so之前一定要进行用户cpu型号的统计，这样你才能放心大胆地进行操作。

我先是花了几个版本的时间统计了用户的cpu型号，然后排除了没有或少量用户才会用到的so，以达到瘦身的目的。

@NonNullpublic static String getCpuName() {    String name = getCpuName1();    if (TextUtils.isEmpty(name)) {        name = getCpuName2();        if (TextUtils.isEmpty(name)) {            name = "unknown";        }    }    return name;}private static String getCpuName1() {    String[] abiArr;    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {        abiArr = Build.SUPPORTED_ABIS;    } else {        abiArr = new String[]{Build.CPU_ABI, Build.CPU_ABI2};    }    StringBuilder abiStr = new StringBuilder();    for (String abi : abiArr) {        abiStr.append(abi);        abiStr.append(',');    }    return abiStr.toString();}private static String getCpuName2() {    try {        FileReader e = new FileReader("/proc/cpuinfo");        BufferedReader br = new BufferedReader(e);        String text = br.readLine();        String[] array = text.split(":\\s+", 2);        e.close();        br.close();        return array[1];    } catch (IOException var4) {        var4.printStackTrace();        return null;    }}复制代码

注意：

1. 如果你和我一样用到了renderscript，那么你必须包含v7，否则会出现模糊异常的问题。
2. 如果你用了RN，那么对于x86需要谨慎的保留，否则可能会出现用户找不到so而崩溃的情况。毕竟rn是一个全局的东西，稍有不慎就可能会出现开机崩的情况。
3. so这个东西还是比较危险的，我们虽然可以通过统计cpu型号来降低风险，但我还是推荐发布app前走一遍大量机型的云测，通过云测平台把风险进一步降低。
4. 小厂的项目可能会舍弃一些so，但随着公司规模的增大，你未来仍旧要重复考虑这个问题。所以我推荐在崩溃系统中上传用户cpu型号的信息，这样我们就可以在第一时间知道因找不到so引起的崩溃量，至于是否需要增加so就看问题的严重程度了。

避免复制so

so有个：在Android 6.0之前，so文件会压缩到apk中，系统在安装应用的时候，会把so文件解压到data分区。这样同一个so文件会有两份存在，一个在apk里，一个在data中。这也导致多占用了一倍的空间，而且会出现各种诡异的错误。这个策略虽然和apk的瘦身无关，但它和app安装在用户手机中的大小有关，因此我们也是需要多多留意的。

Starting from Android Studio 2.2 Preview 2 and newest build tools, the build process will automatically store native libraries uncompressed and page aligned in the APK

在6.0+中，可以通过如下的方式进行申明：

    
     复制代码
    

如果想了解更多信息或者想知道这种配置的限制，可以浏览下。

优化resources.arsc

resources.arsc中存放了一个对应关系：

id	name	default	v11
0x7f090002	PopupAnimation	@ref/0x7f040042, @ref/0x7f040041	…

我们在程序运行的时候肯定要经常用到id，因此它在安装之后仍需要被频繁的读取。如果将这个文件进行了压缩，在每次读取前系统都必须进行解压的工作。这就会有一些性能和内存的开销，综合考虑下来，压缩这个文件是得不偿失的。

删除无用的资源映射

resources.arsc的正确瘦身方式是删除不必要的string entry，你可以借助 来检查出可以优化的部分，比如一些空的引用。

：

进行资源名称混淆

微信团队开源了一个资源混淆工具，。它将资源的名称进行了混淆，所以可以用它对resources.arsc进行优化，只是具体优化效果与编码方式、id数量、平均减少命名长度有关。

表1：

id	name	default	v11
0x7f090001	Android	@ref/0x7f040042, @ref/0x7f040041	…
0x7f090002	ios	@ref/0x7f040042, @ref/0x7f040041	…
0x7f090003	Windows Phone	@ref/0x7f040042, @ref/0x7f040041	…

表2：

id	name	default	v11
0x7f090001	a	@ref/0x7f040042, @ref/0x7f040041	…
0x7f090002	b	@ref/0x7f040042, @ref/0x7f040041	…
0x7f090003	c	@ref/0x7f040042, @ref/0x7f040041	…

我们一眼就可以知道表2肯定比表1存储的字符要小，所以整个文件的大小肯定也要小一些。

详细信息请参考：

关于AndResGuard

这个压缩工具其实就是一个task，使用也十分简单，具体的用法请参考。

原理介绍：

andResGuard {    mappingFile = null    use7zip = true    useSign = true    keepRoot = false    whiteList = [        //for your icon        "R.drawable.icon",        //for fabric        "R.string.com.crashlytics.*",        //for umeng update        "R.string.umeng*",        "R.string.UM*",        "R.layout.umeng*",        "R.drawable.umeng*",        //umeng share for sina        "R.drawable.sina*"    ]    compressFilePattern = [        "*.png",        "*.jpg",        "*.jpeg",        "*.gif",        "resources.arsc"    ]     sevenzip {         artifact = 'com.tencent.mm:SevenZip:1.1.9'         //path = "/usr/local/bin/7za"    }}复制代码

使用这个工具的时候需要注意一些东西：像友盟这种喜欢用反射获取资源的SDK就是一个坑（友盟的SDK就是坑王！）对于app启动图标这样的icon可以不做混淆，推荐将其放入白名单中。

优化META-INF

META-INF文件夹中有三个文件，分别是MANIFEST.MF、CERT.SF、CERT.RSA。下面我将会列出简要的分析，如果你希望更详尽的了解原理，可以查看。

MANIFEST.MF

每一个资源文件（res开头）下面都有一个SHA1-Digest的值。这个值为该文件SHA-1值进行base64编码后的结果。

如果要探究原理，可以看下。这个类中的main方法：

public static void main(String[] args) {    //...    // MANIFEST.MF    Manifest manifest = addDigestsToManifest(inputJar);    je = new JarEntry(JarFile.MANIFEST_NAME);    je.setTime(timestamp);    outputJar.putNextEntry(je);    manifest.write(outputJar);    //...}复制代码

private static void writeSignatureFile(Manifest manifest, OutputStream out)        throws IOException, GeneralSecurityException {    Manifest sf = new Manifest();    Attributes main = sf.getMainAttributes();    main.putValue("Signature-Version", "1.0");    main.putValue("Created-By", "1.0 (Android SignApk)");    BASE64Encoder base64 = new BASE64Encoder();    MessageDigest md = MessageDigest.getInstance("SHA1");    PrintStream print = new PrintStream(            new DigestOutputStream(new ByteArrayOutputStream(), md),            true, "UTF-8");    // Digest of the entire manifest    manifest.write(print);    print.flush();    main.putValue("SHA1-Digest-Manifest", base64.encode(md.digest()));    Map
    
      entries = manifest.getEntries();    for (Map.Entry
     
       entry : entries.entrySet()) {        // Digest of the manifest stanza for this entry.        print.print("Name: " + entry.getKey() + "\r\n");        for (Map.Entry
      
        att : entry.getValue().entrySet()) {            print.print(att.getKey() + ": " + att.getValue() + "\r\n");        }        print.print("\r\n");        print.flush();        Attributes sfAttr = new Attributes();        sfAttr.putValue("SHA1-Digest", base64.encode(md.digest()));        sf.getEntries().put(entry.getKey(), sfAttr);    }    sf.write(out);}复制代码
      
     
    

上述代码说明了SHA1-Digest-Manifest是MANIFEST.MF文件的SHA1并base64编码的结果。

CERT.SF

这里有一项SHA1-Digest-Manifest的值，这个值就是MANIFEST.MF文件的SHA-1并base64编码后的值。后面几项的值是对MANIFEST.MF文件中的每项再次SHA1并base64编码后的值。所以你会看到在manifest.mf中的资源名称在这里也出现了，比如abc_btn_check_material这个系统资源文件就出现了两次。

MANIFEST.MF:

CERT.SF

• 前者：4XHnecusACTIgtImUjC7bQ9HNM8=
• 后者：YFDDnTUd6St4932sE/Xk6H0HMoc=

如果你把前一个文件打开在后面加上\n\r，然后进行编码，你就会得到CERT.SF中的值。

Map
    
      entries = manifest.getEntries(); for (Map.Entry
     
       entry : entries.entrySet()) {     // Digest of the manifest stanza for this entry.     print.print("Name: " + entry.getKey() + "\r\n");     for (Map.Entry
      
        att : entry.getValue().entrySet()) {         print.print(att.getKey() + ": " + att.getValue() + "\r\n");     }     print.print("\r\n");     print.flush();     Attributes sfAttr = new Attributes();     sfAttr.putValue("SHA1-Digest", base64.encode(md.digest()));     sf.getEntries().put(entry.getKey(), sfAttr); } sf.write(out);复制代码
      
     
    

CERT.RSA

CERT.RSA包含了公钥、所采用的加密算法等信息。它对前一步生成的MANIFEST.MF使用了SHA1-RSA算法，用开发者的私钥进行签名，在安装时使用公钥解密它。解密之后，将它与未加密的摘要信息（即，MANIFEST.MF文件）进行对比，如果相符，则表明内容没有被修改。

这点和app瘦身就完全无关了，这块我平时也没有仔细研究过，就不误人子弟了。具体的签名过程可以参考：

优化建议

通过分析得出，除了CERT.RSA没有压缩机会外，其余的两个文件都可以通过混淆资源名称的方式进行压缩。

优化res

资源文件的优化一直是我们的重头戏。如果要和它进行对比，上文的META-INF文件的优化简直可以忽略不计。res的优化分为两块：一个是文本资源（shape、layout等）优化和图片资源优化。本节仅探讨除图片资源优化外的内容，关于图片的内容下面会另起一节。

说明：

上图中有-v4，-v21这样的文件有些是app开发者自己写的，但大多都是系统在打包的时候自动生成的，所以你只需要考虑自己项目中的drawable-mdpi、drawable-hdpi、drawable-xhdpi、drawable-xxhdpi即可。

通过as删除无用资源

在as的任何文件中右击，选择清除无用资源即可删除没有用到的资源文件。

不要勾选清除id！如果清除了id，会影响databinding的使用（id绝对占不了多少空间）

Tips：

做此操作之前，请务必产生一次commit，操作完成后一定要通过git看下diff。这样既方便查看被删除的文件，又可以利用git进行误删恢复。

打包时剔除无用资源

shrinkResources顾名思义————收缩资源。将它设置为true后，每次打包的时候就会自动排除无用的资源（不仅仅是图片）。有了它的帮忙，即使你忘记手动删除无用的资源文件也没事。

buildTypes {    release {        zipAlignEnabled true        minifyEnabled true        shrinkResources true // 是否去除无效的资源文件        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'        signingConfig signingConfigs.release    }    rtm.initWith(buildTypes.release)    rtm {}    debug {        multiDexEnabled true    }}复制代码

删除无用的语言

大部分应用其实并不需要支持几十种语言的，微信也做了根据地区选择性下载语言包的功能。作为国内应用，我们可以只支持中文。推荐在项目的build.gradle中进行如下配置：

android {    //...    defaultConfig {        resConfigs "zh"    }}复制代码

这样在打包的时候就会排除私有项目、android系统库和第三方库中非中文的资源文件了，效果还是比较显著的。

控制raw中资源的大小

• assets目录允许下面有多级子目录，而raw下不允许存在目录结构
• assets中的文件不会产生R文件映射，但raw会
• 如果你app最低支持的版本不是2.3的话，assets和raw应该都不会对资源文件的大小进行限制
• raw文件会生成R文件映射，可以被as的lint分析，而assets则不能
• raw缺少子目录的缺点让其无法成为存放大量文件的目录

一般raw文件下会放音频文件。如果raw文件夹下有音频文件，尽量不要使用无损（如：wav）的音频格式，可以考虑同等质量但文件更小的音频格式。

ogg是一种较适合做音效的音频格式。当年我初中做游戏的时候，我全都是用的mp3和png，最终游戏达到了2G。在换为ogg和jpg后，游戏缩小到了1G以内（因为游戏中音频和大图较多，所以效果比较夸张）。

移动端的音频主要是音效和短小的音频，所以淘宝大量选择了ogg格式，微博的选择格式比较多，有wav、mp3、ogg，我更加推荐淘宝的做法。当然，你仍旧不要忘记opus格式，opus也是一种有损压缩格式，如果感兴趣的话也可以尝试一下。

统一应用风格，减少shape文件

一个应用的界面风格是必须要统一的，这个越早做越好，最基本的就是统一颜色和按钮的按压效果。无UI设计和扁平化风格流行后，倒是给应用瘦身带来了极大的的福利。界面变得越朴实，我们可以用shape画的东西就越多。

当你的app统一过每种颜色对应的按下颜色后，接下来就需要统一按钮的形状、按钮的圆角角度、有无阴影的样子、阴影投射角度，阴影范围等等，最后还要考虑是否支持水波纹效果。

我简单将按钮分为下列元素：

元素	属性01	属性02	属性03	属性04
形状	正方形	三角形	圆角矩形	圆形
颜色	红	黄	蓝	绿
有无阴影	有	无
阴影大小	3dp	5dp
阴影角度	90°	120°	180°
水波纹效果	有	无

各个元素组合后会产生大量的样式，shape和layer-list当然可以实现各种组合，但这样的话光按钮的背景文件就有n个，很不好维护。

一般为了开发方便，都会把需要用到的各种selector图片事先定义好，做业务的时候只需要去调用就行。但这大量的selector文件对于业务开发者来说也是有记忆难度的，所以我推荐使用这个库，它可以将上面的每个元素进行各种组合，用最少的资源文件来实现大量的按压效果。

用库虽然好，但库也会带来学习成本，所以引入者可以将上述的组合定义为按钮的一个个的style。因为style本身是支持继承的，对于这样的组合形态来说，继承真是是一大利器。当你的style有良好的命名后，调用者只需要知道引入什么style就行，至于你用了什么属性别人才不希望管呢。

如果业务开发中有一些特别特殊的按压状态，没有任何复用的价值，那你就可以利用库提供的丰富属性在layout文件中进行实现，再也不用手忙脚乱的到处定义selector文件了。

我将不能继承和不灵活的shape变成了一个个单一的属性，通过库将多个属性进行组合，接着利用支持继承的style来将多个属性固定成一个配置文件，最后对外形成强制的规范性约束，至此便完成了减少selector文件的工作。

使用toolbar，减少menu文件

menu文件是actionBar时代的产物，as虽然对于menu的支持做的还不错，但我也很难爱上它。

menu的设计初衷是解耦和抽象，但因为过度的解耦和定制，让开发变得很不方便，很多项目已经不再使用menu.xml作为actionbar的菜单了。

就目前的形势来看，toolbar是android未来的方向。我虽然作为一个对actionbar和actionbar的兼容处理相当了解的人，但我还是不得不承认actionbar的时代过去了。如果你不信，我可以告诉你淘宝的menu文件就3个，微博的menu文件就9个，如果你还是苦苦依恋着actionbar的配置模式，我推荐一个库，它可以让你在用灵活的toolbar的同时也享受到配置menu的便利性。

限制灵活性，减少layout文件

减少layout文件有两个方法：复用和融合（include）。

复用layout文件

把一些页面共用的布局抽出来，这无论是对layout文件的管理还是瘦身都是极为有用的。

就比如说任何一个app的list页面是相当多的，从布局层面来说就是一个ListView或者RecyclerView，其背后还可能会有loading的view，空状态的view等等，所以我的建议是建立一个list_layout.xml，其余的list页面可以复用或者include它，这样会从很大程度上减少layout文件的数目。

融合layout代码

对于可以被复用的layout我们可以做统一管理，但是对于不会被复用的layout怎么办呢？

假设一个页面是由两个区域组合而成的，fragment的做法是一个页面中放两个container，然后再写两个layout，但实际上这两个layout经常是没有任何复用价值的。我希望找到一种方式，在view区块还没有复用需求的时候用一个layout搞定，需要被复用的时候也可以快速、无痛的拆分出来。

1. UiBlock

是一个类似于fragment的解耦库，它可以为同一个layout中不同区域的view进行逻辑解耦（因为layout可预览的特性，ui定位方面不是难题），它能帮我们尽可能少地建立layout文件。

如果未来需求发生了变动，layout文件中的一块view需要抽出成独立的layout文件的时候，UiBlock的逻辑代码几乎不用改动，你只需要把抽出的layout文件include进来，然后在include标签上定义一个id即可。而这个工作可以通过as的重构功能自动完成，绝不拖泥带水。

    
    复制代码

2. ListHeader

public void addHeaderToListView(ListView listView, View header) {    if (header == null) {        throw new IllegalArgumentException("Can't add a null header view to ListView");    }    ViewGroup viewParent = (ViewGroup) header.getParent();    viewParent.removeView(header);    AbsListView.LayoutParams params = new AbsListView.LayoutParams(            header.getLayoutParams().width,            header.getLayoutParams().height);    header.setLayoutParams(params);    listView.addHeaderView(header); // add}复制代码

我将listView和它的没有复用价值的header放到了同一个layout中，然后在activity中利用上述代码进行了操作，最终完成了用一个layout文件给listView加头的工作。这段代码我很久没动过了，有利有弊，放在这里我也仅仅是举个例子，希望可以帮助大家扩展下思路。

动态下载图片

做过滤镜和贴纸的同学应该会注意到贴纸、表情这类的东西是相当大的，对于这类的图片资源我强烈建议通过在线商店进行获取。这样既可以让你踏踏实实的卖贴纸，又可以减小应用的大小。这么做虽然有一定的复杂度和出错概率，但投入产出比还是很不错的。

准确放置不同分辨率的图片

这个虽然不算是app大小的优化，但是如果你放错了图片，对于app启动时的：

思考一下，如果把一个本来应该放在drawable-xxhdpi里面的图片放在了drawable文件夹中会出现什么问题呢？

在xxhdpi设备上，图片会被放大3倍，图片内存占用就会变为原来的9倍！

国内也有很多人说可以用一套图片来做，不用出多套图，借此来达到app瘦身和给设计减负的目的。谷歌官方是建议为不同分辨率出不同的图片，为此国内也有不少文章讨论过这件事情，总结的不错推荐一读。

每次说到这个话题的时候总有很多人有不同的看法，况且很多人还不知道.9图也是需要切多份的，所以这里我还是先分析一下大厂的放图策略，最后咱们再讨论下较优的方案。

分析过程见：

厂商	mdpi	hdpi	xhdpi	xxhdpi
淘宝	小icon	表情	国家icon	弃用
微博	小icon	背景图&表情	背景图	背景图
微信	弃用	表情	大图	弃用

通过分析得出，传统的出多个分辨率图片的做法在大厂中已经发生了改变，阿里系、腾讯系的产品都采用了一套图走天下的路子。这样的做法还是有利有弊的，权衡之下我给出如下建议：

• 聊天表情就出一套图，放在hdpi中
• 纯色小icon用svg做
• 背景等大图，出一套放在xhdpi中
• logo等权重较大的图片可针对hdpi，xhdpi做两套图
• 如果某些图在真机中确实展示异常，那就用多套图
• 如果遇到奇葩机型，可针对性的补图

成年人不看对错，只看利弊，所以还请大家权衡一二。

丢弃特定资源

如果我们希望保留或丢弃特定的资源，需要在项目中创建一个res/raw/keep.xml文件，这里可以使用tools:keep和 tools:discard两个属性来保留或丢弃资源。

两个属性都可以使用逗号,分隔符声明资源名称列表。也可以使用*作为匹配符。

android {    ...    buildTypes {        release {            shrinkResources true // 开启            minifyEnabled true            proguardFiles getDefaultProguardFile('proguard-android.txt'),                    'proguard-rules.pro'        }    }}复制代码

keep：

    
    复制代码

discard：

    
    复制代码

开启严格模式

开启严格模式后，可能对于编译会产生一些问题，警告也会增多，所以需谨慎开启此功能。

res/raw/keep.xml

    
    复制代码

shrinkMode默认的值为safe，你将它指定为strict便开启了严格模式。严格模式下，apk会保留确定引用到的资源。

Gradle Console中的日志中也会有移除APK资源的信息：:

:android:shrinkDebugResourcesRemoved unused resources: Binary resource data reduced from 2570KB to 1711KB: Removed 33%:android:validateDebugSigning复制代码

apk构建完成后会Gradle会在/build/outputs/mapping/release/下生成resource.txt，这个文件包括详细信息，如资源参考其他资源和使用或删除资源的详细信息等。

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

16:25:48.005 [QUIET] [system.out] @drawable/add_schedule_fab_icon_anim : reachable=true16:25:48.009 [QUIET] [system.out] @drawable/ic_plus_anim_016复制代码

要 为什么add_schedule_fab_icon_anim 仍然在使用，搜索我们可以知道应该有代码引用着add_schedule_fab_icon_anim。

此部分的内容大量参考自一文，请移步官网去详细了解。

移除第三方库中的配置文件

有时候引用的三方库会带有一些配置文件xxxx.properties,或者license信息，打包的时候想去掉这些信息，就可以这样做

android {    packagingOptions {        exclude 'proguard-project.txt'        exclude 'project.properties'        exclude 'META-INF/LICENSE.txt'        exclude 'META-INF/LICENSE'        exclude 'META-INF/NOTICE.txt'        exclude 'META-INF/NOTICE'        exclude 'META-INF/DEPENDENCIES.txt'        exclude 'META-INF/DEPENDENCIES'    }}复制代码

优化图片

对于图片的优化应该是放在优化res一节中进行讲解的，但是因为图片这块比重太大了，所以我让其独立成为一节。

选择合适的图片格式

想要做好图片的优化工作首先要知道应该选择什么样的图片格式，对于这点我推荐一个，方便大家进行深入的了解。也推荐参考下里面的相关内容。

这是谷歌给出的建议是：VD->WebP->Png->JPG

1. 如果是纯色的icon，那么用svg
2. 如果是两种以上颜色的icon，用webp
3. 如果webp无法达到效果，选择png
4. 如果图片没有alpha通道，可以考虑jpg

使用VectorDrawable

VD即，是android上的svg实现类。在经历了长达半年的缓慢兼容之路后，现在终于被support库兼容了，中给出了这样一个例子：

// Gradle Plugin 2.0+  android {    defaultConfig {       vectorDrawables.useSupportLibrary = true      }  }复制代码

    复制代码

配置好后，我们就可以利用强大的svg来替换纯色icon了。

因为svg矢量图的优势，终于可以通过一套图适配多个机型了。svg的好处有很多，缺点也不少，关于svg的优缺点和实践方案，建议移步：

使用WebP

是一种新的图片格式。从Android4.0+开始原生支持，但是不支持包含透明度，直到4.2.1+才支持显示含透明度的webp，使用的时候要特别注意。

Lossy WebP support (suitable for replacing most JPEGs and some PNGs) is guaranteed on Android 4.0+ devices. Newer WebP features (transparency, lossless, suitable for PNGs) are supported since Android 4.2.1+

我们可以通过或者将其它格式的图片转换成webP格式。

关于webP的优缺点和实践方案，建议移步到继续阅读。

复用图片

利用现有的图片进行复用是一个相当有用的方案，关于复用的原则建议和设计进行讨论，当设计师认为二者均为同一图形的时候才可被认为可复用。

复用相同的icon

我们通过svg可以让一张图片适用于不同大小的容器中，以达到复用的目的。最常见的例子就是“叉”，除非你的x是有多种颜色的，那么这种表示关闭的icon可以复用到很多地方。

上图中我通过组合的方式将长得一样的icon（facebook、renren等）复用到了不同的界面中，不仅实现了效果，可维护性也不错。

使用Tint

着色器（tint）是一个强大的工具，我将其和shape、svg等结合后产生了化学反应。

TintMode共有6种，分别是:add，multiply，screen，srcatop，srcin（默认），src_over。

一般用默认的模式就可以搞定大多数需求了，使用到的控件主要是TextView和ImageButton。ImageButton官方已经给出了支持方案，TextView因为有四个Drawable，官方的tint属性在低版本又不可用，所以我让SelectorTextView支持了一下。如果你想要了解具体的兼容方法，可以参考或。

ImageButton

android:tint="@color/blue"复制代码

SelectorTextView

app:drawableLeftTint="@color/orange"app:drawableRightTint="@color/green"app:drawableTopTint="@color/green"app:drawableBottomTint="@color/green"复制代码

因为我用了SelectorTextView和SelectorImageButton，所以我对于背景的tint没有什么需求，也就没做兼容性测试，有兴趣的同学可以尝试一下。

如果你决定要采用tint，一定要通过云测等手段做下兼容性测试，下图是我对于上述属性的测试结果：

复用按压效果

一个应用中的list页面都应该做一定程度的统一，对于有限长度的list，我们可能偏向于用ScrollView做，对于无限长的list用RecyclerView做，但对于它们的按压效果我强烈建议采用同一个样式。

以微信为例，它的所有列表都是白色的item，我的优化思路如下：

1. 列表由LinearLayout、RecyclerView组成
2. 分割线用统一的shape进行绘制，不用切图
3. 整个列表背景设置为白色
4. item的背景是一个selector文件，正常时颜色是透明，按下后出现灰色

通过旋转来复用

如果一个icon可以通过另一个icon的旋转变换来得到，那么我们就可以通过如下方法来实现：

    
    复制代码

这种方法虽好，但是不要滥用。需要读代码的人具备这种知识，否则会出现不好维护的情况。而且在设计师真的是认为两个图有如此的关系的时候才可这样实现，万不可耍小聪明。

压缩图片

图片的压缩策略是：

1. 优先压大图，后小图
2. 不压.9图（svg在侠义上不算图）
3. 对于开屏大图片的压缩需注意力度，要和设计确认后再做
4. 对于体积特别大(超过50k)的图片资源可以考虑有损压缩

关于如何量化两张图片在视觉上的差别，Google 提供了一个叫的工具，有兴趣的同学可以尝试一下。

关于更加详细的内容可以参考：和

ImageOptim

mac上超好用的图片压缩工具是，它集成了很多好用图片压缩库，很多blog中的图片也是用它来压缩的。

值得一提的是，借助Zopfli，它可以在不改变png图像质量的情况下使图片大小明显变小。

pngquant

也是一款著名的压缩工具，对于png的疗效还不错。它不一定适合app中那种背景透明的小icon，所以对比起tinypng来说，优势不明显。

数据来自：

tinypng

是一款相当著名的商用压缩工具，tinypng提供了开放接口供开发者开发属于自己的压缩工具（付费服务）。tinypng对于免费用户也算友好，每月可以免费压缩几百张图片。

我通过来使用tinypng，更加简单方便。我一般是发版本前才做一次图片压缩，每次debug的时候是直接跳过这个task的，完全不影响日常的debug。

tinyinfo {    apiKey = 'xxxxxxxxx'    //编译时是否跳过此task    skip = true    //是否打印日志    isShowLog = true}复制代码

有人说tinypng的缺点是在压缩某些带有过渡效果（带alpha值）的图片时，图片可能会失真，这时你可以将png图片转换为webP格式的图片来解决此问题。

注意事项

aapt可以在构建过程期间优化放置在res/drawable/中的图像资源，以及无损压缩。 aapt可将不需要多于256种颜色的真彩色png转换为带有调色板的8位png，借此来得到质量相同但占用内存较小的图像。

请记住，aapt有以下限制：

• aapt工具不会压缩资源/文件夹中包含的png文件
• 图像文件需要使用256个或更少的颜色的aapt工具来优化它们
• aapt工具可能会使已压缩的png文件膨胀。原因请看：。

如果你自己做了图片压缩，那么请使用cruncherEnabled来禁用aapt的压缩功能：

android {      defaultConfig {          //...    }      aaptOptions {          cruncherEnabled = false     }  }复制代码

优化dex

dex本身的体积还是很可观的，虽说代码这东西不占用多少存储空间，但是微信这样的大厂的dex已经达到了20多M。我大概估计了一下，如果你没有达到方法数上限，那么你的dex的大小大约是10M，可没有用multiDex的又有几家呢？

记录方法数和代码行数

dexcout

要优化这个部分，你首先要对公司的、android库的、第三方库的代码进行深入的了解。我用了来记录项目的方法数：

dexcount {    format = "list"    includeClasses = false    includeFieldCount = true    includeTotalMethodCount = false    orderByMethodCount = false    verbose = false    maxTreeDepth = Integer.MAX_VALUE    teamCityIntegration = false}复制代码

通过分析后你可以得出很多有用的结论，比如某个第三方库是否已经不用了、自己项目的哪个包的方法数最多、目前代码情况是否合理等等。

statistic

我是通过Statistic这个as插件来评估项目中开发人员写的代码量的，它生成的报表也不错：

现在我可以知道：

• 哪些类空行数太多，是不是没有按照代码规范来
• 哪些类的代码量很少，是否有存在的必要
• 哪些类行数过多，是否没有遵守单一职责原则，是否可以进行进一步的拆分

apk method

你还可以用这个工具来查看项目中各个包中的方法数，它会生成树形结构的文档，十分直观。

利用Lint分析无用代码

如果你想删掉没有用到的代码，可以借助as中的Inspect Code对工程做静态代码检查。

Lint是一个相当强大的工具，它能做的事情自然不限于检查无用资源和代码，它还能检测丢失的属性、写错的单位（dp/sp）、放错目录的图片、会引起内存溢出的代码等等。从eclipse时代发展到现在，lint真的是越来越方便了！

Lint的强大也会带来相应的缺点，缺点就是生成的信息量过多，不适合快速定位无用的代码。

我推荐的流程是到下图中的类目中直接看无用的代码和方法。

注意：

这种删除无用代码的工作需要反复多次的进行（比如一月一次）。当你删除了无用代码后，这些代码中用到的资源也会被标记为无用，这时就可以通过上文提到的Remove Unused Resources来删除了。

通过proguard来删除无用代码

手动删除无用代码的流程太繁琐了，如果是一两次倒还会带来删除代码的爽快感，但如果是专人机械性的持续工作，那个人肯定是要疯的。为了保证每次打包后的apk都包含尽可能少的无用代码，我们利用一下proguard这个强大的工具。

android {    buildTypes {        release {            minifyEnabled true // 是否混淆        }    }}复制代码

虽然这种方式成果显著，但也需要配合正确的proguard配置才能起作用，推荐看下一文。

这种利用混淆来删除代码的方式是一种保险措施，真正治本的方法还是在开发过程中随手删除无用的代码，毕竟开发者才是最清楚一段代码该不该被删的。我之前就是随手清理了下没用的代码，然后就莫名其妙的不用使用mulitdex了。

剔除测试代码

我们在测试的时候可能会随便写点测试方法，比如main方法之类的，并且还会引入一些测试库。对于测试环境的代码gradle提供了很方便的androidTest和test目录来隔离生产环境。

对于测试时用到的大量库，可以进行test依赖，这样就可以保证测试代码不会污染线上代码，也可以防止把测试工具、代码等发布到线上的错误（微博就出过这样的错误）。

// Dependencies for local unit teststestCompile 'junit:junit:4.12'testCompile  'org.hamcrest:hamcrest-junit:2.0.0.0'// Android Testing Support Library's runner and rulesandroidTestCompile 'com.android.support:support-annotations:24.1.1'androidTestCompile 'com.android.support.test:runner:0.5'androidTestCompile 'com.android.support.test:rules:0.5'// Espresso UI TestingandroidTestCompile('com.android.support.test.espresso:espresso-core:2.2.2', {    exclude group: 'com.android.support', module: 'support-annotations'})复制代码

PS：在layout中利用tools也是为了达到上述目的。

区分debug/rtm/release模式

debug模式是开发者的调试模式，这个模式下log全开，并且会有一些帮助调试的工具（比如：，），我们可以通过debugCompile和releaseCompile来做不同的依赖，有时候也会需要no-op（关于no-op的内容可以参考下）。

dependencies {   debugCompile 'com.squareup.leakcanary:leakcanary-android:1.4-beta2'   releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.4-beta2'   testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.4-beta2' }复制代码

debug和release是android本身自带的两种生产环境，在实际中我们可能需要有多个环境，比如提测环境、预发环境等，我以rtm（Release to Manufacturing 或者 Release to Marketing的简称）环境做例子。

首先在目录下创建rtm文件：

复刻release的配置：

buildTypes {    release {        zipAlignEnabled true        minifyEnabled true        shrinkResources true // 是否去除无效的资源文件        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'        signingConfig signingConfigs.release    }    rtm.initWith(buildTypes.release)    rtm {}    debug {        multiDexEnabled true    }}复制代码

配置rtm依赖：

ext {    leakcanaryVersion = '1.3.1'}dependencies {    debugCompile "com.squareup.leakcanary:leakcanary-android:$leakcanaryVersion"    rtmCompile "com.squareup.leakcanary:leakcanary-android-no-op:$leakcanaryVersion"    releaseCompile "com.squareup.leakcanary:leakcanary-android-no-op:$leakcanaryVersion"｝复制代码

rtm环境自然也有动态替换application文件的能力，我为了方便非开发者区分app类别，我做了启动icon的替换。

    
        
     
    复制代码

现在我可以将环境真正需要的代码打包，不需要的代码全部剔除，以达到瘦身的目的。

使用拆分后的support库

谷歌最近有意，可无奈v4被引用的地方太多了，但这不失为一个好的开始。目前来看使用拆分后的support库是没有什么优点的，所以我也不建议现在就开始动手，当谷歌和第三方库作者都开始真的往这方面想的时候，你再开始吧。

减少方法数，不用mulitdex

mulitdex会进行分包，分包的结果自然比原始的包要大一些些，能不用mulitdex则不用。但如果方法数超了，除了插件化和等奇淫巧技外我也没什么好办法了。

使用更小库或合并现有库

同一功能就用一个库，禁止一个app中有多个网络库、多个图片库的情况出现。如果一个库很大，并且申请了各种权限，那么就去考虑换掉他。

话人人都会说，但如果一个项目是由多个项目成员合作完成的，是很难避免重复引用库的问题的。同一个功能用不同的库，或者一个库用不同版本的现象比比皆是，这也是很难去解决的。我的解决方案是部门之间多沟通，尽量做base层，base层由少数人进行维护，正如微信在so库方面的做法：

1. C++运行时库统一使用stlport_shared
   之前微信中的C++运行库大多使用静态编译方式，使用stlport_shared方式可减小APK包大小，相当于把大家公有的代码提取出来放一份，减少冗余。同时也会节省一点内存，加载so的时候动态库只会加载一次，静态库则随着so的加载被加载多份内存映像。
2. 把公用的C++模块抽成功能库
   其实与上面的思路是一致的，主要为了减少冗余模块。大家都用到的一些基础功能，应该抽成基础模块。

四、总结

app的瘦身是一个长期并且艰巨的工作，如果是小公司建议一两个月做一次。大公司的话一般都会对app的大小进行持续的统计和追踪，瘦身工作会有专人负责。总之，希望大家在阅读完本文后可以着手对项目进行优化工作，带来真正的收益。

参考资料：