ART 將會(huì)取代Dalvik虛擬機(jī)，因?yàn)? 在Dalvik下，應(yīng)用每次運(yùn)行的時(shí)候，字節(jié)碼都需要通過即時(shí)編譯器轉(zhuǎn)換為機(jī)器碼，這會(huì)拖慢應(yīng)用的運(yùn)行效率，而在ART 環(huán)境中，應(yīng)用在第一次安裝的時(shí)候，字節(jié)碼就會(huì)預(yù)先編譯成機(jī)器碼，使其成為真正的本地應(yīng)用。

　　在最新的Google I/O大會(huì)上，Google 發(fā)布了關(guān)于Android上最新的運(yùn)行時(shí)庫(kù)的情況。這就是Android RunTime (ART). ART 將會(huì)取代Dalvik虛擬機(jī)，成為Android平臺(tái)上Java代碼的執(zhí)行工具。雖然自從Android KitKat，就有了一些關(guān)于ART的消息，但是基本都是一些新聞性質(zhì)的，缺乏具體技術(shù)細(xì)節(jié)方面的介紹。本文嘗試綜合目前已有的各種消息，以及最新放出的 Android L 預(yù)覽版本的ROM的情況，對(duì)ART運(yùn)行時(shí)庫(kù)做個(gè)詳細(xì)的分析。

　　和IOS，Windows，Tizen之類的移動(dòng)平臺(tái)直接將軟件編譯成能夠直接運(yùn)行在特定硬件平臺(tái)上的本地代碼不同。Android平臺(tái)上的軟件會(huì)被編譯器首先編譯成通用的;byte-code”，然后再在具體的移動(dòng)設(shè)備上被轉(zhuǎn)換成本地指令執(zhí)行。

　　從Android誕生至今的十幾年時(shí)間里，Dalvik從開始時(shí)非常簡(jiǎn)單的Java Byte-Code執(zhí)行虛擬機(jī)，逐漸增加各種新的特性，滿足應(yīng)用程序?qū)π阅艿男枨?，以及與硬件設(shè)備協(xié)同演進(jìn)。這其中包括在Android 2.2版本中引入的即時(shí)編譯器(JIT-Compiler), 以及隨后的多線程支持，以及其他一些優(yōu)化。

　　不過，在近兩年里，Android整個(gè)生態(tài)系統(tǒng)的進(jìn)步對(duì)Android虛擬機(jī)的需求，目前的Dalvik虛擬機(jī)的開發(fā)已經(jīng)無法滿足了。Dalvik 最初設(shè)計(jì)時(shí)，處理器的性能很弱，移動(dòng)設(shè)備的內(nèi)存空間非常有限，而且都是32位的系統(tǒng)。于是Google開始構(gòu)建一個(gè)新的虛擬機(jī)來更好的面對(duì)未來的發(fā)展趨勢(shì)。這種虛擬機(jī)的性能能夠在目前的多核處理器，甚至未來的8核處理上輕松擴(kuò)展，能夠滿足對(duì)大容量存儲(chǔ)的支持，以及大容量?jī)?nèi)存的支持。 于是乎，ART出現(xiàn)了。

　　1 架構(gòu)介紹

　　首先，ART的首要設(shè)計(jì)需求就是完全兼容能在Dalvik上運(yùn)行的byte-code，即dex(Dalvik executable)。這樣的話，對(duì)于程序員來說，就不需要對(duì)重新編譯已有的程序，直接拿APK就可以在Dalvik和ART虛擬機(jī)上運(yùn)行。ART帶來的最大的變化，就是使用預(yù)編譯技術(shù)(Ahead-of-Time compile)取代Dalvik中的即時(shí)編譯技術(shù)(Just-In-Time compile)。之前，在應(yīng)用程序每次執(zhí)行的時(shí)候，虛擬機(jī)需要將bytecode編譯成本地碼執(zhí)行，而在ART中這種編譯操作只需執(zhí)行一次，隨后對(duì)該應(yīng)用程序的執(zhí)行都可以通過直接執(zhí)行保存下來的本地碼完成。當(dāng)然，這種預(yù)編譯技術(shù)，需要占用額外的存儲(chǔ)空間來存儲(chǔ)本地碼。正是因?yàn)楝F(xiàn)在移動(dòng)設(shè)備的存儲(chǔ)空間越來越大，這種技術(shù)才得以應(yīng)用。

　　這種預(yù)編譯技術(shù)使得很多原來無法執(zhí)行的編譯優(yōu)化技術(shù)在新的Android平臺(tái)上成為可能。因?yàn)榇a只被編譯和優(yōu)化一次，因此值得花費(fèi)更多的時(shí)間在這次編譯上，以便進(jìn)行更多的優(yōu)化。Google表示，現(xiàn)在可以在應(yīng)用程序的整體代碼技術(shù)上進(jìn)行更高層次的優(yōu)化，因?yàn)榫幾g器現(xiàn)在能夠看到應(yīng)用程序的整體代碼，而之前的即時(shí)編譯，編譯器只能看到并優(yōu)化應(yīng)用程序中某個(gè)函數(shù)或者非常小的一部分代碼。采用ART后，代碼中異常檢查帶來的開銷絕大部分可以避免，對(duì)方法和接口的調(diào)用也加快了很多。完成這部分功能的是新添加的;dex2oat”組件，用來替代Dalvik中對(duì)應(yīng)的;dexopt”組件。Dalvik中的 Odex文件(優(yōu)化后的dex)文件，在ART中也用ELF文件代替了。

　　因?yàn)锳RT目前編譯生成ELF可執(zhí)行文件，內(nèi)核就可以直接對(duì)載入內(nèi)存中的代碼進(jìn)行分頁(yè)管理，這也會(huì)帶來更加高效的內(nèi)存管理，以及更少的內(nèi)存占用。說到這里，我非常好奇內(nèi)核中的KSM(Kernel same-page merging)在ART中會(huì)有什么樣的影響，應(yīng)該能帶來不錯(cuò)的效果吧。我們拭目以待。

　　ART對(duì)續(xù)航時(shí)間的影響也是非常顯著的。因?yàn)椴辉傩枰忉寛?zhí)行，JIT也不用在程序運(yùn)行時(shí)工作，這樣會(huì)直接節(jié)省CPU需要執(zhí)行的指令數(shù)，因而耗電降低。

　　因?yàn)轭A(yù)編譯時(shí)引入了更多分析和優(yōu)化，編譯的時(shí)間會(huì)變長(zhǎng)，這是ART可能會(huì)帶來的一個(gè)副作用。因此相比Dalvik虛擬機(jī)，當(dāng)設(shè)備首次啟動(dòng)及應(yīng)用程序第一次安裝時(shí)，需要花費(fèi)的時(shí)間更久。Google聲稱，這種時(shí)間上的增加并不那么恐怖。他們希望并預(yù)期日后ART上完成上述動(dòng)作的時(shí)間會(huì)和目前的 Dalvik差不多，甚至更短些。

　　上面的圖顯示，ART帶來的性能提升是非常明顯的。對(duì)于同樣的代碼，性能提升約2倍左右。Google稱，將Android L最終發(fā)布的時(shí)候，可以預(yù)計(jì)的性能提升將會(huì)像Chessbench一樣，有3x的加速。

　　2 垃圾收集：理論和實(shí)踐

　　Android虛擬機(jī)依賴自動(dòng)化的內(nèi)存管理機(jī)制，即自動(dòng)垃圾收集。這一Java語(yǔ)言編程模式的基石也是Android系統(tǒng)自誕生之日起，非常重要的一部分。這里向不太了解垃圾收集概念的朋友解釋一下，所謂自動(dòng)垃圾收集，就是說程序員在編程過程中，不需要自己負(fù)責(zé)物理內(nèi)存的存儲(chǔ)的分配和釋放。只需要使用固定的模式創(chuàng)建你需要的變量或者對(duì)象，然后直接利用該變量或?qū)ο蠹纯?。程序的運(yùn)行環(huán)境會(huì)自動(dòng)在內(nèi)存中分配相應(yīng)的內(nèi)存空間存儲(chǔ)該變量或者對(duì)象， 并在該變量或者對(duì)象失效后，自動(dòng)釋放所分配的內(nèi)存。這是和其他需要人工進(jìn)行存儲(chǔ)管理的較低層次語(yǔ)言最大的區(qū)別。自動(dòng)垃圾收集的好處是，程序員不必再在編程時(shí)擔(dān)心內(nèi)存管理的問題，當(dāng)然，這也是有代價(jià)的，那就是程序員無法控制內(nèi)存何時(shí)分配和釋放，因而無法在需要時(shí)進(jìn)行優(yōu)化(Java語(yǔ)言有一些編程接口可以供程序員手工優(yōu)化程序，但控制方式和粒度有限).

　　Android曾經(jīng)被Dalvik的垃圾收集機(jī)制折騰了很久。Android平臺(tái)的內(nèi)存普遍較小，每次應(yīng)用程序需要分配內(nèi)存，當(dāng)堆空間(分配給應(yīng)用程序的一塊內(nèi)存空間)不能提供如此大小的空間時(shí)，Dalvik的垃圾收集器就會(huì)啟動(dòng)。垃圾收集器會(huì)遍歷整個(gè)堆空間，查看每一個(gè)應(yīng)用程序分配的對(duì)象，并對(duì)所有可到達(dá)的對(duì)象(即還會(huì)被使用的對(duì)象)標(biāo)記，并將那些沒有標(biāo)記的對(duì)象空間釋放掉。

　　在Dalvik虛擬機(jī)中，垃圾收集器執(zhí)行的過程將導(dǎo)致兩次應(yīng)用程序的停頓：

　　一是在遍歷堆地址空間階段，

　　另一個(gè)是標(biāo)記階段。

　　所謂停頓，即應(yīng)用程序所有正在執(zhí)行的進(jìn)程將暫停。如果停頓時(shí)間過長(zhǎng)，將會(huì)導(dǎo)致應(yīng)用程序在渲染時(shí)出現(xiàn)丟幀現(xiàn)象，進(jìn)而導(dǎo)致應(yīng)用程序的卡頓現(xiàn)象，大大降低用戶體驗(yàn)。

　　Google聲稱，在Nexus 5手機(jī)上，這種停頓的平均長(zhǎng)度在54ms。這個(gè)停頓時(shí)間將導(dǎo)致平均每次垃圾收集會(huì)導(dǎo)致在應(yīng)用程序渲染顯式時(shí)丟掉4幀的。

　　我自己的經(jīng)驗(yàn)和測(cè)試表明，根據(jù)應(yīng)用程序的不同，停頓的時(shí)間可能會(huì)增大很多。比如，在官方的FIFA應(yīng)用程序這一典型程序中，垃圾收集的停頓會(huì)非常厲害。

　　07-01 15:56:14.275: D/dalvikvm(30615): GCFORALLOC freed 4442K, 25% free 20183K/26856K, paused 24ms, total 24ms

　　07-01 15:56:16.785: I/dalvikvm-heap(30615): Grow heap (frag case) to 38.179MB for 8294416-byte allocation

　　07-01 15:56:17.225: I/dalvikvm-heap(30615): Grow heap (frag case) to 48.279MB for 7361296-byte allocation

　　07-01 15:56:17.625: I/Choreographer(30615): Skipped 35 frames! The application may be doing too much work on its main thread.

　　07-01 15:56:19.035: D/dalvikvm(30615): GCCONCURRENT freed 35838K, 43% free 51351K/89052K, paused 3ms+5ms, total 106ms

　　07-01 15:56:19.035: D/dalvikvm(30615): WAITFORCONCURRENTGC blocked 96ms

　　07-01 15:56:19.815: D/dalvikvm(30615): GCCONCURRENT freed 7078K, 42% free 52464K/89052K, paused 14ms+4ms, total 96ms

　　07-01 15:56:19.815: D/dalvikvm(30615): WAITFORCONCURRENTGC blocked 74ms

　　07-01 15:56:20.035: I/Choreographer(30615): Skipped 141 frames! The application may be doing too much work on its main thread.

　　07-01 15:56:20.275: D/dalvikvm(30615): GCFORALLOC freed 4774K, 45% free 49801K/89052K, paused 168ms, total 168ms

　　07-01 15:56:20.295: I/dalvikvm-heap(30615): Grow heap (frag case) to 56.900MB for 4665616-byte allocation

　　07-01 15:56:21.315: D/dalvikvm(30615): GCFORALLOC freed 1359K, 42% free 55045K/93612K, paused 95ms, total 95ms

　　07-01 15:56:21.965: D/dalvikvm(30615): GCCONCURRENT freed 6376K, 40% free 56861K/93612K, paused 16ms+8ms, total 126ms

　　07-01 15:56:21.965: D/dalvikvm(30615): WAITFORCONCURRENTGC blocked 111ms

　　07-01 15:56:21.965: D/dalvikvm(30615): WAITFORCONCURRENTGC blocked 97ms

　　07-01 15:56:22.085: I/Choreographer(30615): Skipped 38 frames! The application may be doing too much work on its main thread.

　　07-01 15:56:22.195: D/dalvikvm(30615): GCFORALLOC freed 1539K, 40% free 56833K/93612K, paused 87ms, total 87ms

　　07-01 15:56:22.195: I/dalvikvm-heap(30615): Grow heap (frag case) to 60.588MB for 1331732-byte allocation

　　07-01 15:56:22.475: D/dalvikvm(30615): GCFORALLOC freed 308K, 39% free 59497K/96216K, paused 84ms, total 84ms

　　07-01 15:56:22.815: D/dalvikvm(30615): GCFORALLOC freed 287K, 38% free 60878K/97516K, paused 95ms, total 95ms

　　上面的log是從FIFA應(yīng)用程序運(yùn)行后的幾秒鐘時(shí)間里截取的。垃圾收集器在短短的8秒內(nèi)被執(zhí)行了9次，導(dǎo)致應(yīng)用程序總共卡頓了603ms，丟幀達(dá)214次。絕大多數(shù)的卡頓都來自內(nèi)存分配請(qǐng)求，在log中以”GC_FOR_ALLOC;標(biāo)簽描述。

　　ART將整個(gè)垃圾收集系統(tǒng)做了重新設(shè)計(jì)和實(shí)現(xiàn)。為了能做些對(duì)比，下面給出使用ART運(yùn)行相同的應(yīng)用程序，在相同的場(chǎng)景下提取的log：

　　07-01 16:00:44.531: I/art(198): Explicit concurrent mark sweep GC freed 700(30KB) AllocSpace objects, 0(0B) LOS objects, 792% free, 18MB/21MB, paused 186us total 12.763ms

　　07-01 16:00:44.545: I/art(198): Explicit concurrent mark sweep GC freed 7(240B) AllocSpace objects, 0(0B) LOS objects, 792% free, 18MB/21MB, paused 198us total 9.465ms

　　07-01 16:00:44.554: I/art(198): Explicit concurrent mark sweep GC freed 5(160B) AllocSpace objects, 0(0B) LOS objects, 792% free, 18MB/21MB, paused 224us total 9.045ms

　　07-01 16:00:44.690: I/art(801): Explicit concurrent mark sweep GC freed 65595(3MB) AllocSpace objects, 9(4MB) LOS objects, 810% free, 38MB/58MB, paused 1.195ms total 87.219ms

　　07-01 16:00:46.517: I/art(29197): Background partial concurrent mark sweep GC freed 74626(3MB) AllocSpace objects, 39(4MB) LOS objects, 1496% free, 25MB/32MB, paused 4.422ms total 1.371747s

　　07-01 16:00:48.534: I/Choreographer(29197): Skipped 30 frames! The application may be doing too much work on its main thread.

　　07-01 16:00:48.566: I/art(29197): Background sticky concurrent mark sweep GC freed 70319(3MB) AllocSpace objects, 59(5MB) LOS objects, 825% free, 49MB/56MB, paused 6.139ms total 52.868ms

　　07-01 16:00:49.282: I/Choreographer(29197): Skipped 33 frames! The application may be doing too much work on its main thread.

　　07-01 16:00:49.652: I/art(1287): Heap transition to ProcessStateJankImperceptible took 45.636146ms saved at least 723KB

　　07-01 16:00:49.660: I/art(1256): Heap transition to ProcessStateJankImperceptible took 52.650677ms saved at least 966KB

　　ART和Dalvik的差別非常大，新的運(yùn)行時(shí)內(nèi)存管理僅僅停頓了12.364ms，運(yùn)行了4次前臺(tái)垃圾收集，以及2次后臺(tái)垃圾收集。在應(yīng)用程序執(zhí)行的過程中，應(yīng)用程序的堆空間大小并沒有增加，而Dalvik虛擬機(jī)中堆空間共增加了4次。丟幀的個(gè)數(shù)方面，ART虛擬機(jī)也降到了63幀。

　　上面這段示例，只不過是一個(gè)開發(fā)并不完善的應(yīng)用程序中最壞的一個(gè)場(chǎng)景。因?yàn)榧词乖贏RT虛擬機(jī)中，這個(gè)應(yīng)用程序還是丟掉了不少幀渲染圖像。不過上面的log對(duì)比依然很有參考價(jià)值，畢竟牛逼的程序員沒幾個(gè)，大多數(shù)的Android程序都沒辦法開發(fā)的很完美。Android需要能hold住這種情況。

　　ART將一些通常需要垃圾收集器做的工作，拆分給應(yīng)用程序本身完成。這樣，Dalvik中因?yàn)楸闅v堆空間引入的第一次停頓，就被完全消除了。而第二次停頓也因?yàn)橐豁?xiàng)預(yù)清理技術(shù) (packard pre-cleaning)的應(yīng)用而大大縮短。使用該技術(shù)后，只需要在清理完成后，簡(jiǎn)單的檢查和驗(yàn)證時(shí)稍微停頓一下即可。Google聲稱，他們已經(jīng)設(shè)法將這類停頓的時(shí)間縮短到3ms左右，相比Dalvik虛擬機(jī)的垃圾收集器來說，基本上是一個(gè)多數(shù)量級(jí)的降低，很不錯(cuò)了。

　　ART還引入了一個(gè)特殊的超大對(duì)象存儲(chǔ)空間(large object space，LOS)，這個(gè)空間與堆空間是分開的，不過仍然駐留在應(yīng)用程序內(nèi)存空間中。這一特殊的設(shè)計(jì)是為了讓ART可以更好的管理較大的對(duì)象，比如位圖對(duì)象(bitmaps)。在對(duì)堆空間分段時(shí)，這種較大的對(duì)象會(huì)帶來一些問題。比如，在分配一個(gè)此類對(duì)象時(shí)，相比其他普通對(duì)象，會(huì)導(dǎo)致垃圾收集器啟動(dòng)的次數(shù)增加很多。有了這個(gè)超大對(duì)象存儲(chǔ)空間的支持，垃圾收集器因堆空間分段而引發(fā)調(diào)用次數(shù)將會(huì)大大降低，這樣垃圾收集器就能做更加合理的內(nèi)存分配，從而降低運(yùn)行時(shí)開銷。

　　一個(gè)很好的例子，就是運(yùn)行Hangouts(環(huán)聊)應(yīng)用程序時(shí)，在Dalvik虛擬機(jī)中，我們能看到數(shù)次因?yàn)榉峙鋬?nèi)存，運(yùn)行GC而導(dǎo)致的停頓。

　　07-01 06:37:13.481: D/dalvikvm(7403): GCEXPLICIT freed 2315K, 46% free 18483K/34016K, paused 3ms+4ms, total 40ms

　　07-01 06:37:13.901: D/dalvikvm(9871): GCCONCURRENT freed 3779K, 22% free 21193K/26856K, paused 3ms+3ms, total 36ms

　　07-01 06:37:14.041: D/dalvikvm(9871): GCFORALLOC freed 368K, 21% free 21451K/26856K, paused 25ms, total 25ms

　　07-01 06:37:14.041: I/dalvikvm-heap(9871): Grow heap (frag case) to 24.907MB for 147472-byte allocation

　　07-01 06:37:14.071: D/dalvikvm(9871): GCFORALLOC freed 4K, 20% free 22167K/27596K, paused 25ms, total 25ms

　　07-01 06:37:14.111: D/dalvikvm(9871): GCFORALLOC freed 9K, 19% free 23892K/29372K, paused 27ms, total 28ms

　　我們從所有的垃圾收集log中截取了上述一段。其中的顯式(GC_EXPLICIT)和并發(fā)(GC_CONCURRENT)是垃圾收集器中比較通用的清理和維護(hù)性調(diào)用。GC_FOR_ALLOC則是在內(nèi)存分配器嘗試分配新的內(nèi)存空間，但堆空間不夠用時(shí)，調(diào)用的。上面的log中，我們能看到堆空間因?yàn)榉侄尾僮鞫鴶U(kuò)充了堆空間，但仍然無法裝下大對(duì)象。在整個(gè)大對(duì)象分配的過程中，停頓時(shí)間長(zhǎng)達(dá)90ms。

　　相比之下，下面這段log是從Android L預(yù)覽版本的ART運(yùn)行l(wèi)og中提取的。

　　07-01 06:35:19.718: I/art(10844): Heap transition to ProcessStateJankPerceptible took 17.989063ms saved at least -138KB

　　07-01 06:35:24.171: I/art(1256): Heap transition to ProcessStateJankImperceptible took 42.936250ms saved at least 258KB

　　07-01 06:35:24.806: I/art(801): Explicit concurrent mark sweep GC freed 85790(3MB) AllocSpace objects, 4(10MB) LOS objects, 850% free, 35MB/56MB, paused 961us total 83.110ms

　　我們目前還不知道log中的”Heap Transition”表達(dá)的什么意思，不過可以猜測(cè)應(yīng)該是堆空間大小重設(shè)機(jī)制。在應(yīng)用程序已經(jīng)運(yùn)行之后，唯一的對(duì)垃圾收集器的調(diào)用僅消耗的961us。我們并沒有在這段截取的log之前，發(fā)現(xiàn)任何對(duì)垃圾收集器的調(diào)用操作。這段log中比較有趣的，就是LOS的統(tǒng)計(jì)。能夠看到，在LOS中有4個(gè)較大的對(duì)象，共10MB。這塊內(nèi)存并沒有分配在堆空間內(nèi)，否則應(yīng)該會(huì)有類似Dalvik的提示。

　　ART的內(nèi)存分配系統(tǒng)本身也被重寫了。雖然ART相比Dalvik，在內(nèi)存分配方面，能夠帶來大約25%的性能提升，不過Google顯然對(duì)此不滿意，因此引入了一個(gè)新的內(nèi)存分配器來取代當(dāng)前使用的;malloc”分配器。

　　這個(gè)新的內(nèi)存分配器，;rosalloc”(Runs-of-Slots-Allocator)是依據(jù)多線程Java應(yīng)用程序的特點(diǎn)而設(shè)計(jì)的。此內(nèi)存分配器有更細(xì)粒度的鎖機(jī)制，可以直接對(duì)獨(dú)立的對(duì)象上鎖，而非對(duì)整個(gè)待分配的內(nèi)存空間上鎖。在線程局部區(qū)域中的小對(duì)象的分配，完全可以無視鎖的存在了。沒有了鎖的請(qǐng)求和釋放，線程局部小對(duì)象的訪問速度也就大幅提升了。

　　這個(gè)新的內(nèi)存分配器大幅提升了內(nèi)存分配的速度，加速比達(dá)到了10x。

　　同時(shí)，ART的垃圾回收算法也做了改進(jìn)，提升了用戶使用體驗(yàn)，避免應(yīng)用程序的卡頓。這些算法在Google內(nèi)部目前仍然正在開發(fā)中。近期，Google僅僅介紹了一個(gè)新算法，;Moving Garbage Collector”.核心思想是，當(dāng)應(yīng)用程序運(yùn)行在后臺(tái)時(shí)，將程序的堆空間做段合并操作。

　　3 64位支持

　　ART在設(shè)計(jì)時(shí)充分考慮了將日后可能運(yùn)行的各種平臺(tái)進(jìn)行模塊化。因此，ART提供了大量的編譯器后端，用于生成目前常見的體系結(jié)構(gòu)的代碼，例如ARM，X86和MIPS，其中包括對(duì)ARM64， X86-64的支持，以及尚未實(shí)現(xiàn)的對(duì)MIPS64的支持。

　　對(duì)于ARM的64位系統(tǒng)帶來的好處，相比很多朋友都了解了。更大的內(nèi)存地址空間，普適的性能提升，以及加解密的能力和性能提升，此外還有對(duì)已有32位應(yīng)用程序的兼容。

　　除此之外，Google還在ART中引入了引用壓縮技術(shù)，來避免ART堆空間內(nèi)部因?yàn)?4位指針的引入導(dǎo)致的內(nèi)存占用變大問題。其實(shí)，就是在執(zhí)行時(shí)，所有的指針都采用32位表示，而非64位系統(tǒng)應(yīng)該采用的64位指針。

　　Google公開了一些ARM和X86平臺(tái)上應(yīng)用程序在64位和32位模式下的性能對(duì)比。這只是一些預(yù)覽性質(zhì)數(shù)據(jù)。X86的性能測(cè)試在Intel的 BayTrail系統(tǒng)上進(jìn)行，對(duì)于不同的RenderScript測(cè)試程序，性能提升從2x到4.5x不等。ARM平臺(tái)方面，分別在A57和A53系統(tǒng)上，對(duì)crypto的性能做了對(duì)比。這些數(shù)據(jù)因?yàn)槎际轻槍?duì)非常小的例子，所以代表性不大，因此還無法代表實(shí)際應(yīng)用場(chǎng)景的情況。

　　不過，Google也放出了一些有趣的數(shù)據(jù)，這些數(shù)據(jù)是在他們內(nèi)部使用的系統(tǒng)Panorama上測(cè)試的。通過簡(jiǎn)單的從32位ABI轉(zhuǎn)換為64位 ABI，能夠獲得13%到19%的性能提升。還有個(gè)喜人的結(jié)論，那就是ARM的Cortex A53在AArch64模式下能獲得性能提升比A57核要多。

　　Google還聲稱，目前應(yīng)用商店中85%的應(yīng)用程序都可以直接在64位模式下運(yùn)行，也就是說僅有15%的應(yīng)用程序在某種程度上使用了本地代碼，需要重新為64位平臺(tái)編譯該應(yīng)用程序。這對(duì)Google來說將是一個(gè)非常大的優(yōu)勢(shì)。明年，當(dāng)大多數(shù)芯片廠商都開始推64位片上系統(tǒng)的時(shí)候，從32位 Android系統(tǒng)到64位Android系統(tǒng)的的切換將會(huì)非常快。

　　4 結(jié)論

　　結(jié)合上面介紹的諸多方面，ART是Google發(fā)布的一款性能提升大殺器，并且ART也解決了多個(gè)數(shù)年來困擾Android系統(tǒng)的諸多問題。ART 有效地改進(jìn)了多個(gè)解釋執(zhí)行應(yīng)用程序面臨的問題，也提供了一個(gè)自動(dòng)化的高效的存儲(chǔ)管理系統(tǒng)。對(duì)于開發(fā)者來說，許多過去需要手工添加代碼解決的性能問題，現(xiàn)在都能被ART輕松hold住了。

　　這也意味著Android系統(tǒng)終于能夠在系統(tǒng)平滑度，應(yīng)用程序性能方面與IOS勢(shì)均力敵了。對(duì)消費(fèi)者來說，是件喜大普奔的事情。

　　Google目前仍在，而且在未來一段時(shí)間內(nèi)還將大力改進(jìn)ART。ART目前的狀況，與6個(gè)月前已經(jīng)大不相同了，預(yù)計(jì)等到Android L真正發(fā)布的時(shí)候，又會(huì)有翻天覆地的變化。前途是光明的，讓我們拭目以待，翹首期盼吧。