前言

本章節我們將圍繞《支付寶 App 構建優化解析》另啟新系列，細分拆解客戶端在“代碼管理”、“證書管理”、“版本管理”、“構建打包”等維度的具體實現方案展開討論，帶領大家進一步了解支付寶在 App 構建模塊下的持續優化。

本節將主要記錄通過對支付寶 Android 包大小進行壓縮，來改善運行效率和質量。

背景

包大小的重要性已經不需要多說，包大小直接影響用戶的下載，留存，還有部分廠商預裝強制要求必須小于一定的值。但是隨著業務的迭代開發，應用會越來越大，安裝包會不停的膨脹，所以包大小縮減是一個長期的治理過程。

方案

支付寶也一直在優化包大小的方向上努力，我們引入了很多方案。

• 比如：proguard 代碼混淆，圖片從 png 到 tinypng 到 webp，引入 7zip 壓縮方案等。

本方案是有別于上面這些常規的方案，是通過直接刪 dex 中的無用信息，達到支付寶包大小瞬間減小 2.1M 的目的，并且不影響整個的運行邏輯和性能，甚至還能降低一點運行內存。

方案介紹

引言

在講詳細方案前得稍微說說整個 Java 系的調試邏輯。

JVM 運行時加載的是 .class 文件，Android 為了使包大小更緊湊，并且運行更高效發明了 dalvik 和 art 虛擬機，兩種虛擬機運行的都是 .dex 文件(當然 art 虛擬機還可以同時運行 oat 文件，不在本文章討論范圍)。

所以 dex 文件里面信息的內容和 class 文件包含的信息是完全一致的，不同的是 dex 文件對 class 中的信息做了去重，一個 dex 包含了很多的 class 文件，并且在結構上有比較大的差異，class 是流式的結構，dex 是分區結構，各個區塊間通過 offset 索引。后面就只提 dex 的結構，不再提 class 的結構。dex 的結構可以用下面這張圖表示：

dex 文件的結構其實非常清晰，分幾個大塊，header 區，索引區，data 區，map 區。本優化方案優化刪除的就是 data 區中的 debugItems 區域。

debugItem 干嗎用?

首先得知道 debugItem 里面存了什么?

里面主要包含兩種信息：

• 函數的參數變量和所有的局部變量
• 所有的指令集行號和源文件行號的對應關系

有什么用呢：

• 第一點其實很明顯，既然叫 debugItem，那么肯定就是 debug 的時候用的嘍，我們平時在用 IDE 進行斷點和單步調試的時候都會用到這個區域。
• 第二點作用那就是上報 crash 或者主動獲取調用堆棧的時候用的，因為虛擬機真正執行的時候是執行的指令集，上報堆棧會上報 crash 的對應源文件行號，此時正是通過這個 debugItem 來獲取對應的行號，可以用下面的截圖比較直觀的了解：

上圖是一個比較常見的 crash 信息，紅框中的行號便是通過查找這個 debugItem 來獲取的。

debugItem 有多大?

在支付寶的場景下，debug 包有 4-5M，release 包有 3.5M 左右，占 dex 文件大小的比例在 5.5% 左右，和 google 官方的數據是一致的。如果能把這部分直接去掉，是不是很誘人!

debugItem 能直接去掉嗎?

顯然不能，如果去掉了，那所有上報的 crash 信息就會沒有行號，所有的行號都會變成 -1，會被噴的找不到北。

其實在 proguard 的時候就是有配置可以去掉或保留這個行號信息，-keep SourceFile, LineNumberTable 就是這個作用，為了方便定位問題，基本所有的開發都保留了這個配置。

所以，方案的核心思路就是去掉 debugItem，同時又能讓 crash 上報的時候能拿到正確的行號。至于 IDE 調試，這個比較好解決，我們只要處理 release 包就行了，debug 包不處理。

方案一

核心思路也比較簡單，就是行號查找離線化，讓本來存放在 App 中的行號對應關系提前抽離出來存放在服務端，crash 上報的時候通過提前抽離的行號表進行行號反解，解決 crash 信息上報無行號，無法定位的問題。

思路雖然簡單，實現的時候還是有點復雜，推動上線也比較曲折，方案經過幾次調整，大概的方案可以用下面一張圖來抽象：

如上圖，核心點有四個：

• 修改 proguard，利用 proguard 來刪除 debugItem (去掉 -keep lineNumberTable)，在刪除行號表之前 dump 出一個臨時的 dex。
• 修改 dexdump，把臨時的 dex 中的行號表關系 dump 成一個 dexpcmapping 文件(指令集行號和源文件行號映射關系)，并存至服務端。
• hook app runtime 的 crash handler，把 crash 時的指令集行號上報到反解平臺。
• 反解平臺通過上報指令集行號和提前準備好 dexpcmapping 文件反解出正確的行號。

上面這套方案大概花了兩個多星期，擼出了整個 demo，其它幾個改造點都不是很難，難點還是在指令集行號的上報。

我們知道所有的 crash 最終都是會有一個 throwable 對象，里面保存了整個堆棧信息，經過反復的閱讀源碼和嘗試，發現我要的指令集行號其實也在這個對象里面。可以用下面一幅簡單的圖示意：

在打印 crash 堆棧信息前，每個 throwable 都會調用art虛擬機提供的一個 jni 方法，返回一個內部的對象叫 stackTrace 保存在 Throwable 對象中，這個 stackTrace 對象里面保存的便是整個方法的調用棧，當然也包括指令集行號，后續獲取實際的堆棧信息時會再調用一個 art 的 jni 方法，把這個 stackTrace 方法丟過去，底層通過這個 stackTrace 對象中的指令集行號反解出正式的源文件行號。

好了，其實很簡單，反射獲取下這個 Throwable 中的 stackTrace 對象，拿到指令集行號，然后，上報。

這里要注意的一個點，比較惡心，每個虛擬機的實現都不一樣，首先內部對象的名字，有些叫 stackTrace，有些叫 backstrace，然后這個內部對象的類型也非常有，有些是 int 數組，有些是 long 數組，有些是對象數組，但是都會有這個指令集行號，需要針對不同的虛擬機版本使用不同的方法去解析這個對象，大概要兼容4種虛擬機，4.x, 5.x, 6.x, 7.x，7.x 虛擬機之后的就統一了。

方案二

上面這套方案其實挺完美的，沒有什么兼容性問題，刪除是直接利用 proguard，獲取指令集行號直接在 java 層獲取，不需要各種 hook，如果只需要處理 crash 的上報，方案一足夠了，但是在支付寶有很多場景是遠遠不夠的。

比如：

• 性能，CPU，內存異常時調用棧。
• native crash 時的 Java 調用棧。

上面這些 case 都會涉及到堆棧信息，方案一中通過反射調用 throwable 中的 stackTrace 內部對象根本搞不定，需要換種方法。

最開始的思路是嘗試 hook art 虛擬機，每天翻源碼，看看可以 hook 的點，最后還是放棄了，一個是擔心兼容性問題，另一個是 hook 的點太多，比較慌。

最后換了一種思路，嘗試直接修改 dex 文件，保留一小塊 debugItem，讓系統查找行號的時候指令集行號和源文件行號保持一致，這樣就什么都不用做，任何監控上報的行號都直接變成了指令集行號，只需修改 dex 文件。可以用下面的示意圖表示：

如上圖：本來每一個方法都會有一個 debugInfoItem，每一個 debuginfoItem 里面都有一個指令集行號和源文件行號的映射關系，我做的修改其實非常簡單，就是把多余的 debugInfoItem 全部刪掉了，只留了一個 debugInfoItem，所有的方法都指向同一個 debugInfoItem，并且這個 debugInfoItem 中的指令集行號和源文件行號保持一致，這樣不管用什么方式來查行號，拿到的都是指令集行號。

其中也踩過很多坑，其實光留一個 debugInfoItem 是不夠的，要兼容所有虛擬機的查找方式，需要對 debugInfoItem 進行分區，并且 debugInfoItem 表不能太大，遇到過一個坑就是 androidO 上進行 dex2oat 優化的時候，會頻繁的遍歷這個 debugInfoItem，導致 AOT 編譯比較慢，最后都通過 debugInfoItem 分區解決了。

這個方案比較徹底，不用改 proguard，也不用 hook native。不過如果只需要處理 crash 的行號問題，那還是首推方案一，這個方案改動有點大，前期也是每天研究 dex 的文件結構，摳每一個細節，有比較大的把握時才敢改。

小結

目前該方案已經在支付寶正式上線，前面經過好幾輪的外灰驗證，還是比較穩定的。支付寶整體包大小減少了 2.1M 左右，真實的 dex 大小減少 3.5M 左右。

通過本節內容，我們初步了解了支付寶在 Android 客戶端如何通過包大小壓縮以提升 App 運行效率和質量。關于 Android 端包大小壓縮的設計思路和具體實踐，同樣期待你們的反饋，歡迎一起探討交流。