在
華為P30系列的國內發佈會上，全部人的眼光都被P30系列吸住了，
不過黑馬沒有。
發佈會上，
黑馬看到的重點是“方舟編譯器”！
雖然發佈會上對於這個“方舟編譯器”輕描淡寫，
但直覺告訴黑馬這個編譯器可能才是重中之重！
果然，發佈會結束後，
關於“方舟編譯器”的討論就空前絕後，
黑馬也不免俗，
今天也想說說這個“方舟編譯器”到底是怎麼回事？
對於華為來說，有什麼重要意義？
想知道“方舟編譯器”，
就得知道什麼是編譯。
簡單來說就是，
將一種語言翻譯成另一種語言的程序，
再具體一點，
就是將源代碼翻譯成目標代碼的過程。
這個源代碼一般是高級語言，
常見的有C、C++、Java；
目標代碼一般為機器語言。
為什麼要有這麼一個過程？
通常而言，
源代碼是不能被計算機直接識別運行的，
但是機器語言就能被識別到。
好比人與人之間的交流也必須說人話，
與機“交流”也要說“機話”。
那麼安卓系統是怎麼回事呢？
安卓系統是採用JAVA語言進行編寫的，
同樣CPU也是無法識別JAVA語言的，
也是要通過翻譯才能夠被識別。
安卓這一路走來也是很不容易，
也是經過了多種形態的翻譯過程。
早先的安卓編譯，
沒有將源代碼編譯成機器碼，
而是編譯成中間碼，稱之為字節碼。
怎麼辦呢？
計算機是隻能處理機器語言的，
解決方法就是由運行環境中的虛擬機，
將字節碼直接編譯成機器碼。
這也是安卓在4.4之前，
所採用的虛擬機Dalvik的原因。
而為了配合Dalvik虛擬機，
谷歌引入了JIT實時編譯技術，
簡單來說，
這個技術可以加快Dalvik運行速度，
提高編譯效率。
但是有個問題，
JIT實時編譯技術在程序重新運行的時候，
都要重做翻譯這個事，
也就是說每次打開APP，
都要實時JIT編譯，效率很低。
這也是發佈會上，
餘承東吐槽安卓程序，
“邊解釋邊執行”低效的原因。
後來，為了改進這個弊端，
谷歌將安卓虛擬機直接替換成了ART虛擬機，
這個虛擬機的主要特徵是AOT（全部編譯）。
它的優勢在於，在應用安裝時，
字節碼就會預先在手機上編譯成機器碼，
而不是像Dalivk虛擬機那樣，
在運行時再實時編譯。
安裝的時候就已經編譯，
後續運行的時候就不需要再編譯，
因此APP的運行速度會加快。
但是也有缺陷的，
在應用安裝的時候，
就把字節碼編譯成機器碼，
會消耗更多的存儲空間，
且安裝時間會變長。
注意，在這個ARI環境下的安卓程序，
並不是“邊解釋變執行”了。
不過，在安卓7.0時代，
谷歌又主動選擇了JIT+AOT的編譯方式。
這裡黑馬簡單說一下，
一般情況下，
JIT——實時編譯，是動態編譯；
AOT——全部編譯，是靜態編譯。
動態編譯在編譯後得到的信息多，
但實時編譯效率低；
靜態翻譯在編譯後得到的信息少；
但程序運行速度快。
所以為了綜合二者的優點，
谷歌選擇了混合編譯的方式。
在安裝前還是像之前JIT一樣編譯，
解決安裝速度慢的問題。
同時還生成一個ART索引文件，
預加載與緩存提升應用性能，
進一步加快應用的啟動速度與運行性能。
那華為的“方舟編譯器”是怎麼做的？
根據華為的說法，
“方舟編譯器”是架構級優化，
全程執行機器碼高效運行程序。
而不是像谷歌那樣，
將JAVA代碼編譯成中間字節碼。
就算ART環境下，
編譯器編譯的也是字節碼，
再編成機器碼。
跟網傳的華為只是把ART，
新瓶裝舊酒還是不同的。
具體原理黑馬沒有查到，
但從華為發佈的方舟編譯器的執行效率來看，
實現了將JAVA代碼直接編譯成機器碼，
是否真的那麼牛逼，
需要等到開源軟件放出才能知道。
發佈會上有槽點，
比如說安卓“邊解釋變執行”低效的原因，
前面黑馬也已經說過了。
在安卓4.4之前的確是如此，
但之後更換了虛擬機後，
這種編譯方式就已經改變了。
即使來到安卓7.0時代，
谷歌採用混合編譯的方式，
也並不像之前安卓4.4時代那樣，
單純的JIT實時編譯。
對於這，官方為了對比，
可以理解。
雖說如此，
但如果方舟編譯器，
真的實現全程JAVA代碼直接編譯成機器碼，
那麼真的很牛逼！
黑馬認為說不定這是逆天的存在，
說不定可以真的可以媲美iOS。
而且，如果真的具備這種能力，
那麼對於華為日後自建系統來說，
將是大有益處。
將會直接跳過生態系統的建設週期，
任何軟件僅需要通過方舟編譯器進行編譯，
就能夠直接等同硬件通信。
軟件開發和移植的難度將大大降低，
對於系統生態建設來說，堪比開掛！
特別是對比Windows Phone系統差勁的生態後。
唯一的問題可能是開發者會使用嗎?
閱讀更多 黑馬公社 的文章
