安卓4.4art運行模式是什么意思?怎么打安卓4.4art開啟方法?

在安卓4.4中進到開發(fā)者模式里會發(fā)現(xiàn)多了一項“選擇運行環(huán)境”，里面有兩個選項：Dalvik和ART。

Dalvik是之前Android系統(tǒng)使用的Java虛擬機，那么ART是什么呢?

ART是一個AOT編譯器。所謂AOT (Ahead of Time)是指在運行以前就把中間代碼靜態(tài)編譯成本地代碼，而JIT (Just inTime)則是在運行時動態(tài)編譯。

AOT和JIT比各有長處，這里不詳細展開，只簡單列舉幾個最主要的：

AOT的主要編譯過程發(fā)生于開發(fā)用機，因此編譯得慢一點沒關(guān)系，可以充分的做各種耗時的優(yōu)化;JIT在運行時動態(tài)編譯，通常不能做太耗時的優(yōu)化，否則影響啟動和運行速度

更具體一點，以Sun的JVM為例，JIT大體上劃分為client和server兩種模式。Client模式下VM是一邊解釋執(zhí)行，一邊識別熱點 區(qū)域進行JIT編譯，以免明顯影響啟動速度;考慮到內(nèi)存占用，也不會把所有Java字節(jié)碼都編譯成本地代碼。Server模式下則會進行全面的JIT編 譯，因為server啟動慢一點沒關(guān)系，一旦跑起來就會運行很長時間，所以花一點點時間全面優(yōu)化是值得的。

因為受優(yōu)化程度限制，JIT編譯出來的本地代碼體積通常比較大，5到10倍于bytecode都是正常的。AOT編譯出來的本地代碼體積更小。Android的JIT code cache也是內(nèi)存占用的重要角色。

因為是預(yù)編譯好的機器代碼，AOT產(chǎn)生的代碼和加載執(zhí)行過程和普通的本地代碼沒有太大分別。不過仍然需要運行時的GC支持。

雖然AOT可以有更多的時間和空間做編譯優(yōu)化，但并不等于性能上就一定勝過JIT。JVM有不少東西只能在運行時動態(tài)決定是否可以采用編譯優(yōu)化(如 識別可以inline的虛方法)，以及運行時動態(tài)反優(yōu)化(例如inline了一個虛方法，后來發(fā)現(xiàn)遇到新的派生類的實例，就需要取消原來的 inline)。這些事情AOT就不容易做到。

AOT的編譯器一般會分兩個版本，一個在開發(fā)機上編譯整個系統(tǒng)和預(yù)裝應(yīng)用，另一個是一個精簡版，在設(shè)備上運行，負責(zé)編譯連接新安裝的應(yīng)用。

AOT編譯出來的代碼仍然需要運行時的支持，特別是GC。

如果ART確實是用AOT compiler替換JIT，性能先不談，Android的內(nèi)存占用應(yīng)該會因此獲益?，F(xiàn)在dex代碼經(jīng)過 dex => optimized dex => JIT cache這個過程，內(nèi)存中需要同時容納odex和JIT cache兩份代碼;換成ART以后，就變成dex => oat，內(nèi)存里只放oat就可以。不過考慮到ART的解釋器代碼里有提到deoptimization，也有可能在特定情況下還需要load dex代碼解釋執(zhí)行。重要的是oat應(yīng)該是可以直接mmap執(zhí)行的代碼(其實就是一個真·ELF格式的文件)，加載/換頁重加載的速度都會比從odex動 態(tài)編譯來得快。

簡單的說就是以更高的執(zhí)行效率來運行軟件art應(yīng)該利用了LLVM

性能就提升了，另一方面預(yù)載的私有軟件也可以憑此做好保密工作，留在機器上的程序本體是機器碼了，沒有deoat了。

其實Google也在Chrome做了類似的事情。

目前的Chrome支持pNACL，也是一種以(LLVM)字節(jié)碼發(fā)布，到本地再編譯的模式。如此能獲得接近那些直接被編譯為原生代碼的軟件的性能。

Mozilla給出的替代品是asm.js，則是用javascript引擎執(zhí)行C++本機代碼。

總結(jié)：那么，是不是谷歌在做嘗試，今后在Android系統(tǒng)上運行程序不是在Dalvik虛擬機中，而是真正以原生指令方式執(zhí)行?如果真是這樣，哪怕代碼執(zhí)行效率稍低，聯(lián)想起目前Android平臺設(shè)備的配置遠遠強于Iphone的配置，那么是不是Android的運行流暢性趕超Iphone指日可待了?