3.5 ART機制基礎

隨著Android 4.4和Android L版本的推出，Dalvik VM系統逐漸被谷歌拋棄，取而代之的是ART運行機制。ART模式英文全稱為：Android runtime，是從Android 4.4系統開始新增的一種應用運行模式，與傳統的Dalvik模式不同，ART模式可以實現更為流暢的安卓系統體驗，對于大家來說，只要明白ART模式可讓系統體驗更加流暢，不過只有在Android 4.4以上系統中采用此功能。在本章的內容中，將詳細講解ART技術的基礎知識，為讀者步入本書后面知識的學習打下基礎。

3.5.1 什么是ART模式

ART模式的完整名稱是Androidruntime，事實上谷歌的這次優化源于前不久其收購的一家名為Flexycore的公司，該公司一直致力于Android系統的優化，而ART模式也是在該公司的優化方案上演進而來。ART的機制與Dalvik不同。在Dalvik下，應用每次運行的時候，字節碼都需要通過即時編譯器轉換為機器碼，這會拖慢應用的運行效率；而在ART環境中，應用在第一次安裝的時候，字節碼就會預先編譯成機器碼，使其成為真正的本地應用。這個過程稱為預編譯（AOT, Ahead-Of-Time）。這樣，應用的啟動和執行都會變得更加快速。

ART模式與Dalvik模式最大的不同在于，在啟用ART模式后，系統在安裝應用的時候會進行一次預編譯，在安裝應用程序時會先將代碼轉換為機器語言存儲在本地，這樣在運行程序時就不會每次都進行一次編譯了，執行效率也大大提升。從這方面來看，ART模式確實能夠改善Android平臺一直以來在兼容性方面的妥協，但另一方面，應用經過預編譯后的容量，以及應用是否兼容該模式也是需要重點考慮的問題。因此接下來筆者也準備通過一些測試來看看ART模式目前的表現是否能令人滿意。

（1）產生背景。

與iOS相比，Android的用戶體驗總是差強人意。隨著Google的全力推動和硬件廠商的響應，Android還是跨越各種阻礙，逐漸壯大起來了。在此過程中，Google也在經歷著重大的變化。它逐漸從一個只重視數據的公司，轉變為一個重視設計和用戶體驗的公司。從Android 4.0開始，Android擁有了自己的設計語言和應用設計指導。與此同時，Google也在著手解決卡頓問題，Android 4.1使系統和應用運行都更加順暢，而Android 4.2提升了內存管理，使得系統能夠順利運行在硬件配置低端的設備上。

但是，所有這些都沒有解決核心問題，那就是應用運行環境：Dalvik VM效率并不是最高的。從Android 4.4開始，Google開發者引進了新的Android運行環境ART。Android官方將其作為其新的虛擬機，以替代舊的Dalvik VM。

根據一些基準測試，新的運行環境能夠使大多數應用的執行時間減半。這意味著，CPU消耗大、運行時間長的應用能夠更加快速地完成，而一般的應用也能更加流暢，比如動畫效果更順暢，觸控反饋更加即時。在多核處理器的設備上，多數情況下只需激活少量的核心，或者能夠更好地利用ARM的big.LITTLE架構。另外，它將會顯著提升電池的續航能力以及系統的性能。

預編譯也會帶來一些缺點。一方面，機器碼占用的存儲空間更大。字節碼變為機器碼之后，可能會增加10%～20%，不過在應用包中，可執行的代碼常常只是一部分。比如最新的Google+APK是28.3MB，但是代碼只有6.9MB。另一方面，應用的安裝時間會變長。至于延長多少時間，取決于應用本身，一些復雜的應用，如Facebook和Google+，會讓你等待更長時間。

（2）Android系統性能提升之路。

Dalvik虛擬機作為Android平臺的核心組成部分之一，允許在有限的內存資源中同時運行多個虛擬機實例。Dalvik虛擬機通過以下方式提升性能。

DEX代碼安裝時或第一次動態加載時odex化處理。

Android 2.2版本提供了JIT機制提升性能，號稱性能提升3~5倍。

提升硬件配置，如更多核CPU、更高頻率CPU、更大的RAM等。

但是Android的系統流暢度與iOS系統還是有一定差距。Android代碼必須運行在Dalvik虛擬機上，而iOS直接是本地代碼，性能差距也在情理之中。如果Android系統想擁有與iOS系統相同的系統性能，Dalvik虛擬機運行機制就成為Android系統性能提升唯一的障礙。

從Android 4.4開始提供了一種與Dalvik截然不同的運行環境——ART（Android Runtime）的支持。

（3）ART架構。

ART完全兼容Dalvik的字節碼格式dex，因此，開發者編寫軟件不會受到影響，也無需擔心兼容性問題。ART的一大變化是，它不僅支持即時編譯（JIT），而且支持預先編譯（AOT）。在Dalvik上，每次軟件運行，都需從字節碼編譯為原生代碼，ART可以只編譯一次。然后，軟件每次運行時，執行編譯好的原生代碼。預先編譯也為新的優化帶來了可能性。同時，這也會明顯改善電池續航，因為軟件運行時不用編譯了，從而減少了CPU的使用頻率，降低了能耗。

誕生ART也有一些缺點。其中之一是：設備首次啟動以及應用的首次啟動時間會變長。不過，Google宣稱說，這種差別不是很大，而且他們會在這方面努力，使其接近甚至超過Dalvik。另一個缺點是原生代碼占用空間更大，不過，現在設備的空間應該都足夠。

（4）垃圾回收。

Android虛擬機是自動內存管理，這種方式的優點是開發者無需擔心內存管理，缺點是開發者失去了控制權，依賴于系統本身的機制。Dalvik的垃圾回收機制是造成系統卡頓的原因之一。在Dalvik虛擬機下，啟動垃圾回收機制會造成兩次暫停（一次在遍歷階段，一次在標記階段）。所謂暫停，就是應用的所有線程都不再執行。如果暫停時間過長，應用渲染中就會出現掉幀。用戶體驗上來說，就是應用運行的時候出現卡頓。

Google宣稱，Neuxs 5的平均暫停時間是54ms，結果就是，每次垃圾回收啟動，平均掉幀是4幀。如果應用編寫得不好，情況會更加糟糕。Anandtech測試了FIFA游戲。Dalvik環境下，啟動應用的幾秒內，垃圾回收啟動9次，應用暫停時間總和為603ms，總共掉幀為214幀。在ART下，情況有了極大改善。同樣時間里，應用暫停時間總和為12.364ms（4次前臺垃圾回收，2次后臺垃圾回收），總共掉幀是63幀。

ART能夠做到這一點，是因為應用本身做了垃圾回收的一些工作。垃圾回收啟動后，不再是兩次暫停，而是一次暫停。在遍歷階段，應用不需要暫停，而標記階段的暫停時間也大大縮短，因為Google使用了一種新技術（packard pre-cleaning），在暫停前就做了許多事情，減輕了暫停時的工作量。Google承諾，他們已經把平均暫停時間降到了3ms，遠遠超過Dalvik的垃圾回收。

與此同時，Google還改進了內存分配系統，使分配速度加快了10倍。垃圾回收算法也進行了修改，以增強用戶體驗，避免應用被打斷。

（5）64位支持。

ART支持64位系統，這會帶來性能上的提升，加密能力的大幅改進，同時保持與現有32位應用的兼容性。與蘋果不同的是，Google使用了指針壓縮，以避免轉換到64位后，空間占用大幅增加，其虛擬機仍然是32位指針。

Google宣稱，現有Play Store上應用中，85%都可以轉移到64位，剩下的15%有原生代碼，需要重新編譯。總地來說，轉移到64位應該會在短時間內完成。

綜上所述，Google兌現了其提升性能的承諾，解決了困擾Android性能的諸多問題。原來Android的一些致命弱點是因為非原生應用和自動內存管理系統，ART在這些方面做出了大量改進。總之，在應用的流暢度和性能方面，Android終于可以與iOS一決高下了。

3.5.2 ART優化機制基礎

在安裝應用程序時，Dalvik Runtime采用的代碼優化方式是：

        dex2opt（http://124.16.139.131:24080/lxr/source/dalvik/dexopt/OptMain.cpp? v= android-4.0.4#f_
        OptMain.cpp）

而ART Runtime采用的代碼優化方式是：

        dex2oat (https://android.googlesource.com/platform/art/+/kitkat-release/dex2oat/dex2oat.cc)

Dalvik運行環境和ART運行環境產生的優化代碼路徑及文件名都為：

        /data/dalvik-cache/app/data@app@{package name}.apk@classes.dex

ART環境產生的優化代碼文件大小明顯比Dalvik環境產生大。

在Android L系統中，ART模塊的實現源碼被保存在Android L源碼的根目錄“art”中，如圖3-5所示。

從源代碼文件目錄名稱可以很清楚地了解各文件夾中相關文件的功能，其中最為主要的有compiler、dex2oa和runtime這3個文件夾，具體說明如下所示。

compiler：主要負責Dalvik字節碼到本地代碼的轉換，編譯為libart-compiler.so。

dex2oat：完成DEX文件到ELF文件轉換，編譯為dex2oat。

runtime:Android ART運行時源代碼，編譯為libart.so。