本文內容與圖片皆來自於 Cody Toombs 發表於 Android Police 的 Meet ART, Part 2: Benchmarks - Performance Won't Blow You Away Today, But It Will Get Better 。本文為翻譯。
Cody Toombs 於 Android Police 發表的 “Meet ART, Part 2: Benchmarks - Performance Won't Blow You Away Today, But It Will Get Better” 針對 ART 有一系列的測試，因此翻譯本篇文章，希望能讓大家對目前的 ART 有更進一步的瞭解，也有助於決定是否要使用 ART。
也許你已經聽說過 ART 以及 ART 如何增進 Android 的速度與效能，不過真實的表現如何？新的 ART 不再負擔 Dalvik 的許多包袱，因此不再需要那麼多系統資源。這聽起來很棒，可是 ART 離成熟還很遠，而且也還沒調整好。我針對 ART 做了電力的測試，看看這個新的執行階段是否真的能夠應付熱切的期望。ART 確實達成了某些承諾，但是我要先警告你，接下來你所看到的測試結果可能無法打動你。
實際比對
老實說吧，跑分軟體其實不準確也不可靠。即使在精準控制下環境條件都一樣，依然可能出現差距相當大的結果。然而，在量化效能以及數值紀錄上，跑分軟體也是唯一的選擇。此外，大部分的跑分軟體都是使用 NDK（Native Development Kit）編譯而成，因此使用 ART 執行階段也不會再有其他助益。儘管有這些限制，結果中依然出現了一些引人注目，出乎意料的部分，有助於我們對於這個新的執行階段的效能可以有更進一步的認識。
如何測試
在完全沒變更過的 Nexus 5（連 root 都沒有）上，Dalvik 執行階段與 ART 執行階段各跑至少四次。為了確定不會有其他應用程式影響，每次測試前都要先重開機，並且靜置五分鐘。除了圖片中的六種跑分軟體外，我還用 Chrome 跑了兩套瀏覽器跑分軟體 SunSpider 與 BrowserMark，不過分數看不出明顯的差別。好了，那麼我們就來看看跑分結果吧。Linpack for Android
取得良好測試結果的一個重點就是要確定跑分軟體測試的項目與期望值符合。許多跑分軟體都是用 NDK 寫成的，只有少數選擇 SDK。我選擇的跑分軟體中第一個同時也是最符合期望的就是 Linpack，一個在許多知名平台都提供跑分程序的知名跑分軟體。Linpack 執行了一系列的浮點運算，然後據此產生一個分數。在閱讀完 Linpack 的說明後，我認為明顯的該選擇它：「跟處理器的浮點運算能力相較，這個測試比較能反應 Android 的 Dalvik 虛擬機器的狀態」。感謝 ART，分數比 Dalvik 還要高了 10 到 14 個百分點，還不錯。
附註：使用 SDK 寫成，編譯的 app 需要 Dalvik 虛擬機器才能運行。而使用 NDK 寫成，編譯的 app 就已經是原生代碼（native code），不透過 Dalvik 虛擬機器執行了。這一點跟 ART 轉換後的 app 是一樣的。原本 ART 的設計就是用來解決 Dalvik 效率不彰的問題。
Real Pi Benchmark
計算 π 的無限小數位數一直都是個流行的處理器壓力測試，而且是個適合我們的測試。因為大多數的測試方式都是測整數計算，而且完全避免浮點運算。搭配著 Linpack 的結果一起看，可以涵蓋基礎的數學運算。Real Pi 在 計算「算術-幾何平均數（AGM）」與「快速傅立葉變換（FFT）」公式部分是用 NDK 寫成，而「梅欽類（Machin's）」公式則是用 Java 來處理。在原生代碼（NDK）部分，ART 比 Dalvik 快了 3.5。這或許是因為介面的優化，而不是數學計算能力上的差異。比較重要的是 Java 這方面的測試快了 12%。（附註：數字越小，表示越好）。
Quadrant Standard
前面的測試高度著重於數學計算的能力，該來針對系統其他能力作點測試了。Linpack 與 Real Pi 的測試結果顯示 ART 在某些方面確實有改進，但是 Quadrant 的結果幾乎讓人嚇一大跳，可能好過頭了。ART 的 CPU 分數幾乎是 Dalvik 的兩倍，這表現遠優於我們所聽過最樂觀的估算。至於在 I/O，2D 與 3D 繪圖的測試方面，差距小到可以忽略。Dalvik 在記憶體測試分數高了 ART 有 9 個百分點。
 |  |
3D Mark
我曾經懷疑是否要用完全使用 NDK 編譯而成的跑分軟體，因為理論上 ART 應該造成不了什麼影響。然而，測試結果中很有趣的 Dalvik 執行階段多次領先。很難推導 Dalvik 在這邊表現較好的原因，但我接受各種可能性。
AnTuTu Benchmark
把「效能」更進一步地分成許多細項加以分析。安兔兔有助於揭露一種模式：ART 在浮點運算上有顯著成長這件事情越來越明顯，但是在整數運算上並沒有明顯的增進。在「RAM Operation」的強勢表現指明了 ART 更妥善的運用了快取，而不是直接對記憶體 I/O。這些高分的地方表示運行 Dalvik 的成本很可觀，需要消耗更多資源。其他地方除了 Storage I/O 之外都沒有顯著到需要注意，這也許意味著一些特定程序的最佳化。UX Dalvik 明顯的低分，但是不清楚安兔兔這個項目指的是什麼，所以可能沒什麼關係。
CF-Bench
Chaifire 這隻同時使用了 SDK 與 NDK 編譯的跑分工具的測試結果帶來了許多猜測。再一次，原生代碼的部分 Dalvik 再次擁有幅度雖小但是令人難以理解的領先。我們能看到整數計算的部分也對 Dalvik 比較有利。再一次證明浮點運算有著大幅度的強化，這次領先幅度有 23 到 33 個百分點。
其他有趣的測驗
切換執行階段後的首次開機需時通常不會是標準測試項目，但是這個時間長度一定會引起你注意，不要懷疑。我記錄的時間包含了 "Android 正在進行最佳化…" 一直到出現解鎖畫面為止。這台機器上有 149 隻 app。
其他表現
雖然數字在比較上很有用，但是光靠數字看不透全貌。跑分軟體通常只是在短時間內將硬體催到極限，然後換一套測試又再次把硬體催到極限。可惜的是，這種測試方法會忽略了那些不容易測量的細節處。我沒有好方法來測試改進過的記憶體管理（尤其是在垃圾回收 garbage collection 這方面）或是更佳的多執行緒管理。雖然我沒有辦法將這些特色量化，但是我可以證明。瀏覽器的經典測試：甩頁面。盡可能的快速甩動頁面，並且看看畫面能保持多少頁面內容。繼在 Davis 的巨大的 HTC One 評論中對 Mobile 模式的 Chrome 一陣狂操的測試後，證明了 Nexus 5 上強化過的 SoC（註：HTC One 用的是 Qualcomm Snapdragon 600 1.7GHz，Nexus 5 用的是 Qulacomm Snapdragon 800 2.3GHz）在 Dalvik 下一樣無法維持頁面的完整性。但是在 ART 環境中，一個像素都沒有掉過。你自己看。為了公平起見，將 Chrome 切換成 Desktop 模式然後跑一樣的測試。不管是哪個執行階段，畫面都很容易呈現大片的空白。但是可以發現 ART 的渲染比 Dalvik 還要快。可以期待 ART 的弱點被最佳化後，在 Desktop 模式可以實現完美的捲頁。有一位名為 spogbiper 的使用者貼了他自己用兩台 Nexus 7 2013 比較的影片也可以證明。跑 ART 的那台看起來反應比較快。
結論
跑分的結果與影片描繪出 ART 今日的地位。ART 一定可以有所作為，但是現在看來 ART 還不成熟，與 Dalvik 沒有明顯的差距。ART 的浮點運算與基本反應有明顯的優勢，但是也就這樣而已。在整數運算，應用程式可執行性或是其他許多方面，ART 只有微幅或甚至沒有任何優勢可言。事實上，目前看起來玩遊戲的使用者們最好還是繼續使用 Dalvik。為什麼跑分的成績沒有令我們震驚？如果讓我猜，應該是因為發展中的 ART 首要是確保「能運作」以及「穩定」，之後才是最佳化。如果是這樣，那麼現在 ART 裏面應該還有一些原始碼是用來檢查錯誤以及記錄行為用的，以確保 ART 的運作如同設計一般。這些甚至可能比我們使用 Dalvik 還更消耗系統資源。ART 輸給 Dalvik 的測試項目中，其分數都很接近。ART 的後續版本可以期待其效能的大幅增長。
目前現實的問題是：現在值得切換到 ART 嗎？很明顯的 Google 並不建議一般使用者這麼做，而我傾向於同意 Google。雖然 ART 目前看來很可靠，而且我感覺反應也比較好－但有可能只是心理作用。但 ART 不穩定造成應用程式當機的情形卻是存在的。你在使用的 app 中，只要有一個 app 你需要切回 Dalvik 才能運作，這個不便的負面效益遠大於 ART 帶來的那一點點效能上的正面效益。我完成這系列後，我在 KitKat 應該會繼續使用 Dalvik 執行階段吧。而且我相信對大多數人而言 Dalvik 還是比較好的選擇。
沒有留言:
張貼留言