摘要：借華爲方舟編譯器掀起的討論的熱潮，我來說下和 Android ART JVM 和編譯有關的小知識。第六章的最後，我特意解釋了，即使 java字節碼編譯成機器碼，其運行也是離不開虛擬機的管控 ，這些機器碼叫 managed code。

借華爲方舟編譯器掀起的討論的熱潮，我來說下和 Android ART JVM 和編譯有關的小知識。或許你看懂下面這些小知識，就能從另外一個方面明白方舟編譯器爲什麼那麼讓人好奇了。

本文首發我的公衆號：

神農和朋友們的雜文集公衆號。主要想記錄自己、朋友、朋友的朋友們的一些關於coding、programing、程序人生方面的思考。有一些技術，有一些調侃，有一些反思，有一些自勉。

我從16年開始，花了近3年的時間對ART虛擬機做了一個稍微全面的源碼分析（成果見我的新書《深入理解Android：Java虛擬機ART》京東銷售地址 https://item.jd.com/12510921.html ）。其中第六章就是專門講從dex字節碼如何編譯成機器碼。

第六章的最後，我特意解釋了，即使 java字節碼編譯成機器碼，其運行也是離不開虛擬機的管控 ，這些機器碼叫 managed code 。它們和非虛擬機管控運行的程序區別見下面幾個圖：

虛擬機管控運行的機器碼

虛擬機爲什麼要管控機器碼的運行 呢？接着看下圖

以上就是managed code和虛擬機的關係。

所以，方舟編譯器說不用虛擬機了，具體是什麼含義？另外，android app是從zygote fork出來的，zygote自己可是一個JVM，那APP是什麼？

除此之外，根據java語言的特性， 某些數組越界的處理邏輯還要從機器碼運行態退化爲解釋模式執行 （HDeoptimize處理）。來看圖：

下面是 一個觸發HDeoptimize的 程序示例：

從HDeoptimize可以看出，JVM是爲Java語言本身關係及其緊密。

所以，方舟編譯器對這種情況是怎麼處理的？如果要符合Java的要求，那就不會完全是機器碼執行了？或者說有更高級的辦法？

等等等，還有很多謎團需有更進一步的解釋。

簡單來說，源碼寫成什麼樣的邏輯，無論是解釋執行還是機器碼執行都得按這個邏輯來執行。按華爲方舟編譯器介紹的那樣，這是一個類似翻譯的工作。再牛、再快的編譯器， 如果翻譯錯了，就毫無價值 。

JVM、編譯技術 屬於基礎關鍵技術，但感覺絕大部分開發並不真正瞭解它們。這種現象的原因有很多，可能比較關鍵的一個問題是沒有合適的書籍。編譯領域中的 龍書，虎書 很難。而能從JVM源碼角度來介紹JVM的更是絕少有。

我們都希望基業長青。顯然，基業長青離不開對基礎技術的堅守.但是一方面我們也要降低入門門檻，讓更多人有機會看到它，親身接觸到它，然後纔是擴展和完善它。

對方舟編譯器的看法：

1 很高興華爲能在編譯技術這麼底層基礎技術上能讓國人揚眉吐氣。希望華爲能把這個方舟編譯器搞好，搞強大。

2 具體實施過程中，希望能服務好開發者。把真正牛的技術以更友好，更方便的形式提供給開發者慢慢把生態建立起來。

3 希望華爲儘快能在技術上全面剖析和解釋一下方舟。

4 評價一個編譯器的好壞應該是有一套基準測試的 ，華爲不妨亮出測試數據。