# 一、前言

疑問：dex檔案是什麼？dex檔案最佳化又是什麼？

dex檔案最佳化會給專案帶來什麼問題，怎麼解決這些問題？

## 1.1 APK的編譯和打包流程

1、透過aapt打包資原始檔res，對應生成R.java、resources.arsc和res檔案（二進位制&非二進位制保持原來的程式碼）

2、處理aidl檔案，生成java介面檔案（沒有aidl 則忽略）

3、透過java compile編譯R.java、 java介面檔案，生成對應.class檔案（java compiler）

4、運用dex命令，將.class檔案和第三方sdk庫中的.class檔案轉換成classes.dex檔案

5、透過apkbuilder將aapt生成的CompiledResources和其他資原始檔以及classes.dex檔案打包生成apk

6、同樣的，可以使用Jarsigner工具，對上面的apk進行debug或者release簽名

apk的編譯和打包流程圖如下：

![圖片](https://img-blog.csdnimg.cn/img_convert/c2fe4f1b5a060d5ec52f0ef8c2cdcd94.png)

實際專案開發中，5、6兩個步驟，可以藉助jenkins平臺直接生成release包即可滿足需求。

## 1.2 dex檔案的應用場景

再來看看dex檔案常用的場景，比較流行的有：APK 的瘦身、熱修復、外掛化、應用加固、Android 逆向工程、64 K 方法數限制。

拿方法數限制舉例，在上面的第4步，將class檔案轉換成dex檔案，預設只會生成一個dex檔案，單個dex檔案中的方法數不能超過65536，不然編譯會報錯，但是我們在開發App時肯定會整合一堆庫，方法數一般都是超過65536的，解決這個問題的辦法就是：一個dex裝不下，用多個dex來裝，gradle增加一行配置：multiDexEnabled true。

dex檔案的應用場景網上介紹的很多，本文不做介紹。而是對專案中實際遇到的問題進行剖析，從而對dex最佳化有進一步的理解。

# 二、dex到vdex、odex

## 2.1 ART預最佳化

ART（Android runtime）是什麼，它是虛擬機器，運營java程式碼、APP用的。參考Android發展史，Android 5.0把ART作為預設的虛擬機器，而不是Android4.4及之前使用的DVM（Dalvik VM）了。

回顧一下DVM和ART和Android的關係，我們先來了解執行Java的幾種虛擬機器的工作機制：（1）JVM：JVM虛擬機器執行的是java位元組碼。Java檔案到JVM的過程是：**java -> java bytecode(class) -> java bytecode(jar)**

> **DVM**：DVM虛擬機器解析執行的dex位元組碼。Java檔案到DVM的過程是：java -> java bytecode(class) -> dalvik bytecode(dex)

> **ART**：ART虛擬機器執行本地機器碼。Java檔案到ART的過程是：java -> java bytecode(class) -> dalvik bytecode(dex) -> optimized android runtime machine code(oat)

可以看到，DVM到ART的演變，實際上是java檔案到虛擬機器的執行程式碼的過渡，相對而言，ART多了oat的過程，ART使用AOT（Ahead-Of-Time）編譯，在應用第一次安裝的時候，位元組碼預編譯成機器碼存在本地，DVM是使用JIT（Just-In-Time）編譯，在應用每次執行的時候，位元組碼都需要透過編譯器即時轉換為機器碼才能繼續執行。ART相對於DVM，省去了每次解析位元組碼的過程，所以執行時佔用的記憶體會減少，提升應用的執行效率。

## 2.2 ART的執行方式

ART在Android5.0時代，號稱使用AOT即可讓系統執行在512M的機器上。從 Android 7.0（簡稱 N）開始，ART結合 AOT、即時 (JIT) 編譯和配置檔案引導型編譯。

這幾種模式可以組合配置，以谷歌的Pixel 裝置舉例，配置了以下編譯流程：

> 1）最初安裝應用時不進行任何 AOT 編譯。應用前幾次執行時，系統會對其進行解譯，並對經常執行的方法進行 JIT 編譯。

> 2）當裝置閒置和充電時，編譯守護程式會執行，以便根據在應用前幾次執行期間生成的配置檔案對常用程式碼進行 AOT 編譯。

下一次重新啟動應用時將會使用配置檔案引導型程式碼，並避免在執行時對已經編譯過的方法進行 JIT 編譯。在應用後續執行期間進行了 JIT 編譯的方法將會被新增到配置檔案中，然後編譯守護程式將會對這些方法進行 AOT 編譯。

ART 包括一個編譯器（dex2oat 工具）和一個為啟動 Zygote 而載入的執行時 (libart.so)。dex2oat 工具接受一個 APK 檔案，並生成一個或多個編譯檔案，然後執行時將會載入這些檔案。檔案的個數、副檔名和名稱會因版本而異，但在 Android O 版本中，將會生成以下檔案：

> vdex：其中包含 APK 的未壓縮 DEX 程式碼，另外還有一些旨在加快驗證速度的後設資料。

> odex：其中包含 APK 中經過 AOT 編譯的方法程式碼。

> art (optional)：其中包含 APK 中列出的某些字串和類的 ART 內部表示，用於加快應用啟動速度。

## 2.3 vdex、odex的作用

解壓一個APK（以廠商的系統應用包舉例）的包，可以看到下面的結構，不含有任何dex檔案

![圖片](https://img-blog.csdnimg.cn/img_convert/f9d737b6fdab98ea181af5188340d6e5.png)

再看下這個應用在手機中的目錄結構，vdex、odex檔案包含apk的所有程式碼，正常也會包含classes.dex檔案。由於vdex、odex是機器碼，沒辦法直接轉成可以檢視的二級制碼檢視（也可能是我使用的工具不對）。

## 2.4 vdex、odex與classes.dex關係

可能是系統編譯的bug，也可能是生成了ART檔案之後，對odex、vdex檔案做了二次處理，現象是這樣的，嘗試獲取odex中的dex檔案，提示不含有dex檔案。

![圖片](https://img-blog.csdnimg.cn/img_convert/8f299566f829229ba5bd5b4bf309b5d9.png)

為了再次確認odex裡面是否真的含有dex檔案，使用010Editor再次確認，可以看到recent Files下面仍然是沒有dex檔案的。

![圖片](https://img-blog.csdnimg.cn/img_convert/38bf70b33187cccab459a0aa7e4f49ff.png)

嘗試獲取vdex中的dex檔案，也是無法獲取的。

![圖片](https://img-blog.csdnimg.cn/img_convert/4e770a7665009901813d641052bd3e41.png)

所以說，odex(或者vdex)中含有classes.dex的說法是不正確的。

# 三、Arouter是什麼

阿里的一個路由元件，功能很多，我這邊的實際使用場景是進行頁面跳轉。具體功能可以參考阿里峰會上對[arouter的介紹](https://blog.csdn.net/cpcpcp123/article/details/107891817)。

借鑑峰會中提到的一點作為鋪墊，也是我們下面將要講述的一點。“最後想分享的就是ARouter的未來開發計劃。未來ARouter會支援外掛化並且支援生成對映關係文件，因為外掛化是現在很多大型APP中會使用的技術方案，很多的Dex和功能是動態地下發到APP中的，而在這種情況下，是無法找到所有的Dex檔案的，也就是對於沒有載入過的Dex而言，裡面的對映關係是跳轉不過去的，所以一旦Dex檔案位置發生變動，常規的方案是無法找到Dex的，也不能實現對映檔案初始化，這一部分會在後面的版本中進行支援”。

阿里可以識別的arouter路徑如下：

![圖片](https://img-blog.csdnimg.cn/img_convert/11acd826fe864b4bf18e576470c36b6b.png)

換句話說，arouter可能因為dex檔案的位置變化或者路徑變化，而無法找到。

# 四、踩坑

## 4.1 現象

2.4中提到了odex檔案中不含有dex，而arouter查詢路徑遵循分組按需載入的規則，歸結到底，實際上就是對class檔案的查詢，如下圖：

![圖片](https://img-blog.csdnimg.cn/img_convert/603503ca3a0f19a314f36a0a208ddd5c.png)

而class檔案的資訊記錄在dex檔案中，所以出現了異常，使用arouter進行頁面跳轉的時候，出現classNotFound exception。

## 4.2 解決方案

想要找到解決方案，就要知道怎麼樣讓odex對arouter路徑不產生影響，這方面，可能在沒有相關經驗的時候，很難找到解決方案，只能一點點查詢。透過搜尋ART的工作原理，找到文章[《配置ART》](https://source.android.google.cn/devices/tech/dalvik/configure?hl=zh-cn)，其中文章提到：

![圖片](https://img-blog.csdnimg.cn/img_convert/bf0c3d6fb24519094c4b75fbcfd2a332.png)

也就是說透過配置LOCAL\_DEX\_PREOPT的屬性，可以防止odex最佳化，於是找到[Android.mk](https://wallpapers.com/android)中設定該屬性的地方進行設定LOCAL\_DEX\_PREOPT := nostripping。

![圖片](https://img-blog.csdnimg.cn/img_convert/75c912d798336f4978498a4af144e4e3.png)

既在編譯的時候做dex最佳化（生成odex檔案），又不從apk裡剝離dex。於是有了下面的apk生成之後的路徑對比，再看下dex不被剝離的路徑，下面含有了classes.dex檔案。

![圖片](https://img-blog.csdnimg.cn/img_convert/9e8fecd82166453e8ffdb8e622f9b03c.png)

使用jadx開啟這個classes.dex檔案，發現arouter的路徑檔案就在這裡，所以arouter的跳轉正常了，異常不再出現。

![圖片](https://img-blog.csdnimg.cn/img_convert/3f08d86b1a798fddbed6989347dcd875.png)

# 五、總結

odex最佳化這種系統做的事情，往往會出現一些意想不到的結果，如果你負責廠商的應用，經常需要內建專案，這時候要注意了，當你的應用中含有第三方框架的時候，要注意路徑、資源的引用都是沒問題的，雖然正常情況下，odex檔案不會對你的路徑產生干擾，但是也難免odex出現失誤，因為對於odex來說，裡面的資源無需儲存，生成art檔案能夠執行即可。合理使用art的配置，可以幫助解決很多問題。

> 作者：vivo網際網路客戶端團隊-Xu jie

dex最佳化對Arouter查詢路徑的影響

相關文章