App瘦身最佳實踐

bruce0314 8年前發布 | 14K 次閱讀 安卓開發 移動開發

本文的示例代碼主要是基于作者的經驗來編寫的，若你有其他的技巧和方法可以參與進來一起完善這篇文章。

目標

業務方和開發都希望app盡量的小，本文會給出多個實用性的技巧來幫助開發者進行app的瘦身工作。瘦身和減負雖好，但需要注意瘦身對于項目可維護性的影響，建議根據自身的項目進行技巧的選取。

分析app組成結構

做瘦身之前一定要了解自己app的組成結構，然后要有針對性的進行優化，并且要逐步記錄比對，這樣才能更好的完成此項工作。目前as的2.2預覽版中已經有了apk分析器，功能相當強大，此外你還可以利用 nimbledroid 來分析apk。nimbledroid是一個強大的工具，推薦一試。

image_1ar7h642m1v52g0p1r5c4fo1idc4e.png-79.1kB

我們都知道apk是由：

  • asserts

  • lib

  • res

  • dex

  • META-INF

  • androidManifest

這幾個部分構成的。下面我會利用as的分析工具，以微信、微博、淘寶為例進行講述。

image_1ar5097i31eqm12kp1ndlbilos59.png-36.3kB

開始分析后幾秒鐘就能輸出結果，你還可以看到具體類目占的百分比，清晰明了。旁邊的“對比”按鈕提供了diff的功能，讓你可以方便的進行apk優化前后的對比，簡直利器。

image_1ar50k0hl4ek1b8k8fd14bjg9d13.png-63.8kB

image_1ar50n9r11tha15la1gpi1uqs19d81t.png-90.8kB

assets

assets目錄可以存放一些配置文件或資源文件，比如webview的本地html，react native的jsbundle等，微信的整個assets占用了13.4M。如果你的應用對本地資源要求很少的話，這個文件應該不會太大。

image_1ar50vjva119s1abt9it64n1pbfm.png-120.2kB

lib

lib目錄下會有各種so文件，分析器會檢查出項目自己的so和各種庫的so。微博和微信一樣只支持了arm一個平臺，淘寶支持了arm和x86兩個平臺。

image_1ar8g77ucuj7ffo14hs15a1lknm.png-36.4kB

淘寶：

image_1ar8gsi62hbg15711m1l1l1816oo2a.png-23.6kB

resources.arsc

這個文件是編譯后的二進制資源文件，里面是id-name-value的一個map。因為微信做了資源的混淆，所以這里可以看到資源名稱都是不可讀的。

image_1ar50ru80tkj165u1v5g90j1tte9.png-133.3kB

索性放個微博的圖，易于大家理解：

image_1ar8ggv1q4ac6m100pd4r7uo1g.png-80.1kB

META-INF

META-INF目錄下存放的是簽名信息，用來保證apk包的完整性和系統的安全性，幫助用戶避免安裝來歷不明的盜版apk。

image_1ar8gijsiudo1h99lc89leiic1t.png-28kB

res

res目錄存放的是資源文件。包括圖片、字符串。raw文件夾下面是音頻文件，各種xml文件等等。因為微信做了資源混淆，圖片名字都不可讀了。

image_1ar5143g519urnco1tbt2f3158k1j.png-35.6kB

微博就沒有做資源混淆，所以可讀性較好：

image_1ar8gefrd1anu1q5b5h170d1rie13.png-57.3kB

dex

dex文件是java代碼打包后的字節碼，一個dex文件最多只支持65536個方法，這也是為什么微信有了三個dex文件的原因。

image_1ar8g2r9keg21dn1s8grcur7v9.png-5.1kB

因為dex分包是不均勻的，你可以理解為裝箱，一個箱子的大小是固定的，但你代碼的量是不確定的，微信把前兩個箱子裝滿了，最后還剩了2m多的代碼，這些代碼也占用了一個箱子，最終產生了上圖不均勻的結果。

現在，我們已經知道了apk中各個文件的大小和它們占的比例，下面就可以開始針對性的進行優化了。

優化assets

assets中會存放資源文件，這個目錄中各個app存放的內容都有所不同，所以優化也比較難。自從引入RN以來，這個目錄下還會有jsbundle的信息。如果你有地址選擇的功能，這里還會存放地址的映射文件（可參考全名k歌）。對于這塊的資源，as是不會進行主動的刪減的，所以一切都是需要靠開發者進行手動管理的。

全名k歌中的bundle文件：

image_1arn9rc731t40m3kgsa1md11ohg3u.png-126.1kB

刪除無用字體

中文字體是相當大的，我一直不建議將字體文件隨意丟棄到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大呢。

image_1ara1tf2ucmeetq14v510a21fob1d.png-16.1kB

image_1ara1mtufm781bbs1khag1k21ag.png-22.2kB

  • svg：549字節

  • png：375字節（單一分辨率）

  • ion-font：1.1kb

動態下載資源

字體、js代碼這樣的資源能動態下載的就做動態下載，雖然這樣會有出錯的可能性，復雜度也會提升，但這個對于app的瘦身和用戶來說是有長遠的好處的。如果你用了RN，你就可以在app運行時動態去拉取最新的代碼，將圖片和js代碼一并下載后解壓使用。

壓縮資源文件

有些資源文件是必須要隨著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 {
            try {
                if (zipStream != null) {
                    zipStream.close();
                }
                if (bufferedStream != null) {
                    bufferedStream.close();
                }
                if (fileStream != null) {
                    fileStream.close();
                }
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }

全名k歌中的assets目錄下我就發現了大量的zip文件：

image_1arn9mkkmm061j631b3f1ag7a3i3h.png-26.5kB

android上也有一個 7z庫 幫助我們方便的使用7z。這個庫我目前沒用到，有需求的同學可以嘗試一下。

優化lib

配置abiFilters

一個硬件設備對應一個架構（mips、arm或者x86），只保留與設備架構相關的庫文件夾（主流的架構都是arm的，mips屬于小眾，默認也是支持arm的so的，但x86的不支持）可以大大降低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"
    }
}

之后生成的apk中就會排出多余的平臺文件了。armeabi就不用說了，這個是必須包含的，v7是一個圖形加強版本，x86是英特爾平臺的支持庫。

image_1arsrvqedh49dju1s7ulkf13du13.png-61.3kB

分析用戶手機的cpu

我們在舍棄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 來檢查出可以優化的部分，比如一些空的引用。

進行資源名稱混淆

微信團隊開源了一個資源混淆工具， 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存儲的字符要小，所以整個文件的大小肯定也要小一些。

關于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

image_1arn2sdp8ip3cj31j9m1vofcajm.png-81.6kB

每一個資源文件（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

image_1arn41udjrb91fku103b193a2qe13.png-68.3kB

這里有一項SHA1-Digest-Manifest的值，這個值就是MANIFEST.MF文件的SHA-1并base64編碼后的值。后面幾項的值是對MANIFEST.MF文件中的每項再次SHA1并base64編碼后的值。所以你會看到在manifest.mf中的資源名稱在這里也出現了，比如 abc_btn_check_material 這個系統資源文件就出現了兩次。

MANIFEST.MF:

image_1arn47aeq15qc40910rt1u4cvm11g.png-39.3kB

CERT.SF

image_1arn4bje01q921ih1plv15te1n871t.png-44kB

前者是：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瘦身就完全無關了，就是android的apk簽名機制。這塊我平時也沒有仔細研究過，就不誤人子弟了。

優化建議

通過分析得出，除了CERT.RSA沒有壓縮機會外，其余的兩個文件都可以通過混淆資源名稱的方式進行壓縮。

image_1arn6q7ip1p71c1q1kv3s9rigi2a.png-49.6kB

優化res

資源文件的優化一直是我們的重頭戲。如果要和它進行對比，上文的META-INF文件的優化簡直可以忽略不計。這里的優化會分為兩塊，一個是文本資源（shape、layout等）優化，還有一個就是圖片資源優化。

image_1arn8pmpn1ofkdnk14o11hfp15es34.png-116.3kB

說明：

上圖中有-v4，-v21這樣的文件有些是app開發者自己寫的，但大多都是系統在打包的時候自動生成的，所以你只需要考慮自己項目中的drawable-mdpi、drawable-hdpi、drawable-xhdpi、drawable-xxhdpi即可。

通過as刪除無用資源

在as的任何文件中右擊，選擇清除無用資源即可刪除沒有用到的資源文件。

image_1arni457b1j7o1q3pu6f1gn62ju4b.png-57.2kB

不要勾選清除id！如果清除了id，會影響databinding等庫的使用（id絕對占不了多少空間）

image_1arni765omt7bv01qrm1h2d19us4o.png-14.6kB

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也是一種有損壓縮格式，如果感興趣的話也可以嘗試一下。

image_1arn8i7lq1ub56r41a022mj11n32n.png-38.8kB

統一應用風格，減少shape文件

一個應用的界面風格是必須要統一的，這個越早做越好，最基本的就是統一顏色和按鈕的按壓效果。無UI設計和扁平化風格流行后，倒是給應用瘦身帶來了極大的的福利。界面變得越樸實，我們可以用shape畫的東西就越多。

image_1arnj7vjtn1mr74eql8781qjg5v.png-44.5kB

當你的app統一過每種顏色對應的按下顏色后，接下來就需要統一按鈕的形狀、按鈕的圓角角度、有無陰影的樣子、陰影投射角度，陰影范圍等等，最后還要考慮是否支持水波紋效果。

我簡單將按鈕分為下列元素：

元素 屬性01 屬性02 屬性03 屬性04
形狀 正方形 三角形 圓角矩形 圓形
顏色 紅 黃 藍 綠
有無陰影 有 無    
陰影大小 3dp 5dp    
陰影角度 90° 120° 180°  
水波紋效果 有 無    

上面的各個元素會產生大量的組合，shape和layer-list當然可以實現各種組合，但這樣的話光按鈕的背景文件就有多個，很不好維護。

一般為了開發方便，都會把需要用到的各種selector圖片事先定義好，做業務的時候只需要去調用就行。但這大量的selector文件對于業務開發者來說也是有記憶難度的，所以我推薦使用 SelectorInjection 這個庫，它可以將上面的每個元素進行各種組合，用最少的資源文件來實現大量的按壓效果。

用庫雖然好，但庫也會帶來學習成本，所以引入者可以將上述的組合定義為按鈕的一個個的style。因為style本身是支持繼承的，對于這樣的組合形態來說，繼承簡直是一大利器。當你的style有良好的命名后，調用者只需要知道引入什么style就行，至于你用了什么屬性別人才不希望管呢。如果業務開發中有一些特別特殊的按壓狀態，沒有任何復用的價值，那你就可以利用庫提供的豐富屬性在layout文件中進行實現，再也不用手忙腳亂的到處定義selector文件了。

image_1arnkegaj1eug1dvsafj1ao71e7p6p.png-37.7kB

我將不能繼承和不靈活的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的便利性。

image_1ars0g9partf41i1g1lnt8fogm.png-58.4kB

限制靈活性，減少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的重構功能自動完成，絕不拖泥帶水。

image_1asesb6fq1dfu1df71iu0117ps8c9.png-142.6kB

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

2. ListHeader

image_1arsqihk3bdg1p281ks0phricam.png-149.8kB

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加頭的工作。 這段代碼我很久沒動過了，有利有弊，放在這里我也僅僅是舉個例子，希望可以幫助大家擴展下思路。

動態下載圖片

做過濾鏡和貼紙的同學應該會注意到貼紙、表情這類的東西是相當大的，對于這類的圖片資源我強烈建議通過在線商店進行獲取。這樣既可以讓你踏踏實實的賣貼紙，又可以減小應用的大小。這么做雖然有一定的復雜度和出錯概率，但投入產出比還是很不錯的。

image_1arnj0n951qd7ua1pl44uk16ak5i.png-103kB

分門別類放置不同分辨率的圖片

這個雖然不算是app大小的優化，但是如果你放錯了圖片，對于app啟動時的 內存大小會有一定的影響 ：

思考一下，如果把一個本來應該放在drawable-xxhdpi里面的圖片放在了drawable文件夾中會出現什么問題呢？

在xxhdpi設備上，圖片會被放大3倍，圖片內存占用就會變為原來的9倍！

國內也有很多人說可以用一套圖片來做，不用出多套圖，借此來達到app瘦身和給設計減負的目的。谷歌官方是建議為不同分辨率出不同的圖片，為此國內也有不少文章討論過這件事情，這篇總結的不錯推薦一讀。

每次說到這個話題的時候總有很多人有不同的看法，況且很多人還不知道.9圖也是需要切多份的，所以這里我還是先分析一下大廠的放圖策略，最后咱們再討論下較優的方案。

1. 淘寶

mdpi：

image_1arnmbr6n2sji90tas1s0k1g7176.png-84.4kB

mdpi中存留了一些android原始的icon，這個從命名和前綴就能看出來。通過圖片大小分析，這個目錄下面都是一些很小的icon，還有一些沒有用到的icon（這個launcher圖片也很好的說明了淘寶的歷史）。

hdp：

image_1arnmlnf92cv1oca1riu196t1j7o7j.png-93.2kB

hdp中分為兩部分：表情和其他圖片。f+數字的圖片都是表情圖片，淘寶僅僅有一套表情圖片，并且都放在這個目錄下。除了少量的圖片和mdip的圖片一致（比如用戶頭像的place_holder）外，其余的圖片和mdpi的圖片完全不同。順便說一下，此目錄下除了表情之外，其余的都是一些小icon，絕對屬于尺寸很小的那類。

xhdpi：

image_1arnn1tc416n1s0h58f1bnc1dpi80.png-98.4kB

xhdpi又和hdpi不同了，它里面有大量的國家icon。除此之外就是一些對清晰度要求較高的icon。

xxhdpi：

image_1arnnj2f0k8v1moek63ggej1s97.png-58.1kB

xxhdpi就沒什么東西了，幾張圖而已。

其他：

image_1arnnptoucj31n4h1g4n13ft1b0v9k.png-17kB

有后綴的文件夾中除了5張左右的淘寶自己的icon外，其余都是系統的圖片，均以abc開頭。我不清楚淘寶到底有沒有使用到這些圖片，但我可以肯定地說其中有著冗余圖片，或許有著進一步優化的方案。

總結：

淘寶的放置圖片策略是大量的圖片在hdpi，xhdpi中，比如表情圖在hdpi中，國家圖在xhdpi中，大多數圖片都僅有一套，少數全局的icon是會有多張的情況（極少，估計只有十幾張）。xxhdpi和mhdpi僅僅作為補充，沒有太大的作用。

淘寶最令人好奇的點在于它的資源文件很小，但是so文件相當大：

image_1arnuhm0o1k6813581o0dg5m1jung4.png-47.3kB

2. 微博

微博是一個典型的android風格的app，它的drawable全都是有后綴的，完全符合安卓標準的默認打包策略，它還有根據像素密度的圖片，甚至有ldpi的目錄。

image_1arnoj1rl1h2m9trqiusqh5jva1.png-41.8kB

mdpi-v4

image_1arnopum9ogf121a68612ga4peae.png-94.7kB

mdpi中有大量的小icon，里面有個叫做share_wx的，從名字一下子就知道是微信分享的icon，但實際是微博的logo，比較有趣。其余的都是一些邊邊角角的圖標，量不大，所以主力圖肯定不在這里。

hdpi-v4

image_1arnouv1n1cpgdqc1evj12gdmdoar.png-205.6kB

這是微博圖片存放的主要目錄，有很多大背景和表情，微博的表情圖片和淘寶一樣都是在hdpi中的，它以lxh，emoji等前綴開頭，用來區分不同風格的表情。

xhdpi-v4和xxhdpi-v4*

image_1arnp6ag51jt7cka1b3d1slsal5b8.png-195.9kB

這里放了一些背景大圖，我也發現了大量和hdpi中一樣的圖片，所以可以大膽的假設微博是做了不同像素的圖片的。這也證實了我的想法——微博是很標準的android應用。

ldpi-v4

image_1arnpeog7cik19hsage4u020ibl.png-58.3kB

這個目錄的確沒什么用，微博自身也不會維護這個目錄，這全都是第三方庫和應用商店給的圖片，微博開發者只需要放進來就好。

sw400dp和sw32dp-400dp

image_1arnpip3j1iulg7ecio1gtcs1fc2.png-48.7kB

這些目錄放了一些為不同分辨率準備的長得相同的icon，當然還有微博自己的logo。

3. 微信

通過上面的分析，我們是不是可以得出一些經驗了呢？

  • 大量的圖片都在hdpi和xdpi中

  • 表情圖片在hdpi中

  • anim目錄中都是xml文件

  • drawable目錄中有大量的xml和少量的png和.9圖

  • layout文件中是全部的xml

  • raw中放置音頻

  • svg圖片在raw、drawable或assets中

  • 最大的文件夾是圖片文件

  • layout文件較小

  • 相同的圖片，高分屏的肯定比低分屏的大

ok，現在咱們就可以來看微信的資源了，混淆怕啥，友盟混淆的abcd代碼都能看懂，微信的adcd資源也應該不難。

raw(a9)

image_1arnqa3vfd76lrn78n3fsdfcf.png-64.3kB

這個目錄中放置了大量的svg圖片和mp3文件，從專業的角度來想，drawable目錄下肯定不會放mp3，所以這個肯定是raw文件了。這個目錄下有大量的svg，所以可以看出微信已經實現了全svg化，并且已經在線上穩定運行了。這點在微信早期的公眾號上也可以得到佐證，詳細請看 Android微信上的SVG 。

文中提到了：

第一步，拿到.svg后綴的資源文件（UI很容導出這種圖片），放在raw目錄下而不是drawable目錄。

第二步，把 R.drawable.xxx 換成 R.raw.xxx；把 @drawable/xxx 換成 @raw/xxx。

layout(f)

image_1arnqqs2fbl9j932ie1llt1tgacs.png-14kB

現在有了兩個線索，那么初步估計上面的三個目錄肯定是我們常見的目錄，否則不會那么大。

image_1arnr4ghkld6r0r1r9910e81ussd9.png-51.8kB

打開f后發現這個就是layout文件，所以其余的肯定就是圖片文件了。

hdpi(y)

image_1arnr8rn015lj3in76ou621tqadm.png-97.9kB

y是2.9m，里面有大量的表情，所以我判斷它是hdpi，為了更加證實這個猜測，我找到了兩張相同的圖片。

a2中：

image_1arnrkkh21ooi1mquuq9sh614hueg.png-101.4kB

y中：

image_1arnrng70t9s7vnpj36alf5het.png-61.4kB

y中圖片是11kb，a2中圖片是76kb，這明顯說明y是hdpi，a2是xhdpi。

xhdpi(a2)：

image_1arnrscp011v6ptk1r5q1tn01mudfa.png-95.8kB

xhdpi中的圖片和hdpi中的圖片相同的不多，微信在這里放的是一些大圖。

drawable(k)

image_1arns8oe9167th553bb66t857fn.png-72.5kB

drawable本身沒啥可以說的，但是微信的drawable中.9圖份額很少，所以我在想是否svg可以在一定的程度上完成一些.9的工作呢？

總結：

  1. 微信的表情都在hdpi中，僅有一套圖片，這點幾乎已經成為了標準

  2. 微信已經實現了svg化，svg圖片在raw中

  3. 微信傾向于把較大的圖片放在xhdpi中，僅出一套圖

  4. 微信和淘寶一樣都是盡量選擇一套圖來完成需求

優化思路

通過分析得出，傳統的出多個分辨率圖片的做法在大廠中已經發生了改變，阿里系、騰訊系的產品都采用了一套圖走天下的路子。這樣的做法還是有利有弊的，權衡之下我給出如下建議：

  • 聊天表情就出一套圖，放在hdpi中

  • 純色小icon用svg做

  • 背景等大圖，出一套放在xhdpi中

  • logo等權重較大的圖片可針對hdpi，xhdpi做兩套圖

  • 如果某些圖在真機中確實展示異常，那就用多套圖

  • 如果遇到奇葩機型，可針對性的補圖

成年人不看對錯，只看利弊，所以還請大家權衡一二。

優化圖片

對于圖片的優化應該是放在優化res一節中進行講解的，但是因為圖片這塊比重太大了，所以我讓其獨立成為一節。本節主要會從圖片格式、復用圖片和壓縮圖片三個方面進行講解。

使用VectorDrawable

想要做好圖片的優化工作最重要的一點是知道應該選擇什么樣的圖片格式，對于這點我推薦一個 視頻 ，方便大家進行深入的了解。

image_1ar7a260ogr2cldradmbl132o20.png-154.3kB

這是谷歌給出的建議，簡單來說就是：VD->WebP->Png->JPG

  1. 如果是純色的icon，那么用svg

  2. 如果是兩種以上顏色的icon，用webp

  3. 如果webp無法達到效果，選擇png

  4. 如果圖片沒有alpha通道，可以考慮jpg

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轉VectorDrawable

先去這里下載svg圖片：

image_1as2a4ja5h64os6ujvtvj7gt13.png-39.4kB

然后利用這個 在線工具 轉換成VectorDrawable。

image_1as29ve0pl661sn71po24df1cm09.png-60.8kB

svg的兼容性

support庫的代碼質量還是不錯的，但是svg畢竟是一個圖片格式，所以使用svg前還是需要格外慎重的。我寫了一個demo，把用到的所有屬性都做了示例，然后利用云測服務進行兼容性測試。

image_1as22vm0n1avk1bgvukv18561krt1g.png-199.2kB

測試svg也挺簡單的，首先看會不會崩潰，然后看各個分辨率、各個api下是否會有顯示不正常的情況，如果都ok，那么就可以準備引入到項目里面了。

svg的使用技巧

設置恰當的寬高

svg圖片是有默認寬高的，設計也會給出一個默認寬高，設置一個合適的默認寬高對以后的圖片復用會有很大幫助。

image_1as915i10in41fqg71il71fifm.png-88.2kB

image_1as912sge1hkm1jkgm411j5favp9.png-96kB

TextView中drawableLeft等屬性是不能設置圖片的寬高的，但ImageView可以。如果你的圖片會被復用，建議將圖片的寬高設置為TextView中的drawable寬高。

利用padding和scaleType屬性

ImageView中的svg默認情況下是會隨著控件的大小而改變的，它不會像png那樣保持自己的原始大小。我們可以利用這一特性，再配合padding和scaleType屬性來完成各種效果。

image_1as91pho95r229p14nd1siuhpt1g.png-4.7kB

  1. 圖1：60x60，svg自動鋪滿控件

  2. 圖2：30x30，svg被壓縮到原始大小以下

  3. 圖3：60x60，使用scaleType，讓svg保持原始寬度

  4. 圖4：60x60，使用padding，對svg進行任意比例的壓縮

<ImageView
    android:layout_width="60dp"
    android:layout_height="60dp"

    android:tint="@color/blue"
    app:srcCompat="@drawable/非死book"
    />

<ImageView
    android:layout_width="30dp"
    android:layout_height="30dp"

    android:tint="@color/orange"
    app:srcCompat="@drawable/非死book"
    />

<ImageView
    android:layout_width="60dp"
    android:layout_height="60dp"

    android:scaleType="centerInside"
    android:tint="@color/red"
    app:srcCompat="@drawable/非死book"
    />

<ImageView
    android:layout_width="60dp"
    android:layout_height="60dp"

    android:padding="10dp"
    android:tint="@color/green"
    app:srcCompat="@drawable/非死book"
    />

svg的問題和解決方案

svg有很多好處，但也免不了一些問題，本小節中 寫代碼的猴子 提出了一些很實用的建議，感謝他的幫助。

容易寫錯屬性

svg的支持是要通過 app:srcCompat 這個屬性來做的，如果稍微一不注意寫成了src，那么就會出現低版本手機上不兼容的問題。你可以嘗試通過配置Lint規則或是利用腳本進行文件的遍歷等方式來防止出現因開發寫錯屬性而崩潰的問題。

不兼容selector

將svg放入selector中的時候可能會出現一些問題，stackoverflow上也給出了 解決方案 ，就是下面這段代碼放在Activity中。

static {
    AppCompatDelegate.setCompatVectorFromResourcesEnabled(true);
}

開啟這個flag后，你就可以正常的使用Selector這樣的DrawableContainers了。

不支持自定義控件

AppCompatActivity會自動將xml文件中的ImageView替換為AppCompatImageView，但是如果用了你的自定義控件，那么這種機制就無效了，所以自定義控件中盡量使用AppCompatImageView來代替ImageView，使用 setImageResource()來設置資源。如果你的自定義控件中需要獲得drawable或者是有自定義需求，那么可以參考AppCompatImageView中的svg的helper類來編寫。

public class AppCompatImageHelper {

    private final ImageView mView;

    public AppCompatImageHelper(ImageView view) {
        mView = view;
    }

    public void loadFromAttributes(AttributeSet attrs, int defStyleAttr) {
        TintTypedArray a = null;
        try {
            Drawable drawable = mView.getDrawable();

            if (drawable == null) {
                a = TintTypedArray.obtainStyledAttributes(mView.getContext(), attrs,
                        R.styleable.AppCompatImageView, defStyleAttr, 0);

                // If the view doesn't already have a drawable (from android:src), try loading
                // it from srcCompat
                final int id = a.getResourceId(R.styleable.AppCompatImageView_srcCompat, -1);
                if (id != -1) {
                    drawable = AppCompatResources.getDrawable(mView.getContext(), id);
                    if (drawable != null) {
                        mView.setImageDrawable(drawable);
                    }
                }
            }

            if (drawable != null) {
                DrawableUtils.fixDrawable(drawable);
            }
        } finally {
            if (a != null) {
                a.recycle();
            }
        }
    }

    public void setImageResource(int resId) {
        if (resId != 0) {
            final Drawable d = AppCompatResources.getDrawable(mView.getContext(), resId);
            if (d != null) {
                DrawableUtils.fixDrawable(d);
            }
            mView.setImageDrawable(d);
        } else {
            mView.setImageDrawable(null);
        }
    }

    boolean hasOverlappingRendering() {
        final Drawable background = mView.getBackground();
        if (Build.VERSION.SDK_INT >= 21
                && background instanceof android.graphics.drawable.RippleDrawable) {
            // RippleDrawable has an issue on L+ when used with an alpha animation.
            // This workaround should be disabled when the platform bug is fixed. See b/27715789
            return false;
        }
        return true;
    }
}

不兼容第三方庫

市面上有很多優秀的圖片加載庫，它們一般都會支持多種圖片路徑的加載，比如磁盤圖片，網絡圖片，res圖片等等，對于svg這樣的圖片格式，它們是否支持就要大家結合自己的圖片框架進行調研了。像glide目前（2016.09.10）就不支持加載本地的svg圖片。

PS：因為第三方庫更新十分頻繁，建議在用到svg的時候再調研。

性能問題

關于動畫和性能方面的問題， 《Android Vector曲折的兼容之路》 中給出了具體的示例和建議：

  1. Bitmap的繪制效率并不一定會比Vector高，它們有一定的平衡點，當Vector比較簡單時，其效率是一定比Bitmap高的，所以為了保證Vector的高效率，Vector需要更加簡單，PathData更加標準、精簡，當Vector圖像變得非常復雜時，就需要使用Bitmap來代替了。

  2. Vector適用于icon、Button、ImageView的圖標等小的icon，或者是需要的動畫效果，由于Bitmap在GPU中有緩存功能，而Vector并沒有，所以Vector圖像不能做頻繁的重繪。

  3. Vector圖像過于復雜時，不僅僅要注意繪制效率，初始化效率也是需要考慮的重要因素。這點可以參考 微信中的svg 。

  4. SVG加載速度會快于PNG，但渲染速度會慢于PNG，畢竟PNG有硬件加速，但平均下來，加載速度的提升彌補了繪制的速度缺陷。

不便于管理

svg是沒辦法在文件目錄下進行預覽的，其放置的目錄也和其他圖片不同，如果沒有做好管理工作，未來的drawable目錄就會變得越發的混亂。其實，對于目錄或者包內文件的管理有個很簡單的原則： 同目錄多類型文件，以前綴區分；不同目錄，同類型文件，以意義區分。

drawable目錄下有多種類型的文件，我們利用英文排序的原則將這些文件簡單分為svg、.9圖、shape、layer-list這幾類。

image_1asbj36rs1k0a13rn1bmb2p01dumm.png-15.9kB

通過規范特定的前綴，就可以形成一個便于查找和理解的目錄樹，以達到分類的目的。

image_1asbk0j4417s53ed9vphma1cea13.png-81.3kB

在特定前綴的規范下，次級分類的命名就可以按照功能或用途來做區分，比如button或share的icon就可以用不同的前綴來標識。強烈建議開發和設計定一個命名標準，這樣開發就不用對設計出的圖片進行重命名了，而且還可以保證兩個部門有一致的認知。

這個僅僅是一個簡單的分類方法，在實際中需要靈活使用。如果一些文件都是用于某種特定類型的，那么可以自定義前綴。比如我對于按鈕使用的形狀就用了btn作為前綴，而忽略了它們本身的文件類型。

image_1ase39vaiud91foq188ilif1n219.png-13.8kB

不便于預覽

svg是一個特殊格式的文件，可預覽性大大低于png等常用的圖片格式，但幸好win下可以直接在文件目錄下預覽svg圖像，效果十分不錯。

image_1asbld3ar1ptn1pne1l3hrgl12v51g.png-14.6kB

但是vd是一個xml文件，預覽器很難識別出這是什么格式，所以對于vd的預覽才是一個難點。我之后準備寫一個as插件來解決這個問題。

使用WebP

webp 作為一種新的圖片格式，從Android4.0+開始原生支持，但是不支持包含透明度，直到4.2.1+才支持顯示含透明度的webp，使用的時候要特別注意。

webp相比于png最明顯的問題是加載稍慢，不過現在的智能設備硬件配置越來越高，這點差異越來越小。騰訊之前有一篇 對于webp的分析文 十分不錯，如果你準備要用webp了，那么它絕對值得一看。

注意：如果你的項目最低支持到4.2.1，那么你可以繼續閱讀了，如果項目還需要支持到4.0版本，我建議暫時不要上webp，成本太高。

png轉webp

我們可以通過 智圖 或者 isparta 將其它格式的圖片轉換成webP格式。

image_1asbgag1erb11i6b1pqg1gga18is9.png-1045.2kB

webp的問題

兼容性不好

官方文檔中說只有在4.2.1+以上的機型，才能解析無損或者有透明度調整的webp圖片，4.0+才開始支持無透明度的webp圖片。我通過云測發現，在4.0~4.2.1的系統中，帶有透明度的webp圖片雖然不會崩潰，但是完全無法顯示。

image_1asbo6vvd1o9roku1keqa9r4om1t.png-33.5kB

《APK瘦身記，如何實現高達53%的壓縮效果》 一文中也提到有alpha值的jpg圖片，經過webp轉換后，無法在4.0，4.1的Android系統上運行的問題，具體原因見 官方文檔 ：

image_1asbq6bejqva1mtuvaj3kc1al22n.png-14kB

除了兼容性問題外，webp在某些機型和rom上可能會出現一些“神奇”的問題。在三星的部分機型上，部分有alpha通道的圖中會有一條很明顯的黑線（三星的rom對于shape的alpha的支持也有問題，是紅線）。在小米2刷成4.xx的手機上，系統未能正確識別xml文件中描述的webp圖片，也會導致加載webp失敗。

不便于預覽

因為webp的圖片格式是很難預覽的，as也沒有辦法直接預覽webp格式，我一般是通過chrome瀏覽器打開webp，十分不方便。

image_1asbq487rk9b1ff514p7nrefe02a.png-115.1kB

我們知道gradle在build時，有一個mergeXXXResource Task,它將項目的各個aar中所有的res資源統一整合到 /build/intermediates/res/flavorName/{buildType} 目錄下。

webpConvertPlugin 這個gradle插件可以在mergeXXXResource Task和processXXXResource Task之間插入一個task，這個task會將上述目錄下的drawable進行統一處理，將項目目錄里的png、jpg圖片(不包含.9圖片，webp轉換后顯示效果不佳)批量處理成webp圖片，這樣可以讓我們在日常開發時用png、jpg，正式發包時用webp。

復用圖片

復用相同的icon

我們通過svg可以讓一張圖片適用于不同大小的容器中，以達到復用的目的。最常見的例子就是“叉”，除非你的x是有多種顏色的，那么這種表示關閉的icon可以復用到很多地方。

image_1arst9t8p1tq61k8117n31489eg22a.png-12.5kB

image_1as1sslhf1r0a10mr18rnccg1m6o9.png-24.5kB

上圖中我通過組合的方式將長得一樣的icon（非死book、renren等）復用到了不同的界面中，不僅實現了效果，可維護性也不錯。

使用Tint

著色器（tint）是一個強大的工具，我將其和shape、svg等結合后產生了化學反應。TintMode共有6種，分別是:add，multiply，screen，srcatop，srcin（默認），src_over。下圖是 一篇文章 中的總結，說明了其靈活性

image_1as22gvi1jdc16ji1p67a3dqu613.png-67.8kB

一般用默認的模式就可以搞定大多數需求了，使用到的控件主要是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，一定要通過云測等手段做下兼容性測試，下圖是我對于上述屬性的測試結果：

image_1as2382s1sfleismn21q991h8b1t.png-218.6kB

復用按壓效果

一個應用中的list頁面都應該做一定程度的統一，對于有限長度的list，我們可能偏向于用ScrollView做，對于無限長的list用RecyclerView做，但對于它們的按壓效果我強烈建議采用同一個樣式。

image_1arsu35djprokc73jpp3c1cj22n.png-75.1kB

以微信為例，它的所有列表都是白色的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" />

image_1art1llie1j2j1hac1hmtndbe1g9.png-28.3kB

這種方法雖好，但是不要濫用。需要看代碼的人知道這種思路，否則會出現不好維護的情況。當設計真的是認為兩個圖有如此的關系的時候才可這樣實現，萬不可耍小聰明。

壓縮圖片

圖片的壓縮策略是：

  1. 優先壓大圖，后小圖
  2. 不壓.9圖（svg在俠義上不算圖）
  3. 對于開屏大圖片的壓縮需注意力度，要和設計確認后再做
  4. 對于體積特別大(超過50k)的圖片資源可以考慮有損壓縮

關于如何量化兩張圖片在視覺上的差別，Google 提供了一個叫 butteraugli 的工具，有興趣的同學可以嘗試一下。

ImageOptim

mac上超好用的圖片壓縮工具是 ImageOptim ，它集成了很多好用圖片壓縮庫，很多blog中的圖片也是用它來壓縮的。

image_1ar7a83kr1lrns861di8q3mm6p2q.png-639.7kB

值得一提的是，借助Zopfli，它可以在不改變png圖像質量的情況下使圖片大小明顯變小。

pngquant

pngquant 也是一款著名的壓縮工具，對于png的療效還不錯，但它不一定就適合app中那種背景透明的小icon，所以對比起tinypng來說，優勢不明顯。

image_1art6qlf812hk1c19l0h1te413u6m.png-56.6kB

tinypng

tinypng 是一款相當著名的商用壓縮工具，tinypng提供了開放接口供開發者開發屬于自己的壓縮工具（付費服務）。tinypng對于免費用戶也算友好，每月可以免費壓縮幾百張圖片。

我用 gradle插件 來使用tinypng，更加簡單方便。我一般的做法是發版本前才做一次圖片壓縮，每次debug的時候是直接跳過這個task的，完全不影響日常的debug。

tinyinfo {
    apiKey = 'xxxxxxxxx'
    //編譯時是否跳過此task
    skip = true
    //是否打印日志
    isShowLog = true
}

有人說tinypng的缺點是在壓縮某些帶有過渡效果（帶alpha值）的圖片時，圖片可能會失真，對于這種圖片你可以將png圖片轉換為webP格式。

注意事項

aapt默認會在打包時進行圖片的壓縮工作（無論你知不知道，它一直在默默的工作），如果你已經做了圖片壓縮了，那么建議手動禁止這個功能，否則“可能會”出現圖片二次壓縮后反而變大的情況，原因請看： Smaller PNGs, and Android’s AAPT tool 。

image_1art7sk821fugmvh172i1tnkhi713.png-404.5kB

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
}

image_1arpdkoh618hc5ss1ud51buhf79ho.png-172.9kB

通過分析你可以知道代碼的具體情況了，比如某個第三方庫是否已經不用了、自己項目的哪個包的方法數最多、目前代碼情況是否合理等等。

statistic

我是通過 Statistic 這個as插件來評估項目中開發人員寫的代碼量的，它生成的報表也不錯：

image_1arpdsqips6jp323969fivcqi5.png-123.4kB

image_1arpduoqa107u8vn8cv1thm1nn0ii.png-145.2kB

現在我可以知道：

哪些類空行數太多，是不是沒有按照代碼規范來；

哪些類的代碼量很少，是否有存在的必要；

哪些類行數過多，是否沒有遵守單一職責原則，是否可以進行進一步的拆分

apk method

你還可以用 apk-method-count 這個工具來查看項目中各個包中的方法數，它會生成樹形結構的文檔，十分直觀。

image_1arpedp5l1vrn191t1j7b1gkm7q2iv.png-258.2kB

利用Lint分析無用代碼

如果你想刪掉沒有用到的代碼，可以借助as中的 Inspect Code 對工程做靜態代碼檢查。

image_1arpbjnn0gq41604v1p82g1p4dgh.png-52.8kB

image_1arpbrhdp2221n1k7ob15ae1ijrgu.png-141.6kB

Lint是一個相當強大的工具，它能做的事情自然不限于檢查無用資源和代碼，它還能檢測丟失的屬性、寫錯的單位（dp/sp）、放錯像素目錄的圖片、會引起內存溢出的代碼等等。從eclipse時代發展到現在，lint真的是越來越方便了，我們現在只需要點一點就行。

Lint的強大也會帶來相應的缺點，缺點就是生成的信息量過多，不適合快速定位無用的代碼。我推薦的流程是到下圖中的結果中直接看無用的代碼和方法。

image_1arpccgij2hjtgi1s7nuob8o5hb.png-160.3kB

注意：

這種刪除無用代碼的工作需要反復多次進行（比如一月一次）。當你刪除了無用代碼后，這些代碼中用到的資源也會被標記為無用，這時就可以通過上文提到的 Remove Unused Resources 來刪除。

通過proguard來刪除無用代碼

手動刪除無用代碼的流程太繁瑣了，如果是一兩次倒還會帶來刪除代碼的爽快感，但如果是專人機械性持續工作，那個人肯定要瘋的。為了保證每次打包后的apk都包含盡可能少的無用代碼，我們可以在build.gradle中進行如下配置：

android {
    buildTypes {
        release {
            minifyEnabled true // 是否混淆
        }
    }
}

雖然這種方式成果顯著，但也需要配合正確的proguard配置才能起作用。

這種利用混淆來刪除代碼的方式是一種保險措施，真正治本的方法還是在開發過程中隨手刪除無用的代碼，畢竟開發者才是最清楚一段代碼該不該被刪的。我之前就是隨手清理了下沒用的代碼，然后就莫名其妙的不用使用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全開，并且會有一些幫助調試的工具（比如： leakcanary ， stetho ），我們可以通過 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文件：

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的大小進行持續的統計和追蹤，有余力的小公司也可以多多借鑒一下。希望大家閱讀完本文后可以著手對項目進行優化工作，帶來真正的收益。

 

參考資料：

smaller apk系列文章：

https://medium.com/google-developers/smallerapk-part-1-anatomy-of-an-apk-da83c25e7003

 

來自：http://www.jianshu.com/p/8f14679809b3

 

 本文由用戶 bruce0314 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
 轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！