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

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

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

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

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

　　1 架構(gòu)介紹

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

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

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

　　ART對續(xù)航時間的影響也是非常顯著的。 因為不再需要解釋執(zhí)行， JIT也不用在程序運(yùn)行時工作， 這樣會直接節(jié)省CPU需要執(zhí)行的指令數(shù)， 因而耗電降低。

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

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

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

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

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

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

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

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

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

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

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

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

　　ART將整個垃圾收集系統(tǒng)做了重新設(shè)計和實(shí)現(xiàn)。 為了能做些對比， 下面給出使用ART運(yùn)行相同的應(yī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)行時內(nèi)存管理僅僅停頓了12.364ms， 運(yùn)行了4次前臺垃圾收集， 以及2次后臺垃圾收集。 在應(yīng)用程序執(zhí)行的過程中， 應(yīng)用程序的堆空間大小并沒有增加， 而Dalvik虛擬機(jī)中堆空間共增加了4次。 丟幀的個數(shù)方面， ART虛擬機(jī)也降到了63幀。

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

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

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

　　一個很好的例子， 就是運(yùn)行Hangouts(環(huán)聊)應(yīng)用程序時， 在Dalvik虛擬機(jī)中， 我們能看到數(shù)次因為分配內(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)存空間， 但堆空間不夠用時， 調(diào)用的。 上面的log中， 我們能看到堆空間因為分段操作而擴(kuò)充了堆空間， 但仍然無法裝下大對象。 在整個大對象分配的過程中， 停頓時間長達(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á)的什么意思， 不過可以猜測應(yīng)該是堆空間大小重設(shè)機(jī)制。 在應(yīng)用程序已經(jīng)運(yùn)行之后， 唯一的對垃圾收集器的調(diào)用僅消耗的961us。 我們并沒有在這段截取的log之前， 發(fā)現(xiàn)任何對垃圾收集器的調(diào)用操作。 這段log中比較有趣的， 就是LOS的統(tǒng)計。 能夠看到， 在LOS中有4個較大的對象， 共10MB。 這塊內(nèi)存并沒有分配在堆空間內(nèi)， 否則應(yīng)該會有類似Dalvik的提示。

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

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

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

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

　　3 64位支持

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

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

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

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

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

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

　　4 結(jié)論

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

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

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