本文作者：馮瑞；廖斌斌；劉豐愷
前言
應(yīng)用安裝包的體積會顯著影響應(yīng)用的下載速度和安裝速度，按照 Google 的經(jīng)驗數(shù)據(jù)，包體積每增加 1M 會造成 0.17%的新增折損。抖音的一些實驗也證明了包體積會顯著影響下載激活的轉(zhuǎn)化率。
Android 的安裝包是 APK 格式的，在抖音的安裝包中 DEX 的體積占比達(dá)到了 40%以上，所以針對 DEX 的體積優(yōu)化是一種行之有效的包體積優(yōu)化手段。
DEX 本質(zhì)上是由 Java/Kotlin 代碼編譯而成的字節(jié)碼，因此，針對字節(jié)碼進(jìn)行業(yè)務(wù)無感的通用優(yōu)化成為我們的一個探索方向。
優(yōu)化結(jié)果
終端基礎(chǔ)技術(shù)團(tuán)隊和抖音基礎(chǔ)技術(shù)團(tuán)隊在過去的一年里，利用 ReDex 在抖音包體積優(yōu)化方面取得了一些明顯的收益，這些優(yōu)化也被同步到了其他各大 App 上。
在抖音、頭條和其他應(yīng)用上，我們的優(yōu)化對 APK 體積的縮減普遍達(dá)到了 4%以上，對 DEX 體積的縮減則可以達(dá)到 8% ~ 10%
優(yōu)化思路
在 android 應(yīng)用的構(gòu)建過程中，Java/Kotlin 代碼會先被編譯成 Class 字節(jié)碼，在這個階段 gradle 提供了 Transformer 可以進(jìn)行字節(jié)碼的自定義處理，很多插件都是在這個階段處理字節(jié)碼的。然后，Class 文件經(jīng)過 dexBuilder/mergeDex 等任務(wù)的處理會生成 DEX 文件，并最終被打進(jìn)安裝包中。整個過程如下所示：
所以，針對字節(jié)碼的優(yōu)化是有 2 個時機可以進(jìn)行的:
顯然，對 DEX 進(jìn)行優(yōu)化是更理想的一種方式，因為在 DEX 文件中，除了字節(jié)碼指令外，還存在跨 DEX 引用、字符串池這樣的結(jié)構(gòu)，針對這些 DEX 格式的優(yōu)化是無法在 transformer 階段進(jìn)行的。
在確定了針對 DEX 文件進(jìn)行優(yōu)化的思路后，我們選擇了 facebook 的開源框架 ReDex 作為優(yōu)化工具，并對其進(jìn)行了定制開發(fā)。
選擇 ReDex 的原因是它提供了豐富的基礎(chǔ)能力，ReDex 的基礎(chǔ)能力包括：
我們基于這些能力進(jìn)行了定制和擴(kuò)展，并期望最終建立完善的優(yōu)化體系。
優(yōu)化項
在抖音落地的優(yōu)化項，包括 facebook 開源的優(yōu)化和我們自研的優(yōu)化，從其出發(fā)點來看，可以大致分為下面幾種:
- 通用字節(jié)碼優(yōu)化：通常意義下的編譯優(yōu)化，如常量傳播、內(nèi)聯(lián)等，一般也可在 Transformer 階段實現(xiàn)
- DEX 格式優(yōu)化：DEX 中除了字節(jié)碼指令外，還包括字符串池、類/方法引用、debug 信息等等，針對這些方面的優(yōu)化歸類為 DEX 格式優(yōu)化
- 針對編程語言的優(yōu)化：Java/Kotlin 的一些語法糖會生成大量字節(jié)碼，可以對這些字節(jié)碼進(jìn)行針對性的分析和優(yōu)化
- 提升壓縮率的優(yōu)化：將 DEX 打包成 APK 實質(zhì)上是個壓縮的過程，對 DEX 內(nèi)容進(jìn)行針對性的優(yōu)化可以提升壓縮率，從而產(chǎn)生體積更小的 APK
這幾種優(yōu)化沒有明確的標(biāo)準(zhǔn)和界線，有時一個 Pass 會涉及到多種，下面詳細(xì)介紹一下各項優(yōu)化。
通用字節(jié)碼優(yōu)化
ConstantPropagationPass
該 Pass 實際上包含了常量折疊和常量傳播。
常量折疊是在編譯期簡化常量的過程，比如
1 y = 7 – 14 / 22 —>3 y = 0
常量傳播是在編譯期替代指令中已知常量的過程，比如
1 int x = 14;2 int y = 7 – x / 2;3 return y * (28 / x + 2);4 —>5 int x = 14;6 int y = 7 – 14 / 2;7 return (7 – 14 / 2) * (28 / 14 + 2);
上面的例子經(jīng)過 常量折疊 + 常量傳播優(yōu)化后就會簡化為
1 int x = 14;2 int y = 0;3 return 0;
再經(jīng)過死代碼刪除就可以最終變?yōu)閞eturn 0。
具體的優(yōu)化過程是：
- 如果值肯定是非空的，可以將對應(yīng)的判空去掉，比如 kotlin 生成的 null check 調(diào)用
- 如果值肯定為空，可以將指令替換為拋空異常
- 如果值肯定讓某 if 分支走不到，可以刪除對應(yīng)的分支
- 如果值是固定的，可以用 const 指令替換對應(yīng)的賦值或計算指令
一個方法經(jīng)過 ConstantPropagationPass 優(yōu)化后，可能會產(chǎn)生一些死代碼，比如例子中的int y = 0，這也為后續(xù)的死代碼刪除創(chuàng)造了條件。
AnnoKillPass
該 Pass 是用來移除無用注解的。注解主要分為三種類型:
- SOURCE：java 源碼編譯為 class 字節(jié)碼就不可見，此類注解一般不用過于關(guān)注
- CLASS：字節(jié)碼通過 dx 工具轉(zhuǎn)成 DEX 就不可見，代碼運行時不需要獲取信息，所以一般來說也不需要關(guān)注，實測發(fā)現(xiàn)部分注解仍然存在于 DEX 中，這部分注解可以進(jìn)行優(yōu)化
- RUNTIME：DEX 中仍然可見，代碼運行中可以通過 getAnnotations 等接口獲取注解信息，但是隨著業(yè)務(wù)的迭代，可能獲取注解信息的代碼已經(jīng)去掉，注解卻沒有下掉，這部分注解會被 ReDex 安全的移除
除此之外，實際上為了支持某些系統(tǒng)特性，編譯器會自動生成系統(tǒng)注解，雖然注解本身是 RUNTIME 類型，但是可見性是VISIBILITY_SYSTEM
- AnnotationDefault : 默認(rèn)注解，不能刪除
- EnclosingClass : 當(dāng)前內(nèi)部類申明時所在的類
- EnclosingMethod : 當(dāng)前內(nèi)部類申明時所在的方法
- InnerClass : 當(dāng)前內(nèi)部類名稱
- MemberClasses : 當(dāng)前類的所有內(nèi)部類列表
- MethodParameters : 方法參數(shù)
- Signature : 泛型相關(guān)
- Throws : 異常相關(guān)
舉例說明
編譯器生成 1MainApplication$1這個匿名內(nèi)部類，帶有 EnclosingMethod 和 InnerClass 注解
系統(tǒng)提供以下接口獲取類相關(guān)的信息，就是通過分析相關(guān)的系統(tǒng)注解來實現(xiàn)的
- Class.getEnclosingMethod
- Class.getSimpleName
- Class.isAnonymousClass
- ….
如果代碼中不存在使用這些接口獲取類信息的邏輯，就可以安全的移除這部分注解，從而達(dá)到縮減包大小的目的。
RenameClassesPass
該 Pass 通過縮減類名的字符串長度來減小包體積
比如把類名從La/b/c/d/e;改為LX/a;，可以類名字符串的長度，從而達(dá)到包大小縮減的目的。實際上 Proguard 本身已經(jīng)提供類似的功能: -repackageclasses ‘X’，效果如下:
但是-repackageclasses ‘X’的處理會影響 ReDex 的 InterDexPass 的算法邏輯(InterDexPass 可以參考下文)，導(dǎo)致收益縮減
- 收益測試
- Proguard -repackageclasses ‘X’ 收益: 600K+
- Redex InterDexPass 收益: 400K+
- 同時應(yīng)用 Proguard -repackageclasses ‘X’ 和 Redex InterDexPass 收益: 40K+
本質(zhì)原因在于 Proguard 重命名后，影響了 InterDexPass 函數(shù)引用權(quán)重分配，導(dǎo)致 InterDex 收益被回收
- 解決方案
- InterDexPass 深入分析原理，優(yōu)化權(quán)重算法
- 先執(zhí)行 InterDexPass，后執(zhí)行類似 Proguard 的-repackageclasses ‘X’
權(quán)重算法優(yōu)化相對來說比較復(fù)雜，同時存在眾多不可確定性，比如潛在的跟其他優(yōu)化的沖突，所以我們采取了第二種解決方案。
這里需要解決的一個關(guān)鍵點在于如何確定一個類名是否可以被安全的重命名，我們采取了一個比較取巧的方式，ReDex 會分析 Proguard 傳遞上來 mapping.txt 文件，只要我們保持跟 Proguard 類重命名優(yōu)化一樣的處理策略，就不會引發(fā)反射/native 調(diào)用/序列化等一系列問題。
但是執(zhí)行起來還是碰到各種千奇百怪的問題，比如 Signature 系統(tǒng)注解失效問題。Signature 注解的內(nèi)容是非標(biāo)準(zhǔn)的類名格式，所以類重命名后簡單回寫字符串或者更新 Type 類型會導(dǎo)致 Signature 注解失效，最后通過深入解析 Signature 格式規(guī)避了這個問題。
StringBuilderOutlinerPass
該 Pass 是針對 StringBuilder 的 CallSites 進(jìn)行分析縮略的優(yōu)化，與死代碼刪除搭配使用可以有不錯的優(yōu)化效果。
為何要優(yōu)化 StringBuilder 呢？在 Java 的代碼開發(fā)過程中，字符串操作幾乎是我們最經(jīng)常做的一件事情，無論是實際處理字符串拼接還是各種不同數(shù)據(jù)類型之間的拼接操作。而這些拼接操作都會被 Java 的 de-sugar 優(yōu)化為 StringBuilder 操作。比如：var log = “A” + 1 + “B” + 1.0f + other_var; 會被優(yōu)化為：
1 StringBuilder builder = new StringBuilder();2 builder.append(“A”); builder.append(1);3 builder.append(“B”); builder.append(1.0f);4 builder.append(other_var);5 builder.toString();
因此我們對 StringBuilder 的所有 Callsites 進(jìn)行分析，在最好情況下多個方法調(diào)用可以被優(yōu)化為一個調(diào)用，這個方法是一個 outline （外聯(lián)）方法，具體的參數(shù)拼接和 toString 被隱藏在函數(shù)內(nèi)部：
1 invoke-static {v1, v2, v3} Outline;.bind:([Ljava/lang/Object)Ljava/lang/String;
優(yōu)化步驟可以被簡單的分為如下幾個步驟：
1 @Keep2 public static String bind(Object… args) {3 StringBuilder builder = new StringBuilder();4 for (int i = 0; i < args.length ; i++) {5 builder.append(args[i]);6 }7 return builder.toString();8 }
DEX 格式優(yōu)化
InterDexPass
該 Pass 是針對跨 DEX 引用的優(yōu)化。
跨 DEX 引用是指當(dāng)一個 DEX 需要“使用”到另一個 DEX 中的類/方法/變量時，需要在本 DEX 中保存一份對應(yīng)的類/方法/變量的 id，如果 2 個 DEX 用到了相同的字符串，那么這個字符串在 2 個 DEX 都需要進(jìn)行定義。所以，改變類/方法/變量和字符串在 DEX 中的分布，可以減小引用的數(shù)量，從而減小 DEX 的體積。從原理中也可以看出，該優(yōu)化對單 DEX 的應(yīng)用是無效的。
從上圖可以看到，進(jìn)行類重排后，DEX0 的類引用和方法引用數(shù)量都減少了，DEX 的體積也會因此減小。
具體的優(yōu)化過程是：
ReBindRefsPass
該 Pass 是針對方法引用的優(yōu)化，其原理同 InterDexPass。
在字節(jié)碼中，invoke-virtual/interface指令需要一個方法引用，在很多情況下，這個引用指向的是子類或者實現(xiàn)類的引用，把這個引用替換成父類和接口的方法引用不會影響運行時邏輯，同時會減少 DEX 中方法引用的數(shù)量。在生成 DEX 的時候，方法引用的 65536 限制通常是最先遇到的瓶頸，該優(yōu)化也可以緩解這種情況。
如上圖所示，優(yōu)化前 caller 方法的 invoke 指令使用的是子類引用，其偽指令如下所示，需要用到 2 個引用
1 new-instance v0, Sub12 invoke-virtual v0, Sub1.a()3 new-instance v1, Sub24 invoke-virtual v1, Sub2.a()
優(yōu)化后，invoke 指令都指向其父類應(yīng)用，2 個引用可以合并為 1 個，減少了 DEX 中的引用數(shù)量
1 new-instance v0, Sub12 invoke-virtual v0, Base.a()3 new-instance v1, Sub24 invoke-virtual v1, Base.a()
針對編程語言的優(yōu)化
KotlinDataClassPass
該 Pass 是對 Kotlin data class 的優(yōu)化，基本思路是對 data class 的生成代碼進(jìn)行精簡。
- 解構(gòu)聲明優(yōu)化
Kotlin 中存在解構(gòu)聲明這種語法，可以更方便的創(chuàng)建多個變量，基本用法如下
1 data class Person(val name: String，val age: Int)2 val (name，age) = person(“John”，20)
kotlinc 會為Person類生成 get 方法和 componentN 方法，如下是偽代碼表示
1 Person { 2 String name; 3 Int age; 4 5 getName(): String { return name; } 6 getAge(): Int { return age; } 7 component1(): String { return name; } 8 component2(): Int { return age; } 9 }10 // 解構(gòu)聲明編譯為11 val name = person.component12 1()13 val age = person.component2()
可以看到，get 和 component 的邏輯是一樣的，所以在編譯期，可以進(jìn)行全局的匹配，用 get 替換掉 component，然后再刪除 component。
- toString 等生成方法優(yōu)化
kotlin compiler 為 data class 生成的 toString 具有相似的代碼結(jié)構(gòu)，因此可以生成一個輔助方法，然后在所有 data class 的 toString 方法中調(diào)用這個輔助方法，即外聯(lián)，從而減少指令數(shù)量。
equals 和 hashCode 也可以進(jìn)行類似優(yōu)化，但是風(fēng)險相對較高，因此單獨為這些優(yōu)化配置了開關(guān)，業(yè)務(wù)方可以視情況開啟。
提升壓縮率的優(yōu)化
RegAllocPass
DEX 及其他文件經(jīng)過壓縮打成 APK，如果能通過改變 DEX 的內(nèi)容來提升壓縮率，那么也會減小最終的包體積。RegAllocPass 就是通過重新分配寄存器來提升壓縮率的。
dx 生成 DEX 時使用的是線性寄存器分配算法，其基本步驟是進(jìn)行存活變量分析，然后計算出每個變量的活躍區(qū)間，再根據(jù)活躍區(qū)間依次為變量分配寄存器，超出活躍區(qū)間的寄存器可以進(jìn)行再分配，其優(yōu)點是運行速度快，但結(jié)果往往不是最優(yōu)的。
比如下面的代碼，dx 分配了 6 個寄存器，v0 ~ v5
1 public static double calculateLuminance(@ColorInt int color) {2 final double[] result = getTempDouble3Array();3 colorToXYZ(color，result);4 return result[1] / 100;5 }
相對的，ReDex 使用了圖著色算法進(jìn)行寄存器分配，基本步驟是進(jìn)行存活變量分析，并構(gòu)建沖突圖，沖突圖的每個節(jié)點是一個變量，如果 2 個變量可以同時存活，就在兩個節(jié)點之間建立邊，最后為沖突圖著色，每個顏色代表一個寄存器，著色完成即寄存器分配完成。著色法相對更慢，結(jié)果一般更優(yōu)。對上面同樣的代碼，著色法使用了 4 個寄存器，v0 ~ v3。
DEX 中的方法使用的寄存器越少，其內(nèi)容重復(fù)率就越高，壓縮率也會更大，從而減小了包體積。
抖音落地
抖音是字節(jié)跳動規(guī)模最大、運行環(huán)境復(fù)雜度最高的應(yīng)用之一。在 ReDex 落地初期，由于對復(fù)雜度估計不足，在獨立灰度和全量灰度期間引起了一些問題，在解決問題的過程中，我們也逐步形成了一套迭代流程以保證優(yōu)化的穩(wěn)定性。下面介紹一下我們遇到過的典型問題及當(dāng)前的迭代流程。
遇到的問題
兼容性問題
一般來說，只要按照字節(jié)碼規(guī)范進(jìn)行優(yōu)化，就不會有兼容性問題，因為 dalvik/art 也是按照規(guī)范去校驗和運行字節(jié)碼的，即使進(jìn)行了錯誤的優(yōu)化，引起的問題也應(yīng)該是共性問題。但很多事都有例外，ReDex 就在某品牌手機的部分 Android 5.x 的機型上遇到了問題。
從 log 和一些 hook 來看，某品牌手機對 5.x 的 art 做了大量的魔改，可以推斷其魔改存在一些問題，導(dǎo)致對正確的字節(jié)碼的校驗和運行也可能出現(xiàn)問題。一個可能的原因是：在 ReDex 進(jìn)行優(yōu)化時，會對一些方法體的指令順序進(jìn)行重排，這種重排是不影響方法的邏輯的，但是可能會改變一部分指令，魔改后的 art 在校驗這樣的方法時可能會報 verify error，引起 crash。
最終通過黑名單配置跳過了這些方法的優(yōu)化規(guī)避了問題，在后續(xù)的優(yōu)化過程中，沒有再遇到類似的問題。
復(fù)雜場景優(yōu)化問題
抖音業(yè)務(wù)復(fù)雜，代碼寫法多樣，給靜態(tài)分析和優(yōu)化增加了一些難度，也更容易遇到問題。下面是 2 個典型問題：
1 object XXXSDKHelper { 2 init { 3 initXXXSDK() 4 } 5 fun fakeInit() { 6 } 7 } 8 9 // 初始化任務(wù)10 public class XXInitTask implements Runnable {11 @Override12 public void run() {13 XXXSDKHelper.INSTANCE.fakeInit();14 }15 }
在初始化代碼中調(diào)用fakeInit，它是一個空方法，調(diào)用它的目的是觸發(fā)XXSDKHelper類加載從而執(zhí)行init語句塊，如果刪除了這個空方法，就會導(dǎo)致初始化未執(zhí)行，在后續(xù)的流程中拋空指針。
對于 Class.forname(…)等簡單的反射用法，靜態(tài)分析是可以分析出來的，但是對一些經(jīng)過字符串拼接或者嵌套之后的反射，靜態(tài)分析很難分析到。因此，對可能會被反射的代碼進(jìn)行優(yōu)化需要非常小心，通常來說，匿名內(nèi)部類是不會通過反射調(diào)用的，基于此前提，我們進(jìn)行了匿名內(nèi)部類的重命名優(yōu)化，但是在灰度后，發(fā)現(xiàn)某些第三方 SDK 會通過復(fù)雜的運行時邏輯對匿名內(nèi)部類進(jìn)行了反射調(diào)用，最終導(dǎo)致了 ClassNotFoundError。
復(fù)雜場景的優(yōu)化問題有些是業(yè)務(wù)代碼不規(guī)范造成的，但更多的是優(yōu)化前提（空方法可以刪除/匿名內(nèi)部類不會被反射）不成立所導(dǎo)致，所以在進(jìn)行優(yōu)化時首先需要對假設(shè)進(jìn)行謹(jǐn)慎的驗證。
迭代流程
為了減少穩(wěn)定性問題，我們總結(jié)了 ReDex Pass 的迭代流程。
在對一項 Pass 有了初步構(gòu)思后，組內(nèi)會進(jìn)行可行性討論，如果理論上可行就進(jìn)入開發(fā)和驗證階段，之后同步進(jìn)行至少 2 輪的獨立灰度驗證和業(yè)務(wù)方 Pass 評審，最后進(jìn)行全量灰度驗證。其中任意一個環(huán)節(jié)發(fā)現(xiàn)問題，都會重新進(jìn)行整個流程。
通過這個流程，我們大大減少了穩(wěn)定性問題遺留到灰度階段的可能，在不斷完善迭代流程的同時我們也在探索通過加強單元測試、自動化測試等方式來提升質(zhì)量。
后續(xù)規(guī)劃
ReDex 仍然在持續(xù)迭代中，未來我們會在以下幾個方向繼續(xù)進(jìn)行深入探索：
- 更加嚴(yán)格的合法性校驗；ReDex 之前已經(jīng)檢測出若干自定義插件和 proguard 的問題，將問題攔截在了編譯期，后續(xù)會繼續(xù)提升該能力
- 建立更加完善的質(zhì)量驗證體系；ReDex 作為編譯期的全局字節(jié)碼優(yōu)化方案，如果保證優(yōu)化后的字節(jié)碼質(zhì)量一直是個痛點，我們會繼續(xù)在單元測試、自動化測試等方向探索質(zhì)量提升的手段
加入我們
字節(jié)跳動終端技術(shù)團(tuán)隊(Client Infrastructure) 是大前端基礎(chǔ)技術(shù)的全球化研發(fā)團(tuán)隊（分別在北京、上海、杭州、深圳、廣州、新加坡和美國山景城設(shè)有研發(fā)團(tuán)隊），負(fù)責(zé)整個字節(jié)跳動的大前端基礎(chǔ)設(shè)施建設(shè)，提升公司全產(chǎn)品線的性能、穩(wěn)定性和工程效率；支持的產(chǎn)品包括但不限于抖音、今日頭條、西瓜視頻、飛書、瓜瓜龍等，在移動端、Web、Desktop 等各終端都有深入研究。
就是現(xiàn)在！客戶端／前端／服務(wù)端／端智能算法／測試開發(fā) 面向全球范圍招聘！一起來用技術(shù)改變世界，感興趣請聯(lián)系 fengrui.0@bytedance.com，郵件主題 簡歷-姓名-求職意向-期望城市-電話。
抖音 Android 基礎(chǔ)技術(shù)團(tuán)隊是一個深度追求極致的團(tuán)隊，我們專注于性能、架構(gòu)、包大小、穩(wěn)定性、基礎(chǔ)庫、編譯構(gòu)建等方向的深耕，保障超大規(guī)模團(tuán)隊的研發(fā)效率和數(shù)億用戶的使用體驗。目前北京、上海、杭州、深圳都有大量人才需要，歡迎有志之士與我們共同建設(shè)億級用戶 APP！
可以進(jìn)入字節(jié)跳動招聘官網(wǎng)查詢「抖音基礎(chǔ)技術(shù) Android」相關(guān)職位，或者聯(lián)系郵件：xiaolin.gan@bytedance.com ，直接發(fā)送簡歷內(nèi)推或者咨詢相關(guān)信息！
