android與java的關係

摘自：http://bbs.51cto.com/thread-944897-1.html

 

相信學習android的人都會想過或者想知道這個問題，那就請你耐心的看完這篇文章吧，你會對android與java的關係有個深一點的理解。

Android是否至關於Java？請注意，我並無說相等，我說的是至關，就像P = NP裏的那樣。

至關的類/字節碼格式      在不少層面上，Android和Java都有明顯的至關。Android應用程序是用Java(TM)語言寫成的，使用JDK的javac(或等效工具，例如ECJ)來編譯。這個過程產生標準的Java字節碼（.class文件）。這些文件再轉化成Android的.dex文件，從使用的角度來看，它就是一種不一樣格式的Java class文件。不錯，這是一種更優秀的格式；對Sun自從1994年以來的設計有了很大的改進。但就如你能夠把一個GIF格式的圖片轉換成更高級的完美的徹底等效的PNG格式，儘管它們的字節流徹底的不一樣。

      等效的文件格式在細節的實現上很是的不一樣，主要是爲了優化。就比如，若是咱們簡單的知足於低效率的視頻數據流，沒有采用高端的、跨不一樣框架的壓縮技術，那咱們就能夠避免跟MPEGLA視頻解碼專利作鬥爭的麻煩了。
Android特異的classfile設計有好幾種動機；而爲了不和Sun的知識產權保護衝突顯然是一個主要的因素。無論怎樣，Google並無走的離Java足夠遠。兩種文件格式很是的相似。它們在特定的底層數據結構上有區別，但這些結構體在語法上一致的，存儲徹底相同的信息。我相信在JavaSE或JavaME VM裏能夠輕易的在它們的系統classloader裏添加一個.dex分析器來加載」Android classes」。

Android SDK 依賴於.java -> .class -> .dex 轉換的事實狀況既微不足道也毫無損失。「毫無損失」的事實很重要：當GIF = PNG 時，跟受損的JPG文件就不等了 —— 它解碼不出徹底相同的信息。若是JVM和Dalvik都各自獨立，你很難寫出一個相對簡單的工具將一種編譯過的代碼轉換成另外一種 —— 並且不作任何妥協：不丟失信息，不使用冗餘來補償某種特徵在一種VM中是first-class而在另外一種中卻不是的狀況，不須要額外的runtime層 上在一種VM中實現另外一種VM的核心API。

(我知道dx轉換器有多麼的複雜。我看過它的源代碼。那個字節碼轉換器是一個巨大的，全功能的反編譯/重編譯器，通 過SSA構造完成。可是這個轉換器在概念上仍然是無足輕重的；從Java字節碼到Dalvik字節碼的映射在設計上是很平滑的。堆棧相對於寄存器架構中細 節上進行了優化；而重要的東西，例如VM層的類型系統是徹底一致的。)

VM至關      這Dalvik 和 JVM 的至關也是很容易看清楚的。並不僅是源代碼或字節碼格式上的問題：它們的runtime對等物上也同樣。一但一個」Android class」被加載到Dalvik VM裏，它就會像Java class同樣運行，像Java class同樣工做。 若是你懂得Java編程(深刻到高級的，底層的細節)，你也就懂得Android編程。你只須要學一些新的API和框架概念。他們是對等的系統。

      是否記得微軟的.NET? 當.NET剛出世時，Java陣營迅速的反擊指責.NET是對Java的剽竊。我也是其中的一份子，但今天我看問題更清楚了。是的，它過去是個嚴重的剽竊產品；C# 1.0 就是一個… 區分一種語言和另外一種語言最簡單的方法就是看它們的慣用風格 —— 例如toString() 相對於 ToString()。 但在最重要的VM規範裏，微軟作了很大的功課。它的CLR,CLI,和核心框架，都很是的不一樣於Java，因此咱們不能說JVM = CLR這個等式。你不可能使用一個簡單的文件格式轉換工具把你編譯好的Java class轉換成能在.NET runtime上運行的代碼。

要證據嗎？你只需看一看IKVM就知道了。這是一個很是有趣的項目，它可以使Java和.NET跨平臺兼容，因而，你的Java代碼能夠在不作修改的狀況下在CLR（或者是等效的.NET runtime，好比Mono)上運行… 但IKVM並非一個簡單的、類dx的 文件格式轉換器。對Java class的轉化、對Java核心API的適配，都是十分的複雜，即便對一個簡單的HelloWorld程序也是這樣。各個平臺的內部機制，如反射，安 全，並行，異常處理，字節碼驗證，I/O，以及其它核心API，特徵上大體相同，可是在細節上徹底不一樣，一些死衚衕的狀況會迫使IKVM不得不鑽越一個又 一個的火圈來讓Java代碼運行到了.NET VM上。它須要依賴於一個巨大的額外的runtime層，來適配從OpenJDK源代碼裏來的完整JavaSE API。我大體的關注IKVM的開發已經有數年了 —— 我閱讀這精彩的IKVM 博客 – 因此我徹底清楚他們爲了讓Java程序和JavaSE應用適配到.NET上所作的巨大的努力。(這項工做仍然沒有完工；並且不少部分都須要以喪失某些性能爲代價。)

(老的Visual J++ Visual J# 也不是一個簡單的 Java-to-.NET 轉換器。我不想討論它，但咱們徹底能夠說Visual J# 對Java的兼容並不比最先期的IKVM強多少。)

      我把P = NP引進來了討論；有些人把圖靈等效(Turing-equivalence)理論引進來，說任何圖靈完備的平臺/語言/VM都是相互等價的。這也沒錯， 但與本論題無關。圖靈模型這種方式太泛化了；使用這種表面價值來考量會把更個軟件專利系統摧毀(儘管這不是個壞事！)。咱們須要在地上爲JVM等效畫條 線，一條更接近實用需求而遠離圖靈等效的線。按個人觀點，這微不足道的二進制格式轉換，窮盡的高層源代碼和runtime的兼容，使Android明顯的 處於Java等效的這條線內。

APIs 和 Runtime 至關       Android使用了一個至關大的JavaSE APIs子集。這些APIs (來自於Harmony項目)都是全新的實現，但它們是以JavaSE爲模子。若是不是由於TCK許可證問題，Harmony徹底能夠取得JavaSE認 證。但這並無改變這樣的一個事實：Harmony 和 JavaSE APIs是 徹底的等效的 —— 這是特地的，不是偶然的。就像Charles Nutter——有名的JRuby人物——最近寫道:

Android支持一個不完整的（但至關大的）Java 1.5 類庫子集。這個子集大到一個複雜的JRuby項目幾乎不經任何修改就能在Android上運行，不多有限制狀況。

    

看起來Dalvik對JVM是如此的接近，它不得不徹底兼容大部分的JVM規範，包括徹底詳細的JMM (就像Android支持Java風格的線程和併發，已經深刻到了高級的java.util.concurrent包裏了)。可爲何有如此多的」Dalvik是個新VM「或」Dalvik不能運行Java類「的說法呢(90%的討論這場訴訟的論壇和博客都持這種觀點)。

最後的思考     這篇博客並非關於Oracle和Google訴訟官司的法律依據的。我將會忽略（我會刪除掉）那些跑題的評論（跟Android = Java不相關的話）。我只是討厭那些」Android跟Java徹底不要緊「的胡說八道;Google和 Android的擁護者必需要找一個更有意義的論據。

(我將拭目以待這場官司的進展，帶着我全部的預見，直到全部細節和最終結果都出來。除非你有內部消息（我沒有），不要太天真。 保持冷靜。 咱們並不知道Oracle的 —— 或 Google的 —— 真正的所有動機和計劃。咱們並不知道這熒幕背後的故事，自從2007年Google首次宣告Android的誕生(這致使了JavaME生態環境的崩 潰), Sun就痛恨不已，但最後仍是不得不夾着尾巴行事。我不相信任何一個有10億美金的股東控股公司會有利他主義的動機：Google不會，Oracle不 會，即便我喜好的老的Sun公司也不會。咱們等着看吧。)

我不相信Google沒有能力創造出一種既不背離Java太遠，又以Java風格爲基礎的平臺（就像.NET作的那樣）。 Dalvik，以及Android框架，它們多是在權衡了與大量的現有的Java程序，類庫，Java天才，和Java工具鏈高度兼容的願望的最後結 果。微軟在一咬牙一跺腳後放棄了現成移植Java帶來的好處，創造了全新的.NET。Google沒有這樣作。

這個Android = Java等式顯然並非包括全部的東西（不是一一對應的）。每種平臺都有本身一些獨特的API，固然，Android是一個完整的操做系統，包括一個 Linux-based的內核，圖形系統和電信堆棧，等等。很顯然，我只是談論其中最經常使用的部分：Java爲中心的用戶使用區/依賴於Java源代碼、 Java classes（切無論什麼格式）、Java APIs（包括成千上萬的經常使用JavaSE APIs)和出色的類Java的虛擬機的應用框架。對於Android和其它的Java平臺之間的關係有個準確的說法，就是使用版本的概念。我曾記得有個 博客說過這樣的話」Android裏沒有’J’「。那麼，我如今說也不晚：我建議把Android更名爲Java GE（Java Google Edition）。這樣一來就不再會致使混淆了