作者 ｜ 張祖橋

前言

目前，安卓端對于包體積的優化方案已經多如過江之鯽，我們系列的上一篇文章介紹了 Class 字節碼的優化，本期我們將關注點聚焦到資源文件上，從資源二進制文件的全新角度，拓展出包體積優化的新思路。

在資源文件優化方面，通常的優化手段多集中在圖片/文件壓縮、資源文件名稱混淆、離線下載資源文件等方面，而我們的新思路基于對于常規思路的深度分析及思考。

一開始，我們是從資源文件名稱混淆入手優化，業界對于資源文件名稱混淆方案，最為熟知的開源項目當屬 AndResGuard，該項目優化目標為資源文件目錄 res 內的文件，其優化點如下：

• 對重復的資源文件，以計算 md5 值的方式來判斷是否重復并只保留一份;
• 對資源文件名稱進行縮短，即名稱混淆;
• 對 APK 中的內容采取 7zip 壓縮優化;

按照此項目進行優化，總體收益可以達到非常可觀的 MB 級別。但完成此項目的優化后，資源文件的進一步優化便達到瓶頸。

為了在此基礎上更好的實現優化資源大小，我們需要了解資源文件目錄 res 所包含的文件類型及其大小的分布情況。以抖音為例，下表是對其包含的子文件夾名稱、文件數量、將文件夾 zip 壓縮后大小的梳理，以文件數量降序排序：

從上表，可以看到：

• drawable-xxhdpi-v4 目錄下文件數量最多有 6000+，壓縮后文件大小約為 19.5MB。
• drawable 目錄下文件數量排第三，有 4388 個，壓縮后 4.6MB，同時包含圖片和.xml 文件。
• 文件數量排第二和第四的都是 layout 目錄下的布局文件，分別有 5970，2985 個，其文件夾壓縮后大小分別為 12.2MB，8.5MB。布局文件總數近 9K，文件大小約 20.7MB

可見，layout 目錄下的布局文件大小已經和圖片文件不相上下。而這部分如此大的文件，除了有文件名稱的混淆優化之外，是否還有其他優化方式?或者其文件名稱混淆是否徹底?

此外，APK 解壓后的 resources.arsc 文件有 7.3MB 之大。其中包含了 app 所有資源文件名稱和資源字符串值，其中是否也存在冗余字符串?

對于 layout 布局文件，從近萬份之多的文件數量及 20+MB 的文件體積來看，即存在值得探究的必要。我們通過對資源文件的二進制文件格式的解析，并從文件內容被使用的角度分析，發現存在可以刪除的冗余內容。在反復嘗試并解決了各種穩定性和打包兼容問題后，最終研發出了一套針對 Android ARSC/XML 文件格式的包體積優化方案，目前已經落地抖音，實現 2MB 以上的收益。

接下來，本文將深入講解該方案的實現細節。

APK 資源格式優化

我們的核心思路是，以資源路徑縮短為優化出發點，在最終的 APK 文件里，從resources.arsc與 layout 布局文件的二進制文件格式著手，查看其內容結構，尋找可以刪除的未使用字符串，優化文件名稱或者文件里的字符串池。主要分為下面兩個優化點。

資源路徑縮短

資源格式修改

接入 AndResGuard 后，資源文件 res 目錄 -> r，其中的子文件夾和文件名也都被混淆，即：

res/anim/abc_fade_in.xml -> r/a/a.xml

res/anim/abc_fade_in.xml -> r/a/a.xml這是為了減少資源文件路徑，從而減少包體積，自然聯想到，是否還能進一步減少資源文件路徑呢?顯然，如果能將所有文件都放在 r 目錄下，將中間的子文件夾去掉，則可以進一步減少資源文件路徑和 zip 節點數量，一定還有包體收益;順便可以將文件名的后綴去掉，也可以減少文件路徑，即:

r/a/a.xml -> r/a
r/a/b.png -> r/b

由于修改資源文件名稱需要修改resources.arsc文件，這里對resources.arsc 的文件格式分析下：

可以看到，其中包含有 3 個字符串池。

假如我們有一個資源文件abc_fade_in.xml在 res/anim 目錄下，其在resources.arsc文件中 3 個字符串池里的信息如下：

• 全局字符串池(字符串池 1)：主要包含完整文件路徑名，即res/anim/abc_fade_in.xml
• 類型字符串池(字符串池 2)：資源種類名(包括存儲 res 目錄下子文件目錄名)，即anim
• 鍵字符串池(字符串池 3)：文件名，即: abc_fade_in

可以看到，與資源文件名相關的地方有兩處，分別在全局字符串池保存著完整文件路徑名，鍵字符串池保存著文件名，為了將資源路徑縮短，需要同時修改這兩處，即在全局字符串池中修改res/anim/abc_fade_in.xml -> r/f ，在鍵字符串池修改 abc_fade_in -> f。在resources.arsc文件中需要修改的兩處字符串池，如下圖箭頭所示：

然而，在完成資源路徑縮短后，卻發現包體積反而變大了 160K+ !

鍵常量池裁剪

我們知道，文件名稱混淆，其混淆名稱來源于符合文件名稱規范的混淆字符串集合，其中的字符串都是唯一不重合的，所以，字符串集合數量越大，其最長字符串的長度也會越大。

在資源路徑未縮短情況，不同子目錄文件夾下，其使用的文件名稱每次都可以從混淆字符串集合中重新選取，使得其名稱在鍵字符串池中始終保持最短;

其對應的文件名字符串集合為：[a，b，c，d，e]

而在縮短的情況下，由于所有文件都包含在一個文件夾r下，其使用的文件名稱只能來自同一個混淆字符串集合，使其名稱在鍵字符串池中會逐漸變長，同時也會使得路徑字符串跟著變長，導致其整體結果反而變大!如下圖所示：

其對應的文件名字符串集合為：[a，b，c，d，e，f，g，h，i，j]

因此，當所有文件都包含在一個文件夾r下時，無法使得不同子目錄下的文件名得以復用，所以雖然路徑縮短，會使得全局字符串池變小，但鍵字符串池反而會變大。這是因為鍵名默認需要和文件名保持一致。

猜想：resources.arsc文件中，鍵名是否需要和文件名保持一致，更或者，鍵名本身是否有存在的必要?

其實，在經過編譯后，資源文件被使用的地方會被替換成特定的 id 值，比如：

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        // => setContentView(0x7f0b001c); // 替換為id值
    }
}

由此可知，資源文件名稱必然與整型 id 值有著一一對應的關系，這種一一映射的關系可以聯想到：是否只需要根據整型 id 值，就可以找到相應的文件路徑名稱?因為這個過程里完全不涉及鍵字符串的引用。

基于這個想法，我們將鍵字符串池全部替換為單一值"_"， 發現 APK 運行正常。顯然，去掉鍵字符串池，似乎并不會影響 APK 運行期間根據整型 id 值去查找文件路徑。

那么，鍵字符串池中的字符串的作用是什么呢?翻看源碼發現，只有使用類似“資源文件反射”的方式調用，才會獲取鍵字符串池中的字符串值，比如：

// MainActivity.java
// 此處返回值為"_", 因為鍵字符串池已經全部替換為 "_"
String entryName = getResources().getResourceEntryName(R.layout.activity_main);
// 此處返回的id值為0, 因為找不到名為 "abc_fade_in"，類型為"anim"的資源
int id = getResources().getIdentifier("abc_fade_in", "anim", "cn.pkg");

當前項目中，一般沒有使用上述“資源文件反射”獲取資源名稱的使用方式，所以鍵字符串池可以全部替換為單一值"_";目前已知的必須要以這種方式使用資源文件的方式，大多是插件等不在一個宿主項目下的情況，如果需要，可以對這部分字符串名稱進行保留，配置白名單即可。

下圖是resources.arsc文件中鍵字符串池的格式和內容示意圖：

• 偏移數組(標記 1)，數組的值為指向鍵字符串池(標記 2)中每個字符串的偏移值
• 由于需要將鍵字符串池中所有字符串替換為單一值"_"，那么，鍵字符串池中就只有一個"_"字符串，偏移數組也將只有一個元素，其指向鍵字符串池中"_"字符串的起始偏移值 0。

最后，還需將resources.arsc文件中，鍵字符串對應的偏移數組的索引值，所有被調用的地方，全部替換為字符串"_"對應的偏移數組的索引值 0，這樣原有文件名字符串都會換為"_"，鍵字符串池就只剩"_"字符串了。

崩潰和兼容性問題

在項目具體實施灰度中出現了崩潰，發現在 drawable 目錄下的 xml 圖片文件有對其后綴的檢查，如下圖：

frameworks/base/core/java/android/content/res/ResourcesImpl.java

//創建drawable
private Drawable loadDrawableForCookie(@NonNull Resources wrapper, @NonNull TypedValue value, int id, int density) {
    ...
    if (file.endsWith(".xml")) { //對xml文件解析并創建drawable
        final String typeName = getResourceTypeName(id);
        if (typeName != null && typeName.equals("color")) {
            dr = loadColorOrXmlDrawable(wrapper, value, id, density, file);
        } else {
            dr = loadXmlDrawable(wrapper, value, id, density, file);
        }
    } else { //對.png等其他圖片解析并創建drawable
        final InputStream is = mAssets.openNonAsset(value.assetCookie, file, AssetManager.ACCESS_STREAMING);
        final AssetInputStream ais = (AssetInputStream) is;
        dr = decodeImageDrawable(ais, wrapper, value);
    }
    ...
}

因此，我們對 drawable 目錄下的 .xml 后綴不做去除。

上線后，有反饋 6.x 上部分手機啟動慢的現象，經排查發現是其中圖片文件名稱后綴刪除優化，導致的在部分 rom 上 app 啟動慢。排除掉這些兼容性問題，最后，我們僅保留路徑縮短和鍵常量池裁剪優化，而不做文件名后綴去除，即：r/a/a.xml -> r/a.xml，此部分資源路徑壓縮優化收益 300K+。

layout 優化

我們知道，layout 目錄下的布局文件所占包體積很大，從之前的分析可知，resources.arsc文件中有好幾個字符串池，有的字符串池并沒使用可以刪除，而 layout 布局文件與resources.arsc文件的二進制文件格式一致，其中也有字符串池，是否也存在類似的優化點呢?對此，有必要對布局文件的文件格式和內容探究一波，隨意打開一個布局文件，其源代碼和二進制文件格式內容如下：

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:enabled="true"
    android:gravity="center"
    android:background="@color/colorAccent"
    android:layout_width="match_parent"
    android:layout_height="match_parent"/>

從布局文件文件格式上，可以看到，布局文件有一個字符串池 strPool 和一個數組 resMap，為了闡述其作用，假如布局文件中有一個屬性"layout_width"，其在布局文件中包含的信息如下：

• 字符串偏移數組(標記 1)，指向字符串池(標記 2)，用于從字符串池中獲取標簽(如："LinearLayout")或屬性字符串(如："layout_width")
• 字符串池(標記 2)，布局文件中的唯一字符串池，保存布局文件中標簽或屬性字符串名，即："layout_width"
• 屬性數組Resids(標記 3)，包含當前文件所有屬性的整型 id 值，屬性"layout_width"的 id 值：10100F4h。從數組中整型 id 值提示的屬性名(類似：attr_layout_width(10100F4h))，可以看到其屬性名與字符串池中名稱一一對應。

我們知道 layout_width 本身是一個attr屬性，查看系統源碼中的 public.xml，可以看到：

其整型 id 值與上面 layout 文件中的值，即 attr_layout_width 后面的整型 id 值完全一致，都是0x010100f4。系統屬性的 id 值是固定的，而且，一個布局文件的屬性由字符串名稱或整型 id 值來唯一標識，那么，這里是否只需要 id 就可以標識屬性，而屬性的字符串名可以刪除?

猜想：每個屬性都有字符串名和整型 id 值，為了性能，在解析布局文件中每個節點的屬性時，是根據整型 id 值而不是字符串名來唯一標識，并據此拿到該屬性的值即可。

為了驗證我們的猜想，簡單修改字符串池中的一個屬性字符串：layout_width -> llyout_width，驗證可以運行成功。由前面的敘述可知 layout 目錄下文件有近 9K 個，影響范圍很廣，如果可行其收益預計會很大，同時也更需要謹慎。

通過翻看源碼發現，每個屬性(attr)包含一個對應的整型 id 值，在parseXml()解析布局文件得到標簽后，獲取其屬性值時果然會直接根據整型 id 值來獲取。這里屬于比較底層的代碼，因為與性能相關，一般 rom 廠商似乎不會改到這里，其兼容性可能不會受影響。

源碼中解析布局文件，標識屬性并獲取屬性值的代碼如下：

frameworks/base/core/jni/android_util_AssetManager.cpp

// 通過屬性整型id值獲取屬性值
static jboolean android_content_AssetManager_applyStyle(...) {
    ...
    while (ix < NX && curIdent > curXmlAttr) {
        ix++;
        curXmlAttr = xmlParser->getAttributeNameResID(ix); //獲取屬性id值
    }
    if (ix < NX && curIdent == curXmlAttr) { //通過id值來標識屬性
        block = kXmlBlock;
        xmlParser->getAttributeValue(ix, &value); //獲取屬性值
        ...
    }
    ...
}
uint32_t ResXMLParser::getAttributeNameResID(size_t idx) const {
    int32_t id = getAttributeNameID(idx);
    // mTree.mResIds 就是 Resids數組；返回值即屬性id值
    if (id >= 0 && (size_t)id < mTree.mNumResIds) {
        return dtohl(mTree.mResIds[id]);
    }
    return 0;
}

具體實現上，該思路一共有三個要點，總體收益 1.9MB+ ，詳見如下分析。

屬性字符串名稱修改

首先，我們將所有能與 Resids 數組一一對應的字符串全部替換為""字符串，對所有 layout 目錄下的文件進行處理，得到收益 1.1MB+ 。

將此優化進行推廣，對資源目錄 res 下所有以 “.xml” 后綴的文件進行優化，得到附加收益 180K+。這部分收益不大的原因是其他目錄下的“.xml” 后綴文件，多為 drawable 或者 anim 目錄下的文件，這類文件中 Resids數組沒有或者包含的屬性不太多。

偏移數組修改

觀察 layout 目錄下布局文件中字符串池格式，發現包含偏移數組和字符串池，其中，每個節點從字符串池中讀取字符串是根據偏移數組獲取。所以，這里可以只修改偏移數組，將其指向同一個字符串值，從而將空字符串合并為一個，減少字符串池，節省空間，如下圖：

上圖中，左圖，是將與 Resids 數組一一對應的字符串全部替換為""字符串了，其偏移數組會指向 5 個""字符串;右圖，是修改偏移數組，將其值修改為指向第一個""字符串，同時刪除冗余的 4 個""字符串，此方案得到收益 300K+。

命名空間去除

在解析布局文件獲取屬性值的時候，我們發現屬性的命名空間字符串很長，例如："http://schemas.android.com/apk/res/android"。而且每個布局文件都至少存在一個命名空間字符串，其出現相當頻繁。我們猜想，在獲取屬性值時，是否也沒解析屬性的命名空間字符串呢?而在前面我們說過，屬性值的獲取只需要屬性id值來標識，沒用到命名空間字符串。將命名空間字符串替換為空串后，發現的確沒有問題，此優化得到收益500K+。

最終優化形式如下：

• 標記 1--屬性字符串名稱裁剪，將字符串池中每一個字符串替換成""空字符串;
• 標記 2--偏移數組修改，將字符串池中所有""空字符串合并為一個;
• 標記 3--命名空間去除，將字符串池中命名空間字符串替換成""空串。

App Bundle 兼容

以上優化都屬于通用方案，都能在國內 App 上接入使用。然而，目前在海外 Google Play 商店上，App 均采用的是 App Bundle 文件格式(即 AAB)，其中resources.arsc文件和 layout 目錄下布局文件的格式已和上述格式不同，谷歌在其之前二進制文件格式的基礎上，使用了 protobuf 格式，以增強對該文件格式中內容的可擴展性和魯棒性。

在 AAB 文件 split 成多個 APK 的時候，會有 protobuf 格式到二進制 xml 格式的轉換，而這個轉換過程在 Google Play 上，我們無法更改。所以只能針對 AAB 文件格式中的資源文件格式進行優化了，通過 App Bundle 解析布局文件中的屬性并不復雜，這里不再詳述，針對上述優化方案在 AAB 文件上的移植結果如下：

資源路徑縮短：

• 無法實現，因為resources.arsc文件中常量池裁剪無法實現， 即全部替換為同一個字符串"_"會轉換失敗，原因在于執行 protobuf 格式到二進制 xml 格式的轉換中，會判斷當前的鍵字符串是否重復，如果是，那么會直接返回，無法解析通過。

frameworks/base/tools/aapt2/format/proto/ProtoDeserialize.cpp

//讀取protobuf格式的資源文件
static bool DeserializePackageFromPb(...) {
    ...
    for (const pb::ConfigValue& pb_config_value : pb_entry.config_value()) {
        ...
        //FindOrCreateValue搜尋已存在的或者創建新的ResourceConfigValue，搜尋時會判斷鍵字符串是否已存在
        ResourceConfigValue* config_value = entry->FindOrCreateValue(config, pb_config.product());
        if (config_value->value != nullptr) {//發現已存在config_value，返回錯誤
          *out_error = "duplicate configuration in resource table";
          return false;
        }
        ...
    }
    ...
}

layout 優化：

• 屬性字符串名稱裁剪：可以實現，取得收益 400K+;
• 偏移數組修改：無法實現，因為最后轉換 protobuf 格式到二進制 xml 格式，這一步是在 Google Play 本地的 aapt2 命令環境中實現，無法修改;
• 命名空間去除：可以實現，取得收益 200K+

因此，我們的優化方案最終在某海外 App 上總體可以取得 600K+收益。在完成對 AAB 文件的優化后，通過 split 后獲取其中的 base-master.apk，查看其中的 layout 布局文件，收益示意圖如下：

標記 1--屬性字符串名稱裁剪，命名空間去除已優化;

標記 2--偏移數組修改，無法優化，因此還是存在多個""字符串，而不像 APK 里面可以合并為一個。

總結

可見，在資源文件優化方面，還是可以另辟蹊徑，有不少通用優化可以做，總結起來，主要工作還是在對無用字符串的搜尋和確認上。通常，編譯后的二進制文件中，字符串的作用有:

• 代碼執行需要。這類字符串是必須的，但可以考慮是否可以精簡，即混淆;
• 調試輔助功能。這類字符串不一定必須，可以去除，如果需要保留，可以做相應的 keep 功能;
• 文件格式設計者當初為了格式完備性引入，已拓展后續功能。這類字符串可能是與性能相違背的，如未使用可以直接去除;

后兩個點便是搜尋冗余字符串和優化包大小的重點方向。

優化收益落地