剛剛結束的 Google I/O 大會上，Android 下一代操作系統「L」帶來不少驚喜。新系統運行更快、更省電。
然而開發者對這個新系統也有頗多疑問，比如新的運行模式 ART 對開發者意味著什么？ART 模式能否讓應用的體驗超越蘋果？我認為在 ART 運行方式下「L」的性能提升在 15% 到 80% 之間。同時，ART 優化了垃圾回收方式，執行效率比現行的 Dalvik 提高 50% 以上，減少了執行垃圾回收時對應用帶來的卡頓，使應用運行更流暢。
而在安全性方面，ART 和 Dalvik 相比，安全模型和基本機制沒有變化。但 ART 有一些細節改進，對安全有幫助。比如，安裝時對 dex 文件做了更嚴格的驗證。
以下我匯集整理了 360 論壇上開發者提問最多的 6 個問題，一并解答，希望可以幫助開發者更好地認識這個全新的系統。
問題 1. 為什么 ART 能提高性能？
答：主要來自兩方面。
預先（Ahead-of-time）編譯。Android 應用開發時，生成的 Dex 文件包含 Java 的 Byte Code。在 Android L 以前，默認用 Dalvik 虛擬機。應用運行時，Dalvik 對 Java Byte Code 進行解釋執行，或進行 Junt-In-Time 的編譯。在 Android L 里，應用安裝時，用系統工具 dex2oat 將安裝包中的 Dex 文件編譯為 ELF 格式的執行文件（.oat 文件）。應用運行時直接執行二進制指令。
優化垃圾回收（garbage collection）。垃圾回收主要有兩種：（1）gcconcurrent。執行時，Dalvik 會在本次 gc 的開始和結束時會短時間暫停代碼的執行。（2）gcforalloc。執行時，會較長時間中斷 Java 代碼的運行。在 ART 里，執行 gcconcurrent 時，只會暫停代碼一次。執行 gcforalloc 時，中斷 Java 代碼運行的時間大大縮小了。總體上講，ART 里垃圾回收占用的開銷比 Dalvik 少 50% 以上。減少了垃圾回收時對應用帶來的卡頓，使應用運行更流暢。
問題 2. 對應用開發者來說，需要做什么適配工作以支持 ART。比如重新編譯、打包？
答：對絕大多數開發者來說，不需要。不論虛擬機是 Dalvik 還是 ART，安裝包里所包含的仍然是 Dex 文件。由 Dex 文件編譯為二進制文件的工作是在應用安裝時，由裝在設備上的系統工具 dex2oat 完成的。
問題 3. Android 的應用在 ART 里運行后，開發者還能在 Java 層面進行調試嗎？
答：可以。事實上，應用安裝后，編譯生成的.oat 文件中，包含了原始的 Dex 文件。保留 Dex 文件有兩個原因：
需要 Dex 里的關于類的信息，以支持 Java 反射等操作。
調試時，要用 Dex 里的調試信息。
正由于這個原因，編譯生成的.oat 文件，大小是原始的 Dex 文件的兩倍以上。
問題 4. 用 ART 后，性能最終能提高多少？
答：取決于具體的應用。在 Google I/O 上，Google 給的例子是提升兩倍以上。
ART 我們實際測試下來，性能提升在 15% 到 80% 之間。對于大量使用 CPU 的應用，性能提升比較明顯。但如果應用程序的時間主要花在調用系統 API，提升會小一些。因為很多系統 API 的代碼主要在底層的.so 里面。
問題 5. ART 在安全性上有沒有提升？
答：ART 和 Dalvik 相比，安全模型和基本機制沒有變化。但 ART 有一些細節改進，對安全有幫助。比如：
安裝時對 dex 文件做了更嚴格的驗證。
糾正了 Dalvik 長期存在的一個對象模型的問題：一個類里的方法，如果沒有加訪問限制（即沒有用 Public，Private，Protected 描述），Java 規定是 package-private 方法，不在同一 package 的子類不能訪問和重載。而 Dalvik 一直允許子類重載 package-private 的方法。ART 里做了修改，行為與 Java 標準一致。
問題 6. Android L 使用 ART 后，有什么要引起注意的地方？
答：主要有這么幾個：
因為安裝時進行了預先編譯。應用安裝的時間變長，安裝后生成的文件變大。
如果以 DexClassLoader 的形式加載代碼，第一次執行時間也會變長。
對應用最好進行兼容性測試。大多數應用無需修改，但如果應用程序本身對 Dex 文件做了處理，比如進行了加殼，可能有兼容性問題。
總體來說，Android L 十分值得我們期待，今年秋天 Google 將推出正式版本，不過鑒于目前 Android 系統碎片化的現狀，當前大部分手機無法升級，只能購買新款手機。
極客觀察均為極客公園原創報道，轉載請注明原文鏈接。