1. 項(xiàng)目概述從JAR到DEX的橋梁搭建在Android開發(fā)的日常里尤其是涉及到插件化、熱修復(fù)或者需要?jiǎng)討B(tài)加載代碼的場景我們經(jīng)常會(huì)遇到一個(gè)核心需求如何將一個(gè)標(biāo)準(zhǔn)的Java歸檔文件JAR轉(zhuǎn)換成Android運(yùn)行時(shí)ART或Dalvik能夠識(shí)別和執(zhí)行的Dalvik可執(zhí)行文件DEX。這聽起來像是編譯鏈后端的一個(gè)黑盒操作但理解并掌握它能讓你在解決依賴沖突、進(jìn)行底層調(diào)試或構(gòu)建自己的模塊化框架時(shí)擁有更強(qiáng)的掌控力。dx和d8這兩個(gè)工具就是完成這項(xiàng)轉(zhuǎn)換工作的核心“編譯器”。簡單來說這個(gè)過程就是將基于Java字節(jié)碼.class文件打包而成的JAR包翻譯成Android系統(tǒng)專屬的指令集格式。早期的Android SDK主要依賴dx工具它伴隨著SDK誕生穩(wěn)定但略顯陳舊。而d8則是Google在Android Studio 3.1之后力推的新一代DEX編譯器它被集成在androidx的構(gòu)建工具鏈中速度更快產(chǎn)生的DEX文件更優(yōu)化并且是未來構(gòu)建系統(tǒng)的默認(rèn)選擇。很多朋友在集成第三方SDK、處理遺留庫或者自己動(dòng)手封裝工具庫時(shí)都會(huì)直接或間接地用到它們。如果你曾對(duì)ClassNotFoundException或NoClassDefFoundError感到頭疼并懷疑是不是DEX轉(zhuǎn)換出了問題那么深入理解這個(gè)過程就是解開謎團(tuán)的關(guān)鍵。2. 核心工具解析dx與d8的演進(jìn)與抉擇2.1 dx工具經(jīng)典的奠基者dxDalvik eXchange是Android SDK中歷史最悠久的DEX編譯工具。它的核心職責(zé)非常明確讀取一組Java類文件.class將它們合并、優(yōu)化并轉(zhuǎn)換成一個(gè)或多個(gè).dex文件。在Android構(gòu)建流程的早期javac將.java源文件編譯成.class文件后就由dx接手后續(xù)的所有工作。它的工作方式相對(duì)直接。你可以在命令行中找到它通常位于SDK的build-tools/{版本號(hào)}/目錄下。一個(gè)最基本的轉(zhuǎn)換命令看起來是這樣的dx --dex --outputclasses.dex input.jar這條命令告訴dx以input.jar作為輸入啟用DEX轉(zhuǎn)換--dex并將輸出結(jié)果保存到classes.dex文件中。dx會(huì)解壓JAR包處理其中的所有.class文件進(jìn)行常量池合并、方法索引優(yōu)化等操作最終生成DEX格式的字節(jié)碼。注意使用dx時(shí)一個(gè)需要特別留意的限制是“64K引用限制”。由于DEX文件格式的設(shè)計(jì)單個(gè)DEX文件中包含的方法、字段、類的引用總數(shù)不能超過65536個(gè)。對(duì)于大型應(yīng)用或引入了龐大第三方庫的項(xiàng)目很容易觸發(fā)這個(gè)限制這時(shí)就需要啟用dx的--multi-dex選項(xiàng)來生成多個(gè)DEX文件。dx的優(yōu)點(diǎn)是極其穩(wěn)定與舊版本構(gòu)建系統(tǒng)的兼容性最好。但其缺點(diǎn)也顯而易見編譯速度相對(duì)較慢并且生成的代碼優(yōu)化程度不如后來的d8。2.2 d8工具高效的繼任者d8的出現(xiàn)是為了解決dx在性能和輸出優(yōu)化上的瓶頸。它被設(shè)計(jì)為更快速、更智能的DEX編譯器。從實(shí)現(xiàn)上看d8是用Java重寫的它直接集成在Android Gradle插件AGP中成為了默認(rèn)的DEX編譯器。你可以在build-tools目錄的相同位置找到它或者通過Gradle任務(wù)間接調(diào)用。一個(gè)典型的d8命令行轉(zhuǎn)換示例如下d8 --release --lib android.jar --output . input.jar這里的--lib參數(shù)至關(guān)重要它指定了Android平臺(tái)的核心庫android.jar因?yàn)镴AR包中的類可能會(huì)引用Android SDK中的類如Activity、Context。d8需要這些引用信息來完成正確的編譯和鏈接。--release標(biāo)志表示啟用所有優(yōu)化。與dx相比d8的核心優(yōu)勢有三點(diǎn)。第一是編譯速度尤其是在增量編譯和大型項(xiàng)目上提升非常明顯。第二是更積極的代碼優(yōu)化例如更智能的代碼收縮、內(nèi)聯(lián)和死代碼消除這有助于減小最終APK的體積。第三是它對(duì)Java 8語言特性如Lambda表達(dá)式提供了原生支持而dx需要借助脫糖desugar這一額外步驟來處理。2.3 工具選型背后的邏輯那么在實(shí)際操作中該如何選擇這個(gè)決策背后有幾個(gè)關(guān)鍵考量。如果你的項(xiàng)目使用的是較舊的Android Gradle插件例如3.0.x或更早或者你需要與一個(gè)極其依賴舊版構(gòu)建流程的遺留系統(tǒng)集成那么堅(jiān)持使用dx可能是最穩(wěn)妥的選擇可以避免兼容性風(fēng)險(xiǎn)。然而對(duì)于絕大多數(shù)現(xiàn)代Android項(xiàng)目尤其是使用Android Studio 3.1及以上版本和AGP 3.1.0的項(xiàng)目強(qiáng)烈建議使用d8。它不僅速度更快還能自動(dòng)帶來APK體積的優(yōu)化。Gradle在構(gòu)建時(shí)已經(jīng)默認(rèn)啟用了d8。你可以在項(xiàng)目的gradle.properties文件中看到或設(shè)置android.enableD8true。即使你需要手動(dòng)調(diào)用命令行工具從未來維護(hù)性和性能收益的角度看投入時(shí)間學(xué)習(xí)并使用d8也是更明智的投資。我個(gè)人在遷移舊構(gòu)建腳本時(shí)的體會(huì)是從dx切換到d8可能會(huì)暴露一些之前被隱藏的依賴問題比如某些類路徑配置不完整。這看似是麻煩實(shí)則是好事它迫使你的構(gòu)建配置變得更加規(guī)范和健壯。3. 實(shí)操流程詳解從命令行到集成構(gòu)建3.1 環(huán)境準(zhǔn)備與工具定位動(dòng)手之前第一件事是確認(rèn)你的開發(fā)環(huán)境中有可用的Android SDK。無論你用的是Android Studio還是其他IDESDK的路徑通常是明確的。找到build-tools目錄是關(guān)鍵因?yàn)閐x和d8都位于其中。例如在macOS或Linux上路徑可能類似于~/Android/Sdk/build-tools/30.0.3/。我建議將你常用版本的build-tools目錄添加到系統(tǒng)的PATH環(huán)境變量中這樣在任意位置都可以直接調(diào)用dx或d8會(huì)方便很多。接下來是準(zhǔn)備輸入JAR包。這個(gè)JAR可以是你自己項(xiàng)目模塊通過jar命令或Gradle的jar任務(wù)打出來的也可以是任何需要集成到Android環(huán)境中的第三方庫。一個(gè)常見的“坑”是確保你的JAR包是可用的、未損壞的。你可以先用jar tf your.jar命令列出其中的內(nèi)容確認(rèn)包含預(yù)期的.class文件而不是只有資源文件。3.2 使用dx進(jìn)行轉(zhuǎn)換的完整步驟假設(shè)我們有一個(gè)名為my-library.jar的庫文件需要將其轉(zhuǎn)換為classes.dex。以下是使用dx的詳細(xì)步驟和解釋。首先打開終端導(dǎo)航到JAR文件所在的目錄。執(zhí)行以下命令dx --dex --verbose --output./output/classes.dex my-library.jar我們來拆解這個(gè)命令--dex這是核心指令告訴dx執(zhí)行DEX轉(zhuǎn)換操作。--verbose啟用詳細(xì)輸出模式。強(qiáng)烈建議在第一次轉(zhuǎn)換或排查問題時(shí)加上這個(gè)參數(shù)。它會(huì)打印出正在處理的類、遇到的警告等信息是極佳的調(diào)試工具。--output./output/classes.dex指定輸出路徑和文件名。這里我創(chuàng)建了一個(gè)output文件夾來存放結(jié)果保持工作區(qū)整潔。my-library.jar輸入的JAR文件。執(zhí)行后如果成功你會(huì)在output目錄下看到classes.dex文件。用file命令檢查一下file output/classes.dex應(yīng)該顯示為Dalvik dex file version 035之類的信息。對(duì)于可能超過64K限制的大型庫你需要生成多DEX文件dx --dex --multi-dex --output./output/ my-library.jar注意這里--output指定的是一個(gè)目錄。dx會(huì)在這個(gè)目錄下生成主DEX文件classes.dex以及后續(xù)的classes2.dex、classes3.dex等。--multi-dex選項(xiàng)會(huì)自動(dòng)處理類分割的邏輯。3.3 使用d8進(jìn)行轉(zhuǎn)換的完整步驟使用d8的流程略有不同因?yàn)樗鼘?duì)Android運(yùn)行時(shí)環(huán)境的依賴更明確。一個(gè)完整的轉(zhuǎn)換命令需要指定Android核心庫。首先你需要找到當(dāng)前編譯目標(biāo)所對(duì)應(yīng)的android.jar。它位于SDK的platforms目錄下例如~/Android/Sdk/platforms/android-30/android.jar。請確保這里的API級(jí)別android-30與你項(xiàng)目compileSdkVersion或目標(biāo)設(shè)備兼容。然后執(zhí)行d8命令d8 --release \ --lib ~/Android/Sdk/platforms/android-30/android.jar \ --classpath ./dependency1.jar:./dependency2.jar \ --output ./output/ \ my-library.jar命令參數(shù)解析--release啟用所有優(yōu)化適用于最終發(fā)布。如果是調(diào)試可以使用--debug優(yōu)化較少便于調(diào)試。--lib這是d8命令中最容易出錯(cuò)的部分。必須提供正確的android.jar路徑否則編譯器無法解析像android.app.Activity這樣的基礎(chǔ)類引用會(huì)報(bào)“找不到類”的錯(cuò)誤。--classpath如果你的my-library.jar依賴了其他的JAR包例如gson.jar必須通過--classpath將這些依賴的路徑傳遞進(jìn)來多個(gè)路徑用:Linux/macOS或;Windows分隔。這模擬了編譯時(shí)的類路徑查找。--output指定輸出目錄。d8默認(rèn)會(huì)在該目錄下生成一個(gè)或多個(gè)DEX文件如果需要多DEX通常命名為classes.dex、classes2.dex等。轉(zhuǎn)換成功后進(jìn)入output目錄你會(huì)看到生成的DEX文件。你可以使用dexdump工具同樣在build-tools目錄下來反匯編DEX文件查看其內(nèi)容dexdump -d output/classes.dex | less。這對(duì)于進(jìn)行底層驗(yàn)證或?qū)W習(xí)DEX結(jié)構(gòu)非常有幫助。3.4 將轉(zhuǎn)換集成到自動(dòng)化構(gòu)建中手動(dòng)執(zhí)行命令只適用于偶爾的測試。在實(shí)際項(xiàng)目中我們更希望這個(gè)過程是自動(dòng)化的。這里給出一個(gè)在Gradle中自定義任務(wù)來集成d8的示例這比調(diào)用dx更符合現(xiàn)代構(gòu)建流程。在你的模塊級(jí)build.gradle.kts或build.gradle文件中添加如下任務(wù)tasks.registerExec(jarToDexWithD8) { group custom description Convert a JAR file to DEX using d8 // 定義輸入輸出 val inputJar file(libs/my-library.jar) val outputDir file($buildDir/generated/dex/) val androidJar files(android.bootClasspath).first { it.name android.jar } inputs.file(inputJar) outputs.dir(outputDir) // 配置執(zhí)行命令 commandLine listOf( // 找到d8命令的路徑這里是一種查找方式 android.sdkDirectory.resolve(build-tools).resolve(android.buildToolsVersion).resolve(d8).absolutePath, --release, --lib, androidJar.absolutePath, --output, outputDir.absolutePath, inputJar.absolutePath ) // 在執(zhí)行前創(chuàng)建輸出目錄 doFirst { outputDir.mkdirs() } }這個(gè)任務(wù)的關(guān)鍵點(diǎn)在于自動(dòng)發(fā)現(xiàn)路徑通過android.bootClasspath動(dòng)態(tài)查找當(dāng)前項(xiàng)目使用的android.jar避免了硬編碼路徑提高了任務(wù)的可移植性。聲明輸入輸出使用inputs.file和outputs.dir讓Gradle能夠進(jìn)行增量構(gòu)建。如果輸入JAR沒有變化任務(wù)會(huì)跳過執(zhí)行提升構(gòu)建速度。集成到構(gòu)建鏈你可以通過dependsOn或finalizedBy將這個(gè)任務(wù)與其他標(biāo)準(zhǔn)Gradle任務(wù)如assemble掛鉤實(shí)現(xiàn)全自動(dòng)轉(zhuǎn)換。然后在終端運(yùn)行./gradlew jarToDexWithD8即可執(zhí)行轉(zhuǎn)換。這種方式將手動(dòng)命令的靈活性與Gradle構(gòu)建的自動(dòng)化、可重復(fù)性完美結(jié)合。4. 深度原理與高級(jí)應(yīng)用場景4.1 DEX文件格式淺析與轉(zhuǎn)換本質(zhì)理解轉(zhuǎn)換工具在做什么需要稍微了解一下DEX文件。Java的.class文件遵循JVM規(guī)范每個(gè)類一個(gè)文件包含獨(dú)立的常量池、方法表等。而Android的DEX文件是一種經(jīng)過高度整合和優(yōu)化的格式。它將所有輸入類文件中的常量池合并成一個(gè)全局的常量池對(duì)所有類、方法、字段的引用進(jìn)行統(tǒng)一索引。這種設(shè)計(jì)帶來了兩個(gè)直接好處一是顯著減少了整體文件體積消除了大量重復(fù)的常量信息二是為Android運(yùn)行時(shí)ART的快速解釋執(zhí)行或AOT編譯優(yōu)化提供了便利的數(shù)據(jù)結(jié)構(gòu)。因此dx或d8的轉(zhuǎn)換過程遠(yuǎn)不止是簡單的“翻譯”。它包含了以下關(guān)鍵步驟解析與索引讀取所有輸入類文件構(gòu)建一個(gè)全局的符號(hào)表。字節(jié)碼轉(zhuǎn)換將JVM字節(jié)碼指令集基于棧的操作轉(zhuǎn)換為Dalvik字節(jié)碼指令集基于寄存器的操作。這是兩者最根本的差異。優(yōu)化進(jìn)行一系列優(yōu)化如冗余代碼消除、方法內(nèi)聯(lián)、常量傳播等。d8在這一階段比dx做得更深入。布局與寫入按照DEX文件格式將優(yōu)化后的類信息、方法代碼、常量池等數(shù)據(jù)段寫入到最終的.dex文件中。4.2 復(fù)雜依賴與類路徑處理實(shí)戰(zhàn)在實(shí)際操作中單純的my-library.jar往往還依賴其他庫。假設(shè)你的庫依賴了Google的Gson那么轉(zhuǎn)換命令必須將gson.jar包含在類路徑中否則d8在遇到import com.google.gson.Gson;這樣的語句時(shí)就會(huì)報(bào)編譯錯(cuò)誤。處理復(fù)雜依賴鏈的命令示例如下d8 --release \ --lib ~/Android/Sdk/platforms/android-30/android.jar \ --classpath ./libs/gson-2.8.9.jar:./libs/other-dependency.jar \ --min-api 21 \ --output ./output/ \ ./libs/my-library.jar這里引入了--min-api參數(shù)它指定了生成DEX文件所支持的最低Android API級(jí)別。這個(gè)參數(shù)會(huì)影響某些字節(jié)碼特性的使用以及編譯器進(jìn)行的優(yōu)化策略。例如針對(duì)API 21編譯器可能會(huì)使用一些在新的ART運(yùn)行時(shí)上更高效的指令模式。如果依賴關(guān)系非常復(fù)雜手動(dòng)管理--classpath會(huì)變得很痛苦。這時(shí)更專業(yè)的做法是利用Gradle或Maven來解析依賴并生成完整的類路徑。例如在Gradle腳本中你可以通過configurations.compileClasspath或configurations.runtimeClasspath來獲取項(xiàng)目依賴的所有JAR文件集合然后將其拼接成字符串傳遞給d8命令。這確保了構(gòu)建環(huán)境與開發(fā)環(huán)境的一致性。4.3 動(dòng)態(tài)加載與插件化中的應(yīng)用將JAR轉(zhuǎn)換為DEX的一個(gè)高級(jí)應(yīng)用場景是動(dòng)態(tài)加載這是很多插件化框架的基礎(chǔ)。核心思路是在應(yīng)用運(yùn)行時(shí)從網(wǎng)絡(luò)或本地存儲(chǔ)下載一個(gè)JAR或已轉(zhuǎn)換好的DEX文件然后通過DexClassLoader將其加載到當(dāng)前應(yīng)用的類加載器中。流程通常是這樣的準(zhǔn)備階段在服務(wù)器端或構(gòu)建服務(wù)器上使用d8將插件代碼一個(gè)JAR轉(zhuǎn)換為DEX文件。下發(fā)與存儲(chǔ)將DEX文件或包含DEX的JAR/APK下發(fā)給客戶端保存在應(yīng)用的私有目錄下。動(dòng)態(tài)加載在客戶端創(chuàng)建DexClassLoader實(shí)例。File dexOutputDir context.getCodeCacheDir(); // 優(yōu)化后的DEX存放目錄 DexClassLoader classLoader new DexClassLoader( dexFilePath.getAbsolutePath(), // DEX文件路徑 dexOutputDir.getAbsolutePath(), // 優(yōu)化后輸出目錄 null, // 庫文件路徑通常為null parentClassLoader // 父類加載器一般是當(dāng)前應(yīng)用的類加載器 );反射調(diào)用通過classLoader.loadClass(“com.plugin.MainClass”)加載插件類然后反射調(diào)用其方法。在這個(gè)過程中使用d8生成優(yōu)化過的、體積更小的DEX文件可以減少網(wǎng)絡(luò)傳輸量和客戶端的存儲(chǔ)占用。同時(shí)確保轉(zhuǎn)換時(shí)使用的--min-api與客戶端設(shè)備的最低API級(jí)別匹配可以避免兼容性問題。4.4 代碼混淆與資源收縮的聯(lián)動(dòng)在正式的發(fā)布構(gòu)建中JAR到DEX的轉(zhuǎn)換往往不是獨(dú)立的一步而是與ProGuard或R8代碼混淆、資源收縮shrink緊密結(jié)合的。R8實(shí)際上是整合了ProGuard的混淆、優(yōu)化功能與d8的DEX編譯功能。當(dāng)你使用Android Gradle插件并啟用minifyminifyEnabled true時(shí)構(gòu)建流程大致如下所有項(xiàng)目代碼和庫依賴AAR/JAR被收集起來。R8首先對(duì)Java字節(jié)碼進(jìn)行整體分析執(zhí)行代碼混淆、優(yōu)化和收縮移除未使用的類、方法、字段。經(jīng)過混淆優(yōu)化后的字節(jié)碼再由集成在R8內(nèi)部的d8編譯器直接編譯成DEX文件。因此如果你手動(dòng)對(duì)一個(gè)已經(jīng)過混淆的JAR例如第三方提供的混淆后SDK執(zhí)行d8轉(zhuǎn)換通常會(huì)很順利。但如果你對(duì)一個(gè)未混淆的、包含大量未使用代碼的JAR進(jìn)行轉(zhuǎn)換得到的DEX文件會(huì)包含所有內(nèi)容體積可能不夠優(yōu)化。在自動(dòng)化構(gòu)建中將轉(zhuǎn)換步驟放在整個(gè)混淆優(yōu)化流程之后是更合理的。5. 常見問題排查與調(diào)試技巧實(shí)錄5.1 “ClassNotFoundException”與“NoClassDefFoundError”深度排查這是轉(zhuǎn)換后動(dòng)態(tài)加載時(shí)最經(jīng)典的錯(cuò)誤。兩者略有區(qū)別ClassNotFoundException發(fā)生在類加載器明確找不到類的定義時(shí)NoClassDefFoundError則發(fā)生在編譯時(shí)存在但運(yùn)行時(shí)找不到例如靜態(tài)初始化失敗或依賴的類缺失。排查步驟確認(rèn)DEX文件是否包含目標(biāo)類使用dexdump工具。dexdump -f output/classes.dex | grep “Class descriptor”可以列出DEX文件中所有的類。仔細(xì)檢查你的目標(biāo)類包括包名是否在其中。檢查類路徑依賴如果目標(biāo)類依賴了其他類而這些類不在同一個(gè)DEX文件中也會(huì)出錯(cuò)。使用dexdump -d output/classes.dex | grep -A 5 -B 5 “你的類名”查看其方法代碼中引用了哪些外部類。確保這些被引用的類也存在于類加載器能加載到的DEX或原始APK中。驗(yàn)證類加載器路徑動(dòng)態(tài)加載時(shí)雙重檢查DexClassLoader構(gòu)造函數(shù)的第一個(gè)參數(shù)DEX文件路徑是否正確文件是否存在且可讀。第二個(gè)參數(shù)優(yōu)化輸出目錄應(yīng)用有寫入權(quán)限通常是context.getCodeCacheDir()。注意MultiDex如果你手動(dòng)生成了多個(gè)DEX文件classes.dex,classes2.dex在動(dòng)態(tài)加載時(shí)需要確保DexClassLoader能加載到所有必需的DEX文件。一種做法是將多個(gè)DEX文件打包成一個(gè)JAR或ZIP然后傳遞該壓縮包路徑。DexClassLoader內(nèi)部會(huì)解壓并處理其中的所有DEX文件。5.2 版本兼容性與API級(jí)別問題問題表現(xiàn)轉(zhuǎn)換過程成功但DEX文件在低版本Android設(shè)備上運(yùn)行時(shí)崩潰報(bào)錯(cuò)信息可能涉及不支持的指令或方法。根因與解決這通常與--min-api參數(shù)有關(guān)。d8編譯器會(huì)針對(duì)指定的API級(jí)別進(jìn)行優(yōu)化可能會(huì)使用一些在新版本ART上才支持的指令。例如某些字符串操作或數(shù)學(xué)函數(shù)的內(nèi)聯(lián)優(yōu)化只在較高API級(jí)別有效。解決方案在轉(zhuǎn)換時(shí)明確指定你的應(yīng)用支持的最低API級(jí)別。例如如果你的minSdkVersion是21則轉(zhuǎn)換命令應(yīng)加上--min-api 21。這能確保生成的DEX文件與目標(biāo)設(shè)備兼容。驗(yàn)證方法使用dexdump查看DEX頭信息dexdump -f output/classes.dex在輸出中查找min_sdk字段確認(rèn)其值是否符合預(yù)期。5.3 處理包含Android資源或特定注解的JAR普通的Java庫JAR只包含.class文件。但有些Android庫特別是以AAR形式提供但你可能只提取了其中的classes.jar可能依賴Android資源R類或使用了Android特有的注解如NonNull。問題直接轉(zhuǎn)換這類JAR可能會(huì)失敗提示找不到android.R或某些注解類。解決策略提供完整的依賴確保在--classpath中包含了對(duì)應(yīng)的Android支持庫或AndroidX注解庫的JAR包。例如可能需要添加androidx.annotation:annotation的JAR。使用Android SDK編譯最可靠的方法是在一個(gè)模擬的Android項(xiàng)目環(huán)境中通過Gradle依賴該庫然后從構(gòu)建輸出如build/intermediates/transforms/中獲取已經(jīng)由AGP和R8正確處理過的DEX文件而不是自己手動(dòng)轉(zhuǎn)換原始的JAR。分離純Java邏輯如果可能嘗試將庫中不依賴Android API的純Java邏輯剝離出來單獨(dú)打包和轉(zhuǎn)換這樣可以避免復(fù)雜的依賴問題。5.4 性能調(diào)優(yōu)與輸出分析對(duì)于大型庫轉(zhuǎn)換速度和輸出DEX的大小是需要關(guān)注的。增量轉(zhuǎn)換d8支持增量編譯。如果你只是修改了JAR中的少量類理論上可以只重新轉(zhuǎn)換變化的部分。但在手動(dòng)命令行場景下實(shí)現(xiàn)真正的增量比較困難。更實(shí)用的做法是將其集成到Gradle中利用Gradle的增量構(gòu)建特性。分析DEX內(nèi)容使用d8的--pg-map輸出ProGuard映射文件或使用Android Studio的APK分析器即使是對(duì)單個(gè)DEX來查看哪些類和方法占用了大量空間。你可能會(huì)發(fā)現(xiàn)一些意外的依賴或未被混淆的代碼從而有機(jī)會(huì)進(jìn)一步優(yōu)化原始JAR。實(shí)驗(yàn)性優(yōu)化d8提供了一些實(shí)驗(yàn)性標(biāo)志來嘗試更激進(jìn)的優(yōu)化例如--experimental-non-null-assertions。在生產(chǎn)構(gòu)建中需謹(jǐn)慎使用但可以用于探索代碼大小的極限優(yōu)化。手動(dòng)將JAR轉(zhuǎn)換為DEX這項(xiàng)技能在現(xiàn)代Android開發(fā)中看似被高度自動(dòng)化的構(gòu)建系統(tǒng)所隱藏但它仍然是理解Android應(yīng)用構(gòu)成、處理高級(jí)場景如插件化、熱修復(fù)、底層調(diào)試的基石。從穩(wěn)定的dx轉(zhuǎn)向更高效的d8不僅僅是工具的升級(jí)更是構(gòu)建思維向現(xiàn)代化、高性能方向的演進(jìn)。掌握其命令行用法、理解背后的原理并學(xué)會(huì)排查常見問題能讓你在遇到構(gòu)建或運(yùn)行時(shí)類加載的“詭異”問題時(shí)不再束手無策而是能夠直指核心高效解決。