阅读 3660

App瘦身最佳实践

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

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

本文固定连接:github.com/tianzhijiex…


一、背景

目前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分析器,功能相当强大,此外你还可以利用nimbledroid来分析apk。

nimbledroid是一个强大的工具,推荐一试

我们都知道apk是由:

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

这几个部分构成的。

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

概览

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

diff

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文件等等。因为微信做了资源混淆,图片名字都不可读了。

res

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

dex

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

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

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

优化assets

assets中会存放资源文件,这个目录中不同厂的app存放的内容各有不同,所以优化也比较难。自从引入RN以来,这个目录下还会有jsbundle的信息(可参考全民k歌)。如果你有地址选择的功能,这里还会存放地址的映射文件。
对于这块的资源,as是不会进行主动的删减的,所以一切都是需要靠开发者进行手动管理的。

全民k歌中的bundle文件

删除无用字体

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

FontZip是一个字体提取工具,readme中写到:

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

gif2 (1).gif-204.5kB

减少icon-font的使用

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

  • 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库帮助我们方便的使用7z,这个库我目前没用到,有需求的同学可以尝试一下。

优化lib

配置abiFilters

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

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,以达到瘦身的目的。

@NonNull
public 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+中,可以通过如下的方式进行申明:

<application
   android:extractNativeLibs=”false”
   ...
>复制代码

如果想了解更多信息或者想知道这种配置的限制,可以浏览下SmallerAPK(8)

优化resources.arsc

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

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

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

删除无用的资源映射

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

ArscBlamer

进行资源名称混淆

微信团队开源了一个资源混淆工具,AndResGuard。它将资源的名称进行了混淆,所以可以用它对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存储的字符要小,所以整个文件的大小肯定也要小一些。

详细信息请参考:smallerapk-part-3-removing-unused-resources

关于AndResGuard

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

原理介绍:安装包立减1M--微信Android资源混淆打包工具

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。下面我将会列出简要的分析,如果你希望更详尽的了解原理,可以查看《Android APK 签名文件MANIFEST.MF、CERT.SF、CERT.RSA分析》

MANIFEST.MF

每一个资源文件(res开头)下面都有一个SHA1-Digest的值。这个值为该文件SHA-1值进行base64编码后的结果。
如果要探究原理,可以看下SignApk.java。这个类中的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<String, Attributes> entries = manifest.getEntries();
    for (Map.Entry<String, Attributes> entry : entries.entrySet()) {
        // Digest of the manifest stanza for this entry.
        print.print("Name: " + entry.getKey() + "\r\n");
        for (Map.Entry<Object, Object> 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<String, Attributes> entries = manifest.getEntries();
 for (Map.Entry<String, Attributes> entry : entries.entrySet()) {
     // Digest of the manifest stanza for this entry.
     print.print("Name: " + entry.getKey() + "\r\n");
     for (Map.Entry<Object, Object> 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瘦身就完全无关了,这块我平时也没有仔细研究过,就不误人子弟了。具体的签名过程可以参考:blog.csdn.net/asmcvc/arti…

优化建议

通过分析得出,除了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文件对于业务开发者来说也是有记忆难度的,所以我推荐使用SelectorInjection这个库,它可以将上面的每个元素进行各种组合,用最少的资源文件来实现大量的按压效果。

用库虽然好,但库也会带来学习成本,所以引入者可以将上述的组合定义为按钮的一个个的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的配置模式,我推荐一个库AppBar,它可以让你在用灵活的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

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

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

<!-- 使用include -->
<include
    android:id="@+id/bottom_ub"
    layout="@layout/demo_uiblock"
    android:layout_width="match_parent"
    android:layout_height="100dp"
    />复制代码

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图也是需要切多份的,所以这里我还是先分析一下大厂的放图策略,最后咱们再讨论下较优的方案。

分析过程见:《淘宝、微博、微信的 Android 图片放置策略》

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

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

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

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

丢弃特定资源

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

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

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

keep:

<?xml version="1.0" encoding="utf-8"?>
<resources xmlns:tools="http://schemas.android.com/tools"
    tools:discard="@layout/unused2" />复制代码

discard:

<?xml version="1.0" encoding="utf-8"?>
<resources xmlns:tools="http://schemas.android.com/tools"
    tools:shrinkMode="safe"
    tools:discard="@layout/unused2" />复制代码

开启严格模式

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

res/raw/keep.xml

<?xml version="1.0" encoding="utf-8"?>
<resources xmlns:tools="http://schemas.android.com/tools"
    tools:shrinkMode="strict" />复制代码

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

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

:android:shrinkDebugResources
Removed 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=true
16:25:48.009 [QUIET] [system.out] @drawable/ic_plus_anim_016复制代码

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

此部分的内容大量参考自《Shrink Your Code and Resources》一文,请移步官网去详细了解。

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

有时候引用的三方库会带有一些配置文件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一节中进行讲解的,但是因为图片这块比重太大了,所以我让其独立成为一节。

选择合适的图片格式

想要做好图片的优化工作首先要知道应该选择什么样的图片格式,对于这点我推荐一个视频,方便大家进行深入的了解。也推荐参考下《移动端图片格式调研 | Garan no dou》里面的相关内容。

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

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

使用VectorDrawable

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

// Gradle Plugin 2.0+  
android {
    defaultConfig {  
     vectorDrawables.useSupportLibrary = true  
    }  
}复制代码
<ImageView  
  android:layout_width="wrap_content"  
  android:layout_height="wrap_content"  
  app:srcCompat="@drawable/ic_add" 
/>复制代码

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

因为svg矢量图的优势,终于可以通过一套图适配多个机型了。svg的好处有很多,缺点也不少,关于svg的优缺点和实践方案,建议移步:http://todo(未写完)

使用WebP

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+

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

关于webP的优缺点和实践方案,建议移步到《WebP的问题和解决方案》继续阅读。

复用图片

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

复用相同的icon

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

可以复用的x

利用svg和tint

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

使用Tint

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

TintMode共有6种,分别是:add,multiply,screen,srcatop,srcin(默认),src_over。

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

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的旋转变换来得到,那么我们就可以通过如下方法来实现:

<?xml version="1.0" encoding="utf-8"?>
<rotate xmlns:android="http://schemas.android.com/apk/res/android"
    android:drawable="@drawable/blue_btn_icon" // 原始icon
    android:fromDegrees="180" // 旋转角度
    android:pivotX="50%"
    android:pivotY="50%"
    android:toDegrees="180" />复制代码

旋转图片

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

压缩图片

图片的压缩策略是:

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

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

关于更加详细的内容可以参考:《smallerapk-part-6-image-optimization》《QQ音乐团队的PNG图片压缩对比分析》

ImageOptim

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

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

pngquant

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

数据来自:www.jianshu.com/p/a721fbaa6…

tinypng

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

我通过TinyPic来使用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文件膨胀。原因请看:Smaller PNGs, and Android’s AAPT tool

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

android {  
    defaultConfig {  
        //...
    }  

    aaptOptions {  
        cruncherEnabled = false 
    }  
}复制代码

优化dex

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

记录方法数和代码行数

dexcout

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

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

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

statistic

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

预览

java代码

现在我可以知道:

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

apk method

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

利用Lint分析无用代码

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

search action

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

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

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

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

通过proguard来删除无用代码

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

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

虽然这种方式成果显著,但也需要配合正确的proguard配置才能起作用,推荐看下《读懂Android中的代码混淆》一文。

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

剔除测试代码

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

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

// Dependencies for local unit tests
testCompile 'junit:junit:4.12'
testCompile  'org.hamcrest:hamcrest-junit:2.0.0.0'

// Android Testing Support Library's runner and rules
androidTestCompile '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 Testing
androidTestCompile('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全开,并且会有一些帮助调试的工具(比如:leakcanarystetho),我们可以通过debugCompilereleaseCompile来做不同的依赖,有时候也会需要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文件:

image_1arpi1tfq1dd5pga35j10ntuhjjc.png-12.3kB

复刻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的替换。

<?xml version="1.0" encoding="utf-8"?>
<manifest package="com.kale.example"
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    >

    <application
        android:name=".RtmApplication"
        android:allowBackup="true"
        android:icon="@drawable/rtm_icon"
        tools:replace="android:name,android:icon"
        />

</manifest>复制代码

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

使用拆分后的support库

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

减少方法数,不用mulitdex

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

使用更小库或合并现有库

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

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

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

四、总结

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

developer-kale@foxmail.com

weibo:@天之界线2010

参考资料:
smaller apk系列文章
减少APK的大小,Android官方这样说
那些你不知道的APK 瘦身,让你的APK更小
Android技术专题]APK瘦身看这一篇文章就够了
如何将apk大小减少6M的
Android Vector曲折的兼容之路
淘宝、微博、微信的 Android 图片放置策略
Putting Your APKs on Diet
Shrink Your Code and Resources
Reduce APK Size