相信學(xué)習(xí)android的人都會(huì)想過(guò)或者想知道這個(gè)問(wèn)題，那就請(qǐng)你耐心的看完這篇文章吧，你會(huì)對(duì)android與java的關(guān)系有個(gè)深一點(diǎn)的理解。

Android是否相當(dāng)于Java？請(qǐng)注意，我并沒(méi)有說(shuō)相等，我說(shuō)的是相當(dāng)，就像P = NP里的那樣。

相當(dāng)?shù)念?字節(jié)碼格式

在很多層面上，Android和Java都有明顯的相當(dāng)。Android應(yīng)用程序是用Java(TM)語(yǔ)言寫成的，使用JDK的javac(或等效工具，例如ECJ)來(lái)編譯。這個(gè)過(guò)程產(chǎn)生標(biāo)準(zhǔn)的Java字節(jié)碼（.class文件）。這些文件再轉(zhuǎn)化成Android的.dex文件，從使用的角度來(lái)看，它就是一種不同格式的Java class文件。不錯(cuò)，這是一種更優(yōu)秀的格式；對(duì)Sun自從1994年以來(lái)的設(shè)計(jì)有了很大的改進(jìn)。但就如你可以把一個(gè)GIF格式的圖片轉(zhuǎn)換成更高級(jí)的完美的完全等效的PNG格式，盡管它們的字節(jié)流完全的不同。

等效的文件格式在細(xì)節(jié)的實(shí)現(xiàn)上非常的不同，主要是為了優(yōu)化。就好比，如果我們簡(jiǎn)單的滿足于低效率的視頻數(shù)據(jù)流，沒(méi)有采用高端的、跨不同框架的壓縮技術(shù)，那我們就可以避免跟MPEGLA視頻解碼專利做斗爭(zhēng)的麻煩了。

Android特異的classfile設(shè)計(jì)有好幾種動(dòng)機(jī)；而為了避免和Sun的知識(shí)產(chǎn)權(quán)保護(hù)沖突顯然是一個(gè)主要的因素。不管怎樣，Google并沒(méi)有走的離Java足夠遠(yuǎn)。兩種文件格式非常的類似。它們?cè)谔囟ǖ牡讓訑?shù)據(jù)結(jié)構(gòu)上有區(qū)別，但這些結(jié)構(gòu)體在語(yǔ)法上一致的，存儲(chǔ)完全相同的信息。我相信在JavaSE或JavaME VM里可以輕易的在它們的系統(tǒng)classloader里添加一個(gè).dex分析器來(lái)加載”Android classes”。

Android SDK?依賴于.java -> .class -> .dex 轉(zhuǎn)換的事實(shí)情況既微不足道也毫無(wú)損失?！昂翢o(wú)損失”的事實(shí)很重要：當(dāng)GIF = PNG 時(shí)，跟受損的JPG文件就不等了 —— 它解碼不出完全相同的信息。如果JVM和Dalvik都各自獨(dú)立，你很難寫出一個(gè)相對(duì)簡(jiǎn)單的工具將一種編譯過(guò)的代碼轉(zhuǎn)換成另一種 —— 而且不做任何妥協(xié)：不丟失信息，不使用冗余來(lái)補(bǔ)償某種特征在一種VM中是first-class而在另一種中卻不是的情況，不需要額外的runtime層上在一種VM中實(shí)現(xiàn)另一種VM的核心API。

(我知道dx轉(zhuǎn)換器有多么的復(fù)雜。我看過(guò)它的源代碼。那個(gè)字節(jié)碼轉(zhuǎn)換器是一個(gè)巨大的，全功能的反編譯/重編譯器，通 過(guò)SSA構(gòu)造完成。但是這個(gè)轉(zhuǎn)換器在概念上仍然是無(wú)足輕重的；從Java字節(jié)碼到Dalvik字節(jié)碼的映射在設(shè)計(jì)上是很平滑的。堆棧相對(duì)于寄存器架構(gòu)中細(xì) 節(jié)上進(jìn)行了優(yōu)化；而重要的東西，例如VM層的類型系統(tǒng)是完全一致的。)

VM相當(dāng) 這Dalvik 和 JVM 的相當(dāng)也是很容易看清楚的。并不只是源代碼或字節(jié)碼格式上的問(wèn)題：它們的runtime對(duì)等物上也一樣。一但一個(gè)”Android class”被加載到Dalvik VM里，它就會(huì)像Java class一樣運(yùn)行，像Java class一樣工作。?如果你懂得Java編程(深入到高級(jí)的，底層的細(xì)節(jié))，你也就懂得Android編程。你只需要學(xué)一些新的API和框架概念。他們是對(duì)等的系統(tǒng)。

是否記得微軟的.NET? 當(dāng).NET剛出世時(shí)，Java陣營(yíng)迅速的反擊指責(zé).NET是對(duì)Java的剽竊。我也是其中的一份子，但今天我看問(wèn)題更清楚了。是的，它過(guò)去是個(gè)嚴(yán)重的剽竊產(chǎn)品；C# 1.0 就是一個(gè)… 區(qū)分一種語(yǔ)言和另一種語(yǔ)言最簡(jiǎn)單的方法就是看它們的慣用風(fēng)格 —— 例如toString() 相對(duì)于 ToString()。 但在最重要的VM規(guī)范里，微軟做了很大的功課。它的CLR,CLI,和核心框架，都非常的不同于Java，所以我們不能說(shuō)JVM = CLR這個(gè)等式。你不可能使用一個(gè)簡(jiǎn)單的文件格式轉(zhuǎn)換工具把你編譯好的Java class轉(zhuǎn)換成能在.NET runtime上運(yùn)行的代碼。

要證據(jù)嗎？你只需看一看IKVM就知道了。這是一個(gè)非常有趣的項(xiàng)目，它能夠使Java和.NET跨平臺(tái)兼容，于是，你的Java代碼可以在不做修改的情況下在CLR（或者是等效的.NET runtime，比如Mono)上運(yùn)行… 但I(xiàn)KVM并不是一個(gè)簡(jiǎn)單的、類dx的 文件格式轉(zhuǎn)換器。對(duì)Java class的轉(zhuǎn)化、對(duì)Java核心API的適配，都是十分的復(fù)雜，即使對(duì)一個(gè)簡(jiǎn)單的HelloWorld程序也是這樣。各個(gè)平臺(tái)的內(nèi)部機(jī)制，如反射，安 全，并行，異常處理，字節(jié)碼驗(yàn)證，I/O，以及其它核心API，特征上大致相同，但是在細(xì)節(jié)上完全不同，一些死胡同的情況會(huì)迫使IKVM不得不鉆越一個(gè)又 一個(gè)的火圈來(lái)讓Java代碼運(yùn)行到了.NET VM上。它需要依賴于一個(gè)巨大的額外的runtime層，來(lái)適配從OpenJDK源代碼里來(lái)的完整JavaSE API。我大致的關(guān)注IKVM的開(kāi)發(fā)已經(jīng)有數(shù)年了 —— 我閱讀這精彩的IKVM 博客 – 所以我完全清楚他們?yōu)榱俗孞ava程序和JavaSE應(yīng)用適配到.NET上所做的巨大的努力。(這項(xiàng)工作仍然沒(méi)有完工；而且很多部分都需要以喪失某些性能為代價(jià)。)

(老的Visual J++ Visual J# 也不是一個(gè)簡(jiǎn)單的?http://Java-to-.NET?轉(zhuǎn)換器。我不想討論它，但我們完全可以說(shuō)Visual J# 對(duì)Java的兼容并不比最早期的IKVM強(qiáng)多少。)

我把P = NP引進(jìn)來(lái)了討論；有些人把圖靈等效(Turing-equivalence)理論引進(jìn)來(lái)，說(shuō)任何圖靈完備的平臺(tái)/語(yǔ)言/VM都是相互等價(jià)的。這也沒(méi)錯(cuò)， 但與本論題無(wú)關(guān)。圖靈模型這種方式太泛化了；使用這種表面價(jià)值來(lái)考量會(huì)把更個(gè)軟件專利系統(tǒng)摧毀(盡管這不是個(gè)壞事！)。我們需要在地上為JVM等效畫條 線，一條更接近實(shí)用需求而遠(yuǎn)離圖靈等效的線。按我的觀點(diǎn)，這微不足道的二進(jìn)制格式轉(zhuǎn)換，窮盡的高層源代碼和runtime的兼容，使Android明顯的 處于Java等效的這條線內(nèi)。

APIs 和 Runtime 相當(dāng) Android使用了一個(gè)相當(dāng)大的JavaSE APIs子集。這些APIs (來(lái)自于Harmony項(xiàng)目)都是全新的實(shí)現(xiàn)，但它們是以JavaSE為模子。如果不是因?yàn)門CK許可證問(wèn)題，Harmony完全可以取得JavaSE認(rèn) 證。但這并沒(méi)有改變這樣的一個(gè)事實(shí)：Harmony 和 JavaSE APIs是 完全的等效的 —— 這是特意的，不是偶然的。就像Charles Nutter——有名的JRuby人物——最近寫道:

Android支持一個(gè)不完整的（但相當(dāng)大的）Java 1.5 類庫(kù)子集。這個(gè)子集大到一個(gè)復(fù)雜的JRuby項(xiàng)目幾乎不經(jīng)任何修改就能在Android上運(yùn)行，很少有限制情況。

看起來(lái)Dalvik對(duì)JVM是如此的接近，它不得不完全兼容大部分的JVM規(guī)范，包括完全詳細(xì)的JMM (就像Android支持Java風(fēng)格的線程和并發(fā)，已經(jīng)深入到了高級(jí)的java.util.concurrent包里了)?？蔀槭裁从腥绱硕嗟摹盌alvik是個(gè)新VM“或”Dalvik不能運(yùn)行Java類“的說(shuō)法呢(90%的討論這場(chǎng)訴訟的論壇和博客都持這種觀點(diǎn))。

最后的思考 這篇博客并不是關(guān)于Oracle和Google訴訟官司的法律依據(jù)的。我將會(huì)忽略（我會(huì)刪除掉）那些跑題的評(píng)論（跟Android = Java不相關(guān)的話）。我只是討厭那些”Android跟Java完全沒(méi)關(guān)系“的胡說(shuō)八道;Google和 Android的擁護(hù)者必須要找一個(gè)更有意義的論據(jù)。

(我將拭目以待這場(chǎng)官司的進(jìn)展，帶著我所有的預(yù)見(jiàn)，直到所有細(xì)節(jié)和最終結(jié)果都出來(lái)。除非你有內(nèi)部消息（我沒(méi)有），不要太天真。保持冷靜。 我們并不知道Oracle的 —— 或 Google的 —— 真正的全部動(dòng)機(jī)和計(jì)劃。我們并不知道這熒幕背后的故事，自從2007年Google首次宣告Android的誕生(這導(dǎo)致了JavaME生態(tài)環(huán)境的崩 潰), Sun就痛恨不已，但最后還是不得不夾著尾巴行事。我不相信任何一個(gè)有10億美金的股東控股公司會(huì)有利他主義的動(dòng)機(jī)：Google不會(huì)，Oracle不 會(huì)，即使我喜愛(ài)的老的Sun公司也不會(huì)。我們等著看吧。)

我不相信Google沒(méi)有能力創(chuàng)造出一種既不背離Java太遠(yuǎn)，又以Java風(fēng)格為基礎(chǔ)的平臺(tái)（就像.NET做的那樣）。 Dalvik，以及Android框架，它們可能是在權(quán)衡了與大量的現(xiàn)有的Java程序，類庫(kù)，Java天才，和Java工具鏈高度兼容的愿望的最后結(jié) 果。微軟在一咬牙一跺腳后放棄了現(xiàn)成移植Java帶來(lái)的好處，創(chuàng)造了全新的.NET。Google沒(méi)有這樣做。

這個(gè)Android = Java等式顯然并不是包括所有的東西（不是一一對(duì)應(yīng)的）。每種平臺(tái)都有自己一些獨(dú)特的API，當(dāng)然，Android是一個(gè)完整的操作系統(tǒng)，包括一個(gè) Linux-based的內(nèi)核，圖形系統(tǒng)和電信堆棧，等等。很顯然，我只是談?wù)撈渲凶畛Ｓ玫牟糠郑篔ava為中心的用戶使用區(qū)/依賴于Java源代碼、 Java classes（切不管什么格式）、Java APIs（包括成千上萬(wàn)的常用JavaSE APIs)和出色的類Java的虛擬機(jī)的應(yīng)用框架。對(duì)于Android和其它的Java平臺(tái)之間的關(guān)系有個(gè)準(zhǔn)確的說(shuō)法，就是使用版本的概念。我曾記得有個(gè) 博客說(shuō)過(guò)這樣的話”Android里沒(méi)有’J’“。那么，我現(xiàn)在說(shuō)也不晚：我建議把Android改名為Java GE（Java Google Edition）。這樣一來(lái)就再也不會(huì)導(dǎo)致混淆了。