Android L對開發者意味著什麼？

對於Android的下一代操作系統" L"，相信有不少驚喜。但是對於開發者來說，對這個新系統也有頗多疑問，那麼這個新系統究竟有哪些問題是開發者問的最多的呢？

剛剛結束的 Google I/O 大會上，Android下一代操作系統" L"帶來不少驚喜。新系統運行更快、更省電。

然而開發者對這個新系統也有頗多疑問，比如新的運行模式ART對開發者意味著什麼？ART模式能否讓應用的體驗超越蘋果？我認為在ART運行方式下"L"的性能提升在15%到80%之間。同時，ART優化瞭垃圾回收方式，執行效率比現行的Dalvik提高50%以上，減少瞭執行垃圾回收時對應用帶來的卡頓，使應用運行更流暢。

而在安全性方面，ART和Dalvik相比，安全模型和基本機制沒有變化。但ART有一些細節改進，對安全有幫助。比如，安裝時對dex文件做瞭更嚴格的驗證。

以下我匯集整理瞭開發者提問最多的6個問題，一並解答，希望可以幫助開發者更好滴認識這個全新的系統。

問題1. 為什麼ART能提高性能？

答：主要來自兩方面。

1）預先（Ahead-of-time）編譯。Android應用開發時，生成的Dex文件包含Java的Byte Code。在AndroidL以前，默認用Dalvik虛擬機。應用運行時，Dalvik對Java Byte Code進行解釋執行，或進行Junt-In-Time的編譯。在Android L裡，應用安裝時，用系統工具dex2oat將安裝包中的Dex文件編譯為ELF格式的執行文件（.oat文件）。應用運行時直接執行二進制指令。

2）優化垃圾回收（garbagecollection）。垃圾回收主要有兩種：（1）gc_concurrent。執行時，Dalvik會在本次gc的開始和結束時會短時間暫停代碼的執行。（2）gc_for_alloc。執行時，會較長時間中斷Java代碼的運行。在ART裡，執行gc_concurrent時，隻會暫停代碼一次。執行gc_for_alloc時，中斷Java代碼運行的時間大大縮小瞭。總體上講，ART裡垃圾回收占用的開銷比Dalvik少50%以上。減少瞭垃圾回收時對應用帶來的卡頓，使應用運行更流暢。

問題2. 對應用開發者來說，需要做什麼適配工作以支持ART。比如重新編譯，打包？

答：對絕大多數開發者來說，不需要。不論虛擬機是Dalvik還是ART，安裝包裡所包含的仍然是Dex文件。由Dex文件編譯為二進制文件的工作是在應用安裝時，由裝在設備上的系統工具dex2oat完成的。

問題3. Android的應用在ART裡運行後，開發者還能在Java層面進行調試嗎？

答：可以。事實上，應用安裝後，編譯生成的.oat文件中，包含瞭原始的Dex文件。保留Dex文件有兩個原因：

1）需要Dex裡的關於類的信息，以支持Java反射等操作。

2）調試時，要用Dex裡的調試信息。

正由於這個原因，編譯生成的.oat文件，大小是原始的Dex文件的兩倍以上。

問題4. 用ART後，性能最終能提高多少？

答：取決於具體的應用。在Google I/O上，Google給的例子是提升兩倍以上。

ART我們實際測試下來，性能提升在15%到80%之間。對於大量使用CPU的應用，性能提升比較明顯。但如果應用程序的時間主要花在調用系統API，提升會小一些。因為很多系統API的代碼主要在底層的.so裡面。

問題5. ART在安全性上有沒有提升？

答：ART和Dalvik相比，安全模型和基本機制沒有變化。但ART有一些細節改進，對安全有幫助。比如：

（1）安裝時對dex文件做瞭更嚴格的驗證。

（2）糾正瞭Dalvik長期存在的一個對象模型的問題：一個類裡的方法，如果沒有加訪問限制（即沒有用Public，Private，Protected描述），Java規定是package-private方法，不在同一package的子類不能訪問和重載。而Dalvik一直允許子類重載package-private的方法。ART裡做瞭修改，行為與Java標準一致。

問題6. Android L使用ART後，有什麼要引起註意的地方？

答：主要有這麼幾個：

（1）因為安裝時進行瞭預先編譯。應用安裝的時間變長，安裝後生成的文件變大。

（2）如果以DexClassLoader的形式加載代碼，第一次執行時間也會變長。

（3）對應用最好進行兼容性測試。大多數應用無需修改，但如果應用程序本身對Dex文件做瞭處理，比如進行瞭加殼，可能有兼容性問題。

總體來說，Android L十分值得我們期待，今年秋天Google將推出正式版本，不過鑒於目前Android系統碎片化的現狀，當前大部分手機無法升級，隻能購買新款手機。

---

Orignal From: Android L對開發者意味著什麼？