Android 兼容 Java 8 语法特性的原理分析
本文主要闡述了Lambda表達(dá)式及其底層實(shí)現(xiàn)（invokedynamic指令）的原理、Android第三方插件RetroLambda對(duì)其的支持過程、Android官方最新的dex編譯器D8對(duì)其的編譯支持。通過對(duì)這三個(gè)方面的跟蹤分析，以Java 8的代表性特性——Lambda表達(dá)式為著眼點(diǎn)，將Android如何兼容Java8的過程分享給大家。
Java 8概述
Java 8是Java開發(fā)語言非常重要的一個(gè)版本。Oracle從2014年3月18日發(fā)布Java 8，從該版本起，Java開始支持函數(shù)式編程。特別是吸收了運(yùn)行在JVM上的Scala、Groovy等動(dòng)態(tài)腳本語言的特性之后，Java 8在語言的表達(dá)力、簡(jiǎn)潔性兩個(gè)方面有了很大的提高。
Java 8的主要語言特性改進(jìn)概括起來包括以下幾點(diǎn)：
- Lambda表達(dá) （函數(shù)閉包）
- 函數(shù)式接口 （@FunctionalInterface）
- Stream API （通過流式調(diào)用支持map、filter等高階函數(shù)）
- 方法引用（使用::關(guān)鍵字將函數(shù)轉(zhuǎn)化為對(duì)象）
- 默認(rèn)方法（抽象接口中允許存在default修飾的非抽象方法）
- 類型注解和重復(fù)注解
其中Lambda表達(dá)、函數(shù)式接口、方法引用三個(gè)特性為Java帶來了函數(shù)式編程的風(fēng)格；而Stream實(shí)現(xiàn)了map、filter、reduce等常見的高階函數(shù)，數(shù)據(jù)源囊括了數(shù)組、集合、IO通道等，這些又為Java帶來了流式編程或者說鏈?zhǔn)骄幊痰娘L(fēng)格，以上這些風(fēng)格讓Java變得越來越現(xiàn)代化和易用。
Android和Java關(guān)系
其實(shí)Java在Android的快速發(fā)展過程中扮演著非常重要的角色，無論是作為開發(fā)語言（Java）、開發(fā)Framework（Android-SDK引用了80%的JDK-API），還是開發(fā)工具（Eclipse or Android Studio）。這些都和Java有著千絲萬縷的關(guān)系。不過可能是受到與Oracle的法律訴訟的影響，Google在Android上針對(duì)Java的升級(jí)一直都不是很積極：
- Android 從1.0 一直升級(jí)到4.4，迭代了將近19個(gè)Android版本，才在4.4版本中支持了Java 7。
- 然后從Android 4.4版本開始算起，一直到Android N(7.0)共4個(gè)Android版本，才在Jack/Jill工具鏈勉強(qiáng)支持了Java 8。但由于Jack/Jill工具鏈在構(gòu)建流程中舍棄了原有Java字節(jié)碼的體系，導(dǎo)致大量既有的技術(shù)沉淀無法應(yīng)用，致使許多App工程放棄了接入。
- 最后直到Android P(9.0)版本， Google 才在Android Studio 3.x中通過新增的D8 dex編譯器正式支持了Java 8，但部分API并不能全版本支持。
可謂”歷經(jīng)坎坷“。特別是Rx大行其道的今天，Rx配合Java 8特性Lambda帶來簡(jiǎn)潔、高效的開發(fā)體驗(yàn)，更是讓Android Developer望眼欲穿。
接下來，本文將從技術(shù)原理層面，來分析一下Android是如何支持Java 8的。
Lambda 表達(dá)式
想要更好的理解Android對(duì)Java 8的支持過程，Lambda表達(dá)式這一代表性的”語法糖“是一個(gè)非常不錯(cuò)的切入點(diǎn)。所以，我們首先需要搞清楚Lambda表達(dá)式到底是什么？其底層的實(shí)現(xiàn)原理又是什么？
Lambda表達(dá)式是Java支持函數(shù)式編程的基礎(chǔ)，也可以稱之為閉包。簡(jiǎn)單來說，就是在Java語法層面允許將函數(shù)當(dāng)作方法的參數(shù)，函數(shù)可以當(dāng)做對(duì)象。任一Lambda表達(dá)式都有且只有一個(gè)函數(shù)式接口與之對(duì)應(yīng)，從這個(gè)角度來看，也可以說是該函數(shù)式接口的實(shí)例化。
Lambda表達(dá)式
通用格式：
簡(jiǎn)單范例：
說明：
- Lambda表達(dá)式中 () 對(duì)應(yīng)的是函數(shù)式接口-run方法的參數(shù)列表。
- Lambda表達(dá)式中 System.out.println(“xixi”) / System.out.println(“haha”)，在運(yùn)行時(shí)會(huì)是具體的run方法實(shí)現(xiàn)。
Lambda表達(dá)式原理
針對(duì)實(shí)例中的代碼，我們來看下編譯之后的字節(jié)碼：
javac J8Sample.java -> J8Sample.classjavap -c -p J8Sample.class從字節(jié)碼中我們可以看到：
- 實(shí)例中 Lambda表達(dá)式1變成了字節(jié)碼代碼塊中 Line 11的 0: invokedynamic #2, 0 // InvokeDynamic #0:run:()Ljava/lang/Runnable。
- 實(shí)例中 Lambda表達(dá)式2變成了字節(jié)碼代碼塊中 Line 20的 21: invokedynamic #6, 0 // InvokeDynamic #1:run:()Ljava/lang/Runnable。
可見，Lambda表達(dá)式在虛擬機(jī)層面上，是通過一種名為invokedynamic字節(jié)碼指令來實(shí)現(xiàn)的。那么invokedynamic又是何方神圣呢？
invokedynamic 指令解讀
invokedynamic指令是Java 7中新增的字節(jié)碼調(diào)用指令，作為Java支持動(dòng)態(tài)類型語言的改進(jìn)之一，跟invokevirtual、invokestatic、invokeinterface、invokespecial四大指令一起構(gòu)成了虛擬機(jī)層面各種Java方法的分配調(diào)用指令集。區(qū)別在于：
- 后四種指令，在編譯期間生成的class文件中，通過常量池(Constant Pool)的MethodRef常量已經(jīng)固定了目標(biāo)方法的符號(hào)信息（方法所屬者及其類型，方法名字、參數(shù)順序和類型、返回值）。虛擬機(jī)使用符號(hào)信息能直接解釋出具體的方法，直接調(diào)用。
- 而invokedynamic指令在編譯期間生成的class文件中，對(duì)應(yīng)常量池(Constant Pool)的Invokedynamic_Info常量存儲(chǔ)的符號(hào)信息中并沒有方法所屬者及其類型 ，替代的是BootstapMethod信息。在運(yùn)行時(shí)，通過引導(dǎo)方法BootstrapMethod機(jī)制動(dòng)態(tài)確定方法的所屬者和類型。這一特點(diǎn)也非常契合動(dòng)態(tài)類型語言只有在運(yùn)行期間才能確定類型的特征。
那么，invokedynamic如何通過引導(dǎo)方法找到所屬者及其類型？我們依然結(jié)合前面的J8Sample實(shí)例：
javap -v J8Sample.class結(jié)合J8Sample.class字節(jié)碼，并對(duì)invokedynamic指令調(diào)用過程進(jìn)行跟蹤分析。總結(jié)如下：
依據(jù)上圖invokedynamic調(diào)用步驟，我們一步一步做一個(gè)分析講解。
步驟1 選取J8Sample.java源碼中Lambda表達(dá)式1：
Runnable runnable = () -> System.out.println("xixi"); // lambda表達(dá)式1
步驟2 通過javac J8Sample.java編譯得到J8Sample.class之后，
Lambda表達(dá)式1變成：0: invokedynamic #2, 0 // InvokeDynamic #0:run:()Ljava/lang/Runnable;
對(duì)應(yīng)在J8Sample.class中發(fā)現(xiàn)了新增的私有靜態(tài)方法：
步驟3 針對(duì)表達(dá)式1的字節(jié)碼分析 #2 對(duì)應(yīng)的是class文件中的常量池：
#2 = InvokeDynamic #0:#35 // #0:run:()Ljava/lang/Runnable;
注意，這里InvokeDynamic不是指令，代表的是Constant_InvokeDynamic_Info結(jié)構(gòu)。
步驟4 結(jié)構(gòu)后面緊跟的 #0 標(biāo)識(shí)的是class文件中的BootstrapMethod區(qū)域中引導(dǎo)方法的索引：
步驟5 引導(dǎo)方法中的 java/lang/invoke/LambdaMetafactory.metafactory才是invokedynamic指令的關(guān)鍵：
該方法會(huì)在運(yùn)行時(shí)，在內(nèi)存中動(dòng)態(tài)生成一個(gè)實(shí)現(xiàn)Lambda表達(dá)式對(duì)應(yīng)函數(shù)式接口的實(shí)例類型，并在接口的實(shí)現(xiàn)方法中調(diào)用步驟2中新增的靜態(tài)私有方法。
步驟6 使用java -Djdk.internal.lambda.dumpProxyClasses J8Sample.class運(yùn)行一下，可以內(nèi)存中動(dòng)態(tài)生成的類型輸出到本地：
步驟7 通過javap -p -c J8Sample\$\$Lambda\$1.class反編譯一下，可以看到生成類的實(shí)現(xiàn)：
在run方法中使用了invokestatic指令，直接調(diào)用了J8Sample.lambda$main$0這個(gè)在編譯期間生成的靜態(tài)私有方法。
至此，上面7個(gè)步驟就是Lambda表達(dá)式在Java的底層的實(shí)現(xiàn)原理。Android 針對(duì)這些實(shí)現(xiàn)會(huì)怎么處理呢？
Android不能直接支持
回到Android系統(tǒng)上，Java-Bytecode（JVM字節(jié)碼）是不能直接運(yùn)行在Android系統(tǒng)上的，需要轉(zhuǎn)換成Android-Bytecode（Dalvik/ART 字節(jié)碼）。
如圖：
通過Lambda這節(jié)，我們知道Java底層是通過invokedynamic指令來實(shí)現(xiàn)，由于Dalvik/ART并沒有支持invokedynamic指令或者對(duì)應(yīng)的替代功能。簡(jiǎn)單的來說，就是Android的dex編譯器不支持invokedynamic指令，導(dǎo)致Android不能直接支持Java 8。
Android間接支持
既然不能直接支持，那就只能在Java-Bytecode轉(zhuǎn)換到Android-Bytecode這一過程中想辦法，間接支持。這個(gè)間接支持的過程我們統(tǒng)稱為Desugar（脫糖）過程。
官方流程圖：
當(dāng)前，無論是RetroLambda，還是Google的Jack & Jill 工具，還是最新的D8 dex編譯器：
- 流程方面：都是按照如上圖所示的官方流程進(jìn)行Desugar的。
- 原理方面：卻是參照Lambda在Java底層的實(shí)現(xiàn)，并將這些實(shí)現(xiàn)移至到RetroLambda插件或者Jack、D8編譯器工具中。
下面我們逐個(gè)分析解讀一下。
Android 間接支持之RetroLambda
如圖所示，RetroLambda 的Desugar過程發(fā)生在javac將源碼編譯完成之后，dx工具進(jìn)行dex編譯之前。
RetroLambda Desugar
其實(shí)就是參照invokedynamic指令解讀一節(jié)中的步驟5，根據(jù)java/lang/invoke/LambdaMetafactory.metafactory方法，直接將原本在運(yùn)行時(shí)生成在內(nèi)存中的J8Sample\$\$Lambda\$1.class，在javac編譯結(jié)束之后，dx編譯dex之前，直接生成到本地，并使用生成的J8Sample\$\$Lambda\$1類修改J8Sample.class字節(jié)碼文件，將J8Sample.class中的invokedynamic指令替換成invokestatic指令。
將實(shí)例中的J8Sample.java放到一個(gè)配置了Retrolambda的Android工程中：
AndroidStudio -> Build -> make project 編譯之后：
app:transformClassesWithRetrolambdaForDebug任務(wù)發(fā)生在app:compileDebugJavaWithJavac（對(duì)應(yīng)javac）之后，和app:transformDexArchiveWithDexMergerForDebug（對(duì)應(yīng)dx）之前，同時(shí)在build/intermediates/transforms/retrolambda下面生產(chǎn)如圖所示的class文件。
J8Sample.class和J8Sample$$Lambda$1.class反編譯之后的代碼如下：
通過反編譯代碼，可以看出J8Sample.class中Lambda表達(dá)式已經(jīng)被我們熟悉的1.7or1.6的語句所替代。
注意：右圖中J8Sample.lambda$main$0()方法在左圖中沒有顯示出來，但是J8Sample.class字節(jié)碼確實(shí)是存在的。
Android間接支持之Jack&Jill工具
Jack是基于Eclipse的ecj編譯開發(fā)的， Jill是基于ASM4開發(fā)的。Jack&Jill工具鏈?zhǔn)荊oogle在Android N(7.0)發(fā)布的，用于替換javac&dx的工具鏈，并且在jack過程內(nèi)置了Desugar過程。
但是在Android P(9.0) 的時(shí)候?qū)ack&Jill工具鏈廢棄了，被 javac&D8工具鏈替代了。這里就不做Desugar具體分析了。
D8是Android P(9.0)新增的dex編譯器。并在Android Studio 3.1版本中默認(rèn)使用D8作為dex的默認(rèn)編譯器。
D8 Desugar
如圖所示，Desugar過程放在了D8的內(nèi)部，由Android Studio這個(gè)IDE來實(shí)現(xiàn)這個(gè)轉(zhuǎn)換，原理基本和RetroLambda是一樣。
本質(zhì)上也是參照java/lang/invoke/LambdaMetafactory.metafactory方法直接將原本在運(yùn)行時(shí)生成在內(nèi)存中的J8Sample\$\$Lambda\$1.class，在D8的編譯dex期間，直接生成并寫入到dex文件中。
同樣，將實(shí)例中的J8Sample.java放到支持D8的Android工程中：
同樣，AndroidStudio -> Build -> make project編譯之后：
javac編譯之后的J8Sample.class還是使用invokedynamic指令，即這一步并沒有Desugar：
在app:transformDexArchiveWithDexMergerForDebug（對(duì)應(yīng)dx）任務(wù)之后，再對(duì)應(yīng)build/intermediates/transforms/dexMerger目錄找第0個(gè)classex.dex。
執(zhí)行$ANDROID_HOME/build-tools/28.0.3/dexdump -d classes.dex >> dexInfo.txt拿到dex信息。
還是選取實(shí)例中Lambda表達(dá)式1 ：Runnable runnable = () -> System.out.println("xixi");來進(jìn)行分析。
這個(gè)dexIno.txt文件非常大，有1.4M，我們通過com.J8Smaple2.J8Sample找到我們J8Sample在dex中位置。
新增方法：
J8Sample.main方法：
圖中選中部分，對(duì)應(yīng)就是Lambda表達(dá)式1 desugar之后的內(nèi)容。
翻譯成Java的話就變成了：new Lcom/j8sample2/-$$Lambda$J8Sample$jWmuYH0zEF070TKXrjBFgnnqOKc這個(gè)生成類的一個(gè)對(duì)象。
類Lcom/j8sample2/-$$Lambda$J8Sample$jWmuYH0zEF070TKXrjBFgnnqOKc對(duì)應(yīng)前面的生成的J8Sample$$Lambda$1類型，只不過數(shù)字1變成了Hash值。
實(shí)現(xiàn)Interface Ljava/lang/Runnable。 Lcom/j8sample2/-$$Lambda$J8Sample$jWmuYH0zEF070TKXrjBFgnnqOKc.run方法：
到這里，是不是和前面RetroLambda就一樣了。
總結(jié)
至此，Lambda及其invokedynamic指令、RetroLambda插件、D8編譯器各自的原理分析都已經(jīng)結(jié)束了。
相比較Lambda在Java8自己內(nèi)部的實(shí)現(xiàn)：即運(yùn)行時(shí)，在內(nèi)存中動(dòng)態(tài)生成關(guān)聯(lián)的函數(shù)式接口的實(shí)例類型，通過BSM-引導(dǎo)方法找到該內(nèi)存類（字節(jié)碼層面的反射）。
在Android上的其他三種Desugar方式，原理都是一樣的，區(qū)別在于時(shí)機(jī)不同：
探討
無論是RetroLambda，還是D8，對(duì)Java8的特性也不是全都支持。
Java8新增的許多API（例如：新的DataAPI），就D8編譯器而言，只有在Android P(9.0)版本中能直接運(yùn)行。低于9.0就不行了。如何能夠全版本支持Java 8。D8還有很長(zhǎng)的一段路要走。
如果我們?cè)诘桶姹拘枰褂眯碌腁PI，目前可以采取將這些API打包進(jìn)去的臨時(shí)辦法。
寫到這里，肯定有人要提出，為什么不直接使用Kotlin呢？確實(shí)Kotlin對(duì)Lambda表達(dá)式、函數(shù)引用等特性都做了很好的支持，但是現(xiàn)實(shí)的情況中，Kotlin很難取代Android中的Java。新業(yè)務(wù)、新工程還相對(duì)容易，對(duì)老業(yè)務(wù)來說，尤其是經(jīng)過多年沉淀，工程結(jié)構(gòu)復(fù)雜，遷移改造帶來的收益，往往遠(yuǎn)遠(yuǎn)小于遷移改造帶來的成本和不可控之風(fēng)險(xiǎn)。Kotlin和Java同時(shí)存在的情況，長(zhǎng)期來看是一個(gè)必然的結(jié)果。
至于Java 8的其他特性呢，D8是如何實(shí)現(xiàn)的，也可以按照上面類似的方式去分析，甚至可以結(jié)合Kotlin實(shí)現(xiàn)的方式，一探究竟。
總結(jié)
以上是生活随笔為你收集整理的Android 兼容 Java 8 语法特性的原理分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 4大JVM性能分析工具详解，及内存泄漏分
- 下一篇： 阿里P8架构师谈：Zookeeper的原